diff --git a/content/pt-br/docs/tasks/access-application-cluster/access-cluster.md b/content/pt-br/docs/tasks/access-application-cluster/access-cluster.md new file mode 100644 index 0000000000000..c062909e80956 --- /dev/null +++ b/content/pt-br/docs/tasks/access-application-cluster/access-cluster.md @@ -0,0 +1,269 @@ +--- +title: Acessando clusters +weight: 20 +content_type: concept +--- + + + +Esse tópico fala sobre diversas maneiras de interagir com clusters. + + + +## Acessando pela primeira vez com kubectl + +Se estiver acessando o Kubernetes API pela primeira vez, recomendamos usar a CLI do Kubernetes, `kubectl`. + +Para acessar um cluster, você precisa saber a localização do cluster e ter credenciais para acessá-lo. Geralmente, isso é configurado automaticamente quando você trabalha com um [Guia de instalação](/pt-br/docs/setup/) ou outra pessoa configurou o cluster e forneceu a você credenciais e uma localização. + +Verifique o local e as credenciais que o kubectl conhece com esse comando: + +```shell +kubectl config view +``` + +Muitos dos [exemplos](/docs/reference/kubectl/quick-reference/) fornecem uma introdução ao uso do `kubectl` e a documentação completa pode ser encontrada no [guia de referência do kubectl](/docs/reference/kubectl/). + +## Acessando diretamente a API REST {#directly-accessing-the-rest-api} + +O Kubectl lida com a localização e a autenticação no servidor de API. +Se você quiser acessar diretamente a API REST com um cliente http como +curl ou wget, ou um navegador, há várias maneiras de localizar e autenticar: + +- Executar o kubectl no modo proxy. + - Método recomendado. + - Usa a localização previamente armazenada do servidor da API. + - Verifica a identidade do apiserver usando um certificado autoassinado. Não há possibilidade de ataque MITM (_Man-In-The-Middle_). + - Autentica-se no servidor da API. + - No futuro, poderá fazer balanceamento de carga inteligente no lado do cliente, e transferência em caso de falha. +- Forneça o local e as credenciais diretamente para o cliente http. + - Método alternativo. + - Funciona com alguns tipos de código de cliente que são confundidos pelo uso de um proxy. + - É necessário importar um certificado raiz em seu navegador para se proteger contra ataque MITM (_Man-In-The-Middle_). + +### Usando o kubectl proxy + +O comando a seguir executa o kubectl em um modo em que ele atua como um proxy reverso. Ele lida com +localização do apiserver e da autenticação. +Execute-o desta forma: + +```shell +kubectl proxy --port=8080 +``` + +Consulte [kubectl proxy](/docs/reference/generated/kubectl/kubectl-commands/#proxy) para obter mais detalhes. + +Em seguida, você pode explorar a API com curl, wget ou um navegador, substituindo localhost +por [::1] para IPv6, da seguinte forma: + +```shell +curl http://localhost:8080/api/ +``` + +O resultado é semelhante a este: + +```json +{ + "kind": "APIVersions", + "versions": [ + "v1" + ], + "serverAddressByClientCIDRs": [ + { + "clientCIDR": "0.0.0.0/0", + "serverAddress": "10.0.1.149:443" + } + ] +} +``` + +### Sem kubectl proxy + +Use `kubectl apply` e `kubectl describe secret...` para criar um token para a conta de serviço padrão com grep/cut: + +Primeiro, crie o Secret, solicitando um token para a ServiceAccount padrão: + +```shell +kubectl apply -f - </dev/null; do + echo "waiting for token..." >&2 + sleep 1 +done +``` + +Recupere e use o token gerado: + +```shell +APISERVER=$(kubectl config view --minify | grep server | cut -f 2- -d ":" | tr -d " ") +TOKEN=$(kubectl describe secret default-token | grep -E '^token' | cut -f2 -d':' | tr -d " ") + +curl $APISERVER/api --header "Authorization: Bearer $TOKEN" --insecure +``` + +O resultado é semelhante a este: + +```json +{ + "kind": "APIVersions", + "versions": [ + "v1" + ], + "serverAddressByClientCIDRs": [ + { + "clientCIDR": "0.0.0.0/0", + "serverAddress": "10.0.1.149:443" + } + ] +} +``` + +Usando `jsonpath`: + +```shell +APISERVER=$(kubectl config view --minify -o jsonpath='{.clusters[0].cluster.server}') +TOKEN=$(kubectl get secret default-token -o jsonpath='{.data.token}' | base64 --decode) + +curl $APISERVER/api --header "Authorization: Bearer $TOKEN" --insecure +``` + +O resultado é semelhante a este: + +```json +{ + "kind": "APIVersions", + "versions": [ + "v1" + ], + "serverAddressByClientCIDRs": [ + { + "clientCIDR": "0.0.0.0/0", + "serverAddress": "10.0.1.149:443" + } + ] +} +``` + +Os exemplos acima usam a opção `--insecure`. Isso deixa o cluster sujeito a ataques MITM. +Quando o kubectl acessa o cluster, ele usa um certificado raiz guardado +e certificados de cliente para acessar o servidor. (Esses certificados são instalados no diretório +`~/.kube`). Como os certificados do cluster normalmente são autoassinados, pode ser necessária uma +configuração especial para que seu cliente http use o certificado raiz. + +Em alguns clusters, o servidor da API não requer autenticação; ele pode servir +no localhost ou estar protegido por um firewall. Não há um padrão +para isso. A página [Controlando Acesso à API do Kubernetes](/pt-br/docs/concepts/security/controlling-access) +descreve como um administrador de cluster pode configurar isso. + +## Acesso programático à API + +O Kubernetes suporta oficialmente as bibliotecas de clientes [Go](#go-client) e [Python](#python-client). + +### Cliente Go{#go-client} + +* Para obter a biblioteca, execute o seguinte comando: `go get k8s.io/client-go@kubernetes-`, + consulte [INSTALL.md](https://github.com/kubernetes/client-go/blob/master/INSTALL.md#for-the-casual-user) + para obter instruções detalhadas de instalação. Consulte + [https://github.com/kubernetes/client-go](https://github.com/kubernetes/client-go#compatibility-matrix) + para ver quais versões são compatíveis. +* Escreva um aplicativo utilizando o cliente Go. Observe que ela define seus próprios objetos de API, + portanto, se necessário, importe as definições de API do cliente Go em vez de importá-las do repositório principal. + Por exemplo, `import "k8s.io/client-go/kubernetes"` está correto. + +O cliente Go pode usar o mesmo arquivo [kubeconfig](/pt-br/docs/concepts/configuration/organize-cluster-access-kubeconfig/) +como a CLI do kubectl faz, para localizar e autenticar ao apiserver. Veja esse +[exemplo](https://git.k8s.io/client-go/examples/out-of-cluster-client-configuration/main.go). + +Se o aplicativo for disponibilizado como um pod no cluster, consulte a [próxima seção](#acessando-a-api-a-partir-de-um-pod). + +### Cliente Python{#python-client} + +Para usar o [cliente Python](https://github.com/kubernetes-client/python), execute o seguinte comando: +`pip install kubernetes`. Consulte [a página Python Client Library](https://github.com/kubernetes-client/python) +para obter mais opções de instalação. + +O cliente Python pode usar o mesmo arquivo [kubeconfig](/docs/concepts/configuration/organize-cluster-access-kubeconfig/) +que a ferramenta kubectl utiliza para localizar e autenticar ao servidor da API. Veja esse +[exemplo](https://github.com/kubernetes-client/python/tree/master/examples). + +### Outras bibliotecas + +Existem [bibliotecas de clientes](/docs/reference/using-api/client-libraries/) para acessar a API utilizando outras linguagens. +Consulte a documentação de outras bibliotecas para saber como elas se autenticam. + +## Acessando a API a partir de um pod + +Ao acessar a API a partir de um pod, a localização e a autenticação +para o servidor de API são um pouco diferentes. + +Consulte [Acessando a API a partir de um pod](/docs/tasks/run-application/access-api-from-pod/) +para obter mais detalhes. + +## Acessando serviços em execução no cluster + +A seção anterior descreve como se conectar ao servidor da API do Kubernetes. +Para obter informações sobre como se conectar a outros serviços em execução em um cluster do Kubernetes, consulte +[Acessando serviços em execução em clusters](/pt-br/docs/tasks/access-application-cluster/access-cluster-services/). + +## Solicitação de redirecionamentos + +Os recursos de redirecionamento foram descontinuados e removidos. Em vez disso, use um proxy (veja abaixo). + +## Tantos proxies + +Há vários proxies diferentes que você pode encontrar ao usar o Kubernetes: + +1. O [kubectl proxy](#directly-accessing-the-rest-api): + + - é executado no computador de um usuário ou em um pod + - cria um proxy de um endereço localhost para o servidor da API do Kubernetes + - a conexão do cliente para o proxy usa HTTP + - a conexão do proxy para o servidor da API usa HTTPS + - localiza o apiserver + - adiciona cabeçalhos de autenticação + +2. O [proxy do servidor da API](/pt-br/docs/tasks/access-application-cluster/access-cluster-services/#descobrindo-serviços-integrados): + + - é um bastião incorporado ao apiserver + - conecta um usuário fora do cluster aos IPs do cluster que, de outra forma, poderiam não ser acessíveis + - é executado no processo do servidor da API + - cliente para proxy usa HTTPS (ou http se o servidor da API estiver configurado dessa forma) + - a conexão do proxy para o destino pode usar HTTP ou HTTPS, conforme escolhido pelo proxy usando as informações disponíveis + - pode ser usado para acessar um Nó, Pod ou Serviço + - faz o balanceamento de carga quando usado para acessar um serviço + +3. O [kube proxy](/docs/concepts/services-networking/service/#ips-and-vips): + + - é executado em cada nó + - proxy de UDP e TCP + - não entende HTTP + - fornece balanceamento de carga + - é usado apenas para acessar serviços + +4. Um Proxy/balanceador de carga na frente do(s) servidor(es) da API: + + - a existência e a implementação variam de cluster para cluster (por exemplo, nginx) + - fica entre todos os clientes e um ou mais servidores da API + - atua como um balanceador de carga se houver vários servidores da API. + +6. Balanceadores de carga de provedor de nuvem em serviços externos: + + - são fornecidos por alguns provedores de nuvem computacional (por exemplo, AWS ELB, Google Cloud Load Balancer) + - são criados automaticamente quando o serviço Kubernetes tem o tipo `LoadBalancer` + - usam somente UDP/TCP + - a implementação varia de acordo com o provedor de nuvem. + +Normalmente, os usuários do Kubernetes não precisam se preocupar com nada além dos dois primeiros tipos. O administrador do cluster +normalmente garantirá que os últimos tipos sejam configurados corretamente. diff --git a/content/pt-br/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md b/content/pt-br/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md new file mode 100644 index 0000000000000..4c81fd63bdef3 --- /dev/null +++ b/content/pt-br/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md @@ -0,0 +1,400 @@ +--- +title: Configurar o acesso a múltiplos clusters +content_type: task +weight: 30 +card: + name: tasks + weight: 25 + title: Configure access to clusters +--- + + + +Esta página mostra como configurar o acesso a vários clusters usando arquivos de configuração. Depois que os clusters, os usuários e os contextos forem definidos em um ou mais arquivos de configuração, você pode alternar rapidamente entre os clusters usando o comando `kubectl config use-context`. + +{{< note >}} +Um arquivo usado para configurar o acesso a um cluster às vezes é chamado de arquivo *kubeconfig*. Essa é uma forma genérica de se referir a arquivos de configuração. Isso não significa que exista um arquivo chamado `kubeconfig`. +{{< /note >}} + + +{{< warning >}} +Use somente arquivos kubeconfig de fontes confiáveis. O uso de um arquivo kubeconfig artificialmente criado, pode resultar em execução de código malicioso ou exposição de arquivos. Se você preciso usar um arquivo kubeconfig não-confiável, inspecione-o cuidadosamente antes, da mesma forma que faria com um script de shell. +{{< /warning>}} + + +## {{% heading "prerequisites" %}} + +{{< include "task-tutorial-prereqs.md" >}} + +Para verificar se {{< glossary_tooltip text="kubectl" term_id="kubectl" >}} está instalado, +execute `kubectl version --client`. A versão do kubectl deve ter [no máximo uma versão menor de diferença](/releases/version-skew-policy/#kubectl) da versão do servidor de API do seu cluster. + + + +## Defina clusters, usuários e contextos + +Suponha que você tenha dois clusters, um para o trabalho de desenvolvimento, chamado `development`, e outro para o trabalho de teste, chamado `test`. +No cluster `development`, seus desenvolvedores de front-end trabalham em um namespace chamado `frontend`, +e os desenvolvedores de armazenamento trabalham em um namespace chamado `storage`. Em seu cluster `test`, +os desenvolvedores trabalham no namespace padrão ou criam namespaces auxiliares conforme +acharem adequado. O acesso ao cluster de desenvolvimento requer autenticação por certificado. O acesso +ao cluster de teste requer autenticação por nome de usuário e senha. + +Crie um diretório chamado `config-exercise`. Em seu diretório +`config-exercise`, crie um arquivo chamado `config-demo` com este conteúdo: + +```yaml +apiVersion: v1 +kind: Config +preferences: {} + +clusters: +- cluster: + name: development +- cluster: + name: test + +users: +- name: developer +- name: experimenter + +contexts: +- context: + name: dev-frontend +- context: + name: dev-storage +- context: + name: exp-test +``` + +Um arquivo de configuração descreve clusters, usuários e contextos. Seu arquivo `config-demo` +tem a estrutura para descrever dois clusters, dois usuários e três contextos. + +Vá para o diretório `config-exercise`. Digite estes comandos para adicionar detalhes do cluster ao +seu arquivo de configuração: + +```shell +kubectl config --kubeconfig=config-demo set-cluster development --server=https://1.2.3.4 --certificate-authority=fake-ca-file +kubectl config --kubeconfig=config-demo set-cluster test --server=https://5.6.7.8 --insecure-skip-tls-verify +``` + +Adicione detalhes do usuário ao seu arquivo de configuração: + +{{< caution >}} +O armazenamento de senhas na configuração do cliente do Kubernetes é arriscado. Uma alternativa melhor seria usar um plug-in de credenciais e salvá-las separadamente. Veja: [plugins de credenciais client-go](/pt-br/docs/reference/access-authn-authz/authentication/#plugins-de-credenciais-client-go) +{{< /caution >}} + +```shell +kubectl config --kubeconfig=config-demo set-credentials developer --client-certificate=fake-cert-file --client-key=fake-key-seefile +kubectl config --kubeconfig=config-demo set-credentials experimenter --username=exp --password=some-password +``` + +{{< note >}} +- Para excluir um usuário, você pode executar `kubectl --kubeconfig=config-demo config unset users.` +- Para remover um cluster, você pode executar `kubectl --kubeconfig=config-demo config unset clusters.` +- Para remover um contexto, você pode executar `kubectl --kubeconfig=config-demo config unset contexts.` +{{< /note >}} + +Adicione detalhes de contexto ao seu arquivo de configuração: + +```shell +kubectl config --kubeconfig=config-demo set-context dev-frontend --cluster=development --namespace=frontend --user=developer +kubectl config --kubeconfig=config-demo set-context dev-storage --cluster=development --namespace=storage --user=developer +kubectl config --kubeconfig=config-demo set-context exp-test --cluster=test --namespace=default --user=experimenter +``` + +Abra seu arquivo `config-demo` para ver os detalhes adicionados. Como alternativa para abrir o arquivo `config-demo`, você pode usar o comando `config view` + +```shell +kubectl config --kubeconfig=config-demo view +``` + +O resultado mostra os dois clusters, dois usuários e três contextos: + +```yaml +apiVersion: v1 +clusters: +- cluster: + certificate-authority: fake-ca-file + server: https://1.2.3.4 + name: development +- cluster: + insecure-skip-tls-verify: true + server: https://5.6.7.8 + name: test +contexts: +- context: + cluster: development + namespace: frontend + user: developer + name: dev-frontend +- context: + cluster: development + namespace: storage + user: developer + name: dev-storage +- context: + cluster: test + namespace: default + user: experimenter + name: exp-test +current-context: "" +kind: Config +preferences: {} +users: +- name: developer + user: + client-certificate: fake-cert-file + client-key: fake-key-file +- name: experimenter + user: + # Nota de documentação (este comentário NÃO faz parte da saída do comando). + # Armazenar senhas na configuração do cliente Kubernetes é arriscado. + # Uma alternativa melhor seria usar um plugin de credenciais + # e armazenar as credenciais separadamente. + # Veja https://kubernetes.io/pt-br/docs/reference/access-authn-authz/authentication/#plugins-de-credenciais-client-go + password: some-password + username: exp +``` + +O `fake-ca-file`, o `fake-cert-file` e o `fake-key-file` acima são os espaços reservados +para a localização dos arquivos de certificado. Você precisa alterá-los para a localização real +dos arquivos de certificado em seu ambiente. + +Às vezes, você pode querer usar dados codificados em Base64 incorporados aqui, em vez de arquivos de certificado separados. +Nesse caso, é necessário adicionar o sufixo `data` às chaves, por exemplo, +`certificate-authority-data`, `client-certificate-data`, `client-key-data`. + +Cada contexto é uma tripla (cluster, usuário, namespace). Por exemplo, o contexto +`dev-frontend` diz: "Use as credenciais do usuário `developer` +para acessar o namespace `frontend` do cluster `development`". + +Define o contexto atual: + +```shell +kubectl config --kubeconfig=config-demo use-context dev-frontend +``` + +Agora, sempre que você use um comando `kubectl`, a ação será aplicada ao cluster, +e ao namespace listados no contexto `dev-frontend`. E o comando usará +as credenciais do usuário listado no contexto `dev-frontend`. + +Para ver apenas as informações de configuração associadas ao +o contexto atual, use a opção `--minify`. + +```shell +kubectl config --kubeconfig=config-demo view --minify +``` + +O resultado mostra as informações de configuração associadas ao contexto `dev-frontend`: + +```yaml +apiVersion: v1 +clusters: +- cluster: + certificate-authority: fake-ca-file + server: https://1.2.3.4 + name: development +contexts: +- context: + cluster: development + namespace: frontend + user: developer + name: dev-frontend +current-context: dev-frontend +kind: Config +preferences: {} +users: +- name: developer + user: + client-certificate: fake-cert-file + client-key: fake-key-file +``` + +Agora, suponha que você queira trabalhar por um tempo no cluster de teste. + +Altere o contexto atual para `exp-test`: + +```shell +kubectl config --kubeconfig=config-demo use-context exp-test +``` + +Agora, qualquer comando `kubectl` que você usar, será aplicado ao namespace padrão do cluster `test`. E o comando usará as credenciais do usuário +listado no contexto `exp-test`. + +Ver a configuração associada ao novo contexto atual, `exp-test`. + +```shell +kubectl config --kubeconfig=config-demo view --minify +``` + +Por fim, suponha que você queira trabalhar por um tempo no namespace `storage` do cluster `development`. + +Altere o contexto atual para `dev-storage`: + +```shell +kubectl config --kubeconfig=config-demo use-context dev-storage +``` + +Ver a configuração associada ao novo contexto atual, `dev-storage`. + +```shell +kubectl config --kubeconfig=config-demo view --minify +``` + +## Crie um segundo arquivo de configuração + +Em seu diretório `config-exercise`, crie um arquivo chamado `config-demo-2` com este conteúdo: + +```yaml +apiVersion: v1 +kind: Config +preferences: {} + +contexts: +- context: + cluster: development + namespace: ramp + user: developer + name: dev-ramp-up +``` + +O arquivo de configuração anterior define um novo contexto chamado `dev-ramp-up`. + +## Defina a variável de ambiente KUBECONFIG + +Verifique se você tem uma variável de ambiente chamada `KUBECONFIG`. Em caso afirmativo, salve o valor atual da variável de ambiente `KUBECONFIG` para que você possa restaurá-lo posteriormente. +Por exemplo: + +### Linux + +```shell +export KUBECONFIG_SAVED="$KUBECONFIG" +``` + +### Windows PowerShell + +```powershell +$Env:KUBECONFIG_SAVED=$ENV:KUBECONFIG +``` + + A variável de ambiente `KUBECONFIG` é uma lista de caminhos para arquivos de configuração. A lista é +delimitada por dois pontos para Linux e Mac, e delimitada por ponto e vírgula para Windows. Se você tiver +uma variável de ambiente `KUBECONFIG`, familiarize-se com os arquivos de configuração +na lista. + +Anexe temporariamente duas localizações à sua variável de ambiente `KUBECONFIG`. Por exemplo: + +### Linux + +```shell +export KUBECONFIG="${KUBECONFIG}:config-demo:config-demo-2" +``` + +### Windows PowerShell + +```powershell +$Env:KUBECONFIG=("config-demo;config-demo-2") +``` + +Em seu diretório `config-exercise`, digite este comando: + +```shell +kubectl config view +``` + +O resultado mostra informações mescladas de todos os arquivos listados em sua variável de ambiente `KUBECONFIG`. Em particular, observe que as informações mescladas têm o contexto `dev-ramp-up` do arquivo `config-demo-2` e os três contextos do arquivo `config-demo`: + +```yaml +contexts: +- context: + cluster: development + namespace: frontend + user: developer + name: dev-frontend +- context: + cluster: development + namespace: ramp + user: developer + name: dev-ramp-up +- context: + cluster: development + namespace: storage + user: developer + name: dev-storage +- context: + cluster: test + namespace: default + user: experimenter + name: exp-test +``` + +Para obter mais informações sobre como os arquivos kubeconfig são mesclados, consulte +[Organizando o acesso ao cluster usando arquivos kubeconfig](/pt-br/docs/concepts/configuration/organize-cluster-access-kubeconfig/) + +## Explore o diretório $HOME/.kube + +Se você já tiver um cluster e puder usar o `kubectl` para interagir com o +o cluster, então provavelmente você tem um arquivo chamado `config` no diretório `$HOME/.kube`. + +Vá para `$HOME/.kube` e veja quais arquivos estão lá. Normalmente, há um arquivo chamado +`config`. Também pode haver outros arquivos de configuração nesse diretório. Em um breve momento +familiarize-se com o conteúdo desses arquivos. + +## Acrescente $HOME/.kube/config à sua variável de ambiente KUBECONFIG + +Se você tiver um arquivo `$HOME/.kube/config` e ele ainda não estiver listado em sua variável de ambiente +`KUBECONFIG`, acrescente-o à sua variável de ambiente `KUBECONFIG` agora. +Por exemplo: + +### Linux + +```shell +export KUBECONFIG="${KUBECONFIG}:${HOME}/.kube/config" +``` + +### Windows Powershell + +```powershell +$Env:KUBECONFIG="$Env:KUBECONFIG;$HOME\.kube\config" +``` + +Visualize as informações de configuração mescladas de todos os arquivos que agora estão listados +em sua variável de ambiente `KUBECONFIG`. Em seu diretório config-exercise, digite: + +```shell +kubectl config view +``` + +## Limpar + +Retorne sua variável de ambiente `KUBECONFIG` ao seu valor original. Por exemplo:
+ +### Linux + +```shell +export KUBECONFIG="$KUBECONFIG_SAVED" +``` + +### Windows PowerShell + +```powershell +$Env:KUBECONFIG=$ENV:KUBECONFIG_SAVED +``` + +## Verificar o sujeito representado pelo kubeconfig + +Nem sempre é óbvio quais atributos (nome de usuário, grupos) você obterá após a autenticação no cluster. +Isso pode ser ainda mais desafiador se você estiver gerenciando mais de um cluster ao mesmo tempo. + +Há um subcomando de `kubectl` para verificar os atributos do sujeito, como o nome de usuário, para o Kubernetes contexto selecionado: `kubectl auth whoami`. + +Leia [Acesso da API às informações de autenticação de um cliente](/docs/reference/access-authn-authz/authentication/#self-subject-review) +para saber mais sobre isso em detalhes. + + +## {{% heading "whatsnext" %}} + +* [Organizando o acesso ao cluster usando arquivos kubeconfig](/pt-br/docs/concepts/configuration/organize-cluster-access-kubeconfig/) +* [kubectl config](/docs/reference/generated/kubectl/kubectl-commands#config) +