Move portuguese content to pt-br to correct shortcode problems and add redirection (#27413)
* Move portuguese content to pt-br to correct shortcode problems and add a redirection * Correct small shortcode * Move portuguese content to pt-br to correct shortcode problems and add a redirection * Add missing print page shortcodes
This commit is contained in:
Ricardo Katz
@@ -0,0 +1,69 @@
|
||||
---
|
||||
title: Administração de Cluster
|
||||
weight: 100
|
||||
content_type: concept
|
||||
description: >
|
||||
Detalhes de baixo nível relevantes para criar ou administrar um cluster Kubernetes.
|
||||
no_list: true
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
A visão geral da administração do cluster é para qualquer pessoa que crie ou administre um cluster do Kubernetes.
|
||||
É pressuposto alguma familiaridade com os [conceitos](/docs/concepts) principais do Kubernetes.
|
||||
|
||||
<!-- body -->
|
||||
## Planejando um cluster
|
||||
|
||||
Consulte os guias em [Configuração](/docs/setup) para exemplos de como planejar, instalar e configurar clusters Kubernetes. As soluções listadas neste artigo são chamadas de *distros*.
|
||||
|
||||
{{< note >}}
|
||||
Nem todas as distros são mantidas ativamente. Escolha distros que foram testadas com uma versão recente do Kubernetes.
|
||||
{{< /note >}}
|
||||
|
||||
Antes de escolher um guia, aqui estão algumas considerações:
|
||||
|
||||
- Você quer experimentar o Kubernetes em seu computador ou deseja criar um cluster de vários nós com alta disponibilidade? Escolha as distros mais adequadas ás suas necessidades.
|
||||
- Você vai usar um **cluster Kubernetes gerenciado** , como o [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/), ou **vai hospedar seu próprio cluster**?
|
||||
- Seu cluster será **local**, ou **na nuvem (IaaS)**? O Kubernetes não oferece suporte direto a clusters híbridos. Em vez disso, você pode configurar vários clusters.
|
||||
- **Se você estiver configurando o Kubernetes local**, leve em consideração qual [modelo de rede](/docs/concepts/cluster-Administration/networking) se encaixa melhor.
|
||||
- Você vai executar o Kubernetes em um hardware **bare metal** ou em **máquinas virtuais? (VMs)**?
|
||||
- Você **deseja apenas executar um cluster** ou espera **participar ativamente do desenvolvimento do código do projeto Kubernetes**? Se for a segunda opção,
|
||||
escolha uma distro desenvolvida ativamente. Algumas distros usam apenas versão binária, mas oferecem uma maior variedade de opções.
|
||||
- Familiarize-se com os [componentes](/docs/concepts/overview/components/) necessários para executar um cluster.
|
||||
|
||||
|
||||
## Gerenciando um cluster
|
||||
|
||||
* Aprenda como [gerenciar nós](/docs/concepts/architecture/nodes/).
|
||||
* Aprenda a configurar e [gerenciar a quota de recursos](/docs/concepts/policy/resource-quotas/) para clusters compartilhados.
|
||||
|
||||
## Protegendo um cluster
|
||||
|
||||
* [Gerar Certificados](/docs/tasks/administer-cluster/certificates/) descreve os passos para gerar certificados usando diferentes cadeias de ferramentas.
|
||||
|
||||
* [Ambiente de Contêineres do Kubernetes](/docs/concepts/containers/container-environment/) descreve o ambiente para contêineres gerenciados pelo kubelet em um nó Kubernetes.
|
||||
|
||||
* [Controle de Acesso a API do Kubernetes](/docs/concepts/security/controlling-access) descreve como o Kubernetes implementa o controle de acesso para sua própria API.
|
||||
|
||||
* [Autenticação](/docs/reference/access-authn-authz/authentication/) explica a autenticação no Kubernetes, incluindo as várias opções de autenticação.
|
||||
|
||||
* [Autorização](/docs/reference/access-authn-authz/authorization/) é separado da autenticação e controla como as chamadas HTTP são tratadas.
|
||||
|
||||
* [Usando Controladores de Admissão](/docs/reference/access-authn-authz/admission-controllers/) explica plugins que interceptam requisições para o servidor da API Kubernetes após
|
||||
a autenticação e autorização.
|
||||
|
||||
* [usando Sysctl em um Cluster Kubernetes](/docs/tasks/administer-cluster/sysctl-cluster/) descreve a um administrador como usar a ferramenta de linha de comando `sysctl` para
|
||||
definir os parâmetros do kernel.
|
||||
|
||||
* [Auditoria](/docs/tasks/debug-application-cluster/audit/) descreve como interagir com *logs* de auditoria do Kubernetes.
|
||||
|
||||
### Protegendo o kubelet
|
||||
* [Comunicação Control Plane-Nó](/docs/concepts/architecture/control-plane-node-communication/)
|
||||
* [TLS bootstrapping](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/)
|
||||
* [Autenticação/autorização do kubelet](/docs/reference/command-line-tools-reference/kubelet-authentication-authorization/)
|
||||
|
||||
## Serviços Opcionais para o Cluster
|
||||
|
||||
* [Integração com DNS](/docs/concepts/services-networking/dns-pod-service/) descreve como resolver um nome DNS diretamente para um serviço Kubernetes.
|
||||
|
||||
* [Registro e Monitoramento da Atividade do Cluster](/docs/concepts/cluster-administration/logging/) explica como funciona o *logging* no Kubernetes e como implementá-lo.
|
||||
@@ -0,0 +1,58 @@
|
||||
---
|
||||
title: Instalando Addons
|
||||
content_type: concept
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
|
||||
Addons estendem a funcionalidade do Kubernetes.
|
||||
|
||||
Esta página lista alguns dos add-ons e links com suas respectivas instruções de instalação.
|
||||
|
||||
Os Add-ons de cada sessão são classificados em ordem alfabética - a ordem não implica qualquer status preferencial.
|
||||
|
||||
|
||||
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## Rede e Política de Rede
|
||||
|
||||
|
||||
* [ACI](https://www.github.com/noironetworks/aci-containers) fornece rede integrada de contêineres e segurança de rede com a Cisco ACI.
|
||||
* [Calico](https://docs.projectcalico.org/latest/getting-started/kubernetes/) é um provedor de políticas de rede e rede L3 seguro.
|
||||
* [Canal](https://github.com/tigera/canal/tree/master/k8s-install) une Flannel e Calico, fornecendo rede e política de rede.
|
||||
* [Cilium](https://github.com/cilium/cilium) é um plug-in de políticas de rede e rede L3 que pode impor políticas de HTTP / API / L7 de forma transparente. Tanto o modo de roteamento quanto o de sobreposição / encapsulamento são suportados.
|
||||
* [CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie) permite que o Kubernetes se conecte facilmente a uma variedade de plugins CNI, como Calico, Canal, Flannel, Romana ou Weave.
|
||||
* [Contiv](http://contiv.github.io) fornece um rede configurável (L3 nativa usando BGP, sobreposição usando vxlan, L2 clássico e Cisco-SDN / ACI) para vários casos de uso e uma estrutura rica de políticas de rede. O projeto Contiv é totalmente [open source](http://github.com/contiv). O script de [instalação](http://github.com/contiv/install) fornece opções de instalação com ou sem kubeadm.
|
||||
* [Contrail](http://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/), baseado no [Tungsten Fabric](https://tungsten.io), é um projeto open source, multi-cloud com uma rede virtualizada e com uma plataforma de gerenciamento de políticas de rede. O Contrail e o Tungsten Fabric estão integrados a sistemas de orquestração, como Kubernetes, OpenShift, OpenStack e Mesos, e fornecem modos de isolamento para máquinas virtuais, containers / pods e cargas em servidores físicos.
|
||||
* [Flannel](https://github.com/coreos/flannel/blob/master/Documentation/kubernetes.md) é um provedor de rede de sobreposição que pode ser usado com o Kubernetes.
|
||||
* [Knitter](https://github.com/ZTE/Knitter/) é uma solução de rede que suporta múltiplas redes no Kubernetes.
|
||||
* [Multus](https://github.com/Intel-Corp/multus-cni) é um plugin Multi para suporte a várias redes no Kubernetes para suportar todos os plugins CNI (por exemplo, Calico, Cilium, Contiv, Flannel), além das cargas de trabalho baseadas em SRIOV, DPDK, OVS-DPDK e VPP no Kubernetes.
|
||||
* [NSX-T](https://docs.vmware.com/en/VMware-NSX-T/2.0/nsxt_20_ncp_kubernetes.pdf) O Plugin de contêiner (NCP) fornece integração entre o VMware NSX-T e orquestradores de contêineres como o Kubernetes, além da integração entre o NSX-T e as plataformas CaaS / PaaS baseadas em contêiner, como Pivotal Container Service (PKS) e OpenShift.
|
||||
* [Nuage](https://github.com/nuagenetworks/nuage-kubernetes/blob/v5.1.1-1/docs/kubernetes-1-installation.rst) é uma plataforma SDN que fornece uma rede baseada em políticas entre os Pods Kubernetes e os ambientes não-Kubernetes, com visibilidade e monitoramento de segurança.
|
||||
* [Romana](http://romana.io) é uma solução de rede Camada 3 para redes de pods que também suporta [NetworkPolicy API](/docs/concepts/services-networking/network-policies/). Detalhes da instalação do add-on Kubeadm disponíveis [aqui](https://github.com/romana/romana/tree/master/containerize).
|
||||
* [Weave Net](https://www.weave.works/docs/net/latest/kube-addon/) fornece rede e política de rede, continuará trabalhando em ambos os lados de uma partição de rede e não requer um banco de dados externo.
|
||||
|
||||
## Descoberta de Serviço
|
||||
|
||||
* [CoreDNS](https://coredns.io) é um servidor DNS flexível e extensível que pode ser [instalado](https://github.com/coredns/deployment/tree/master/kubernetes) como DNS dentro do cluster para ser utilizado por pods.
|
||||
|
||||
## Visualização & Controle
|
||||
|
||||
* [Dashboard](https://github.com/kubernetes/dashboard#kubernetes-dashboard) é uma interface web para gestão do Kubernetes.
|
||||
* [Weave Scope](https://www.weave.works/documentation/scope-latest-installing/#k8s) é uma ferramenta gráfica para visualizar contêineres, pods, serviços etc. Use-o em conjunto com o [Weave Cloud account](https://cloud.weave.works/) ou hospede você mesmo a interface do usuário.
|
||||
|
||||
## A infraestrutura
|
||||
|
||||
* [KubeVirt](https://kubevirt.io/user-guide/docs/latest/administration/intro.html#cluster-side-add-on-deployment) é um add-on para executar máquinas virtuais no Kubernetes. É geralmente executado em clusters em maquina fisica.
|
||||
|
||||
|
||||
## Add-ons Legado
|
||||
|
||||
Existem vários outros complementos documentados no diretório não mais ultilizados [cluster/addons](https://git.k8s.io/kubernetes/cluster/addons).
|
||||
|
||||
Projetos bem mantidos deveriam ser linkados aqui. PRs são bem vindas!
|
||||
|
||||
|
||||
@@ -0,0 +1,228 @@
|
||||
---
|
||||
title: Certificates
|
||||
content_type: concept
|
||||
weight: 20
|
||||
---
|
||||
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
Ao usar um client para autenticação de certificado, você pode gerar certificados
|
||||
manualmente através `easyrsa`, `openssl` ou `cfssl`.
|
||||
|
||||
|
||||
|
||||
|
||||
<!-- body -->
|
||||
|
||||
### easyrsa
|
||||
|
||||
**easyrsa** pode gerar manualmente certificados para o seu cluster.
|
||||
|
||||
1. Baixe, descompacte e inicialize a versão corrigida do easyrsa3.
|
||||
|
||||
curl -LO https://storage.googleapis.com/kubernetes-release/easy-rsa/easy-rsa.tar.gz
|
||||
tar xzf easy-rsa.tar.gz
|
||||
cd easy-rsa-master/easyrsa3
|
||||
./easyrsa init-pki
|
||||
1. Gerar o CA. (`--batch` set automatic mode. `--req-cn` default CN to use.)
|
||||
|
||||
./easyrsa --batch "--req-cn=${MASTER_IP}@`date +%s`" build-ca nopass
|
||||
1. Gere o certificado e a chave do servidor.
|
||||
O argumento `--subject-alt-name` define os possíveis IPs e nomes (DNS) que o servidor de API usará para ser acessado. O `MASTER_CLUSTER_IP` é geralmente o primeiro IP do serviço CIDR que é especificado como argumento em `--service-cluster-ip-range` para o servidor de API e o componente gerenciador do controlador. O argumento `--days` é usado para definir o número de dias após o qual o certificado expira.
|
||||
O exemplo abaixo também assume que você está usando `cluster.local` como DNS de domínio padrão
|
||||
|
||||
./easyrsa --subject-alt-name="IP:${MASTER_IP},"\
|
||||
"IP:${MASTER_CLUSTER_IP},"\
|
||||
"DNS:kubernetes,"\
|
||||
"DNS:kubernetes.default,"\
|
||||
"DNS:kubernetes.default.svc,"\
|
||||
"DNS:kubernetes.default.svc.cluster,"\
|
||||
"DNS:kubernetes.default.svc.cluster.local" \
|
||||
--days=10000 \
|
||||
build-server-full server nopass
|
||||
1. Copie `pki/ca.crt`, `pki/issued/server.crt`, e `pki/private/server.key` para o seu diretório.
|
||||
1. Preencha e adicione os seguintes parâmetros aos parâmetros de inicialização do servidor de API:
|
||||
|
||||
--client-ca-file=/yourdirectory/ca.crt
|
||||
--tls-cert-file=/yourdirectory/server.crt
|
||||
--tls-private-key-file=/yourdirectory/server.key
|
||||
|
||||
### openssl
|
||||
|
||||
**openssl** pode gerar manualmente certificados para o seu cluster.
|
||||
|
||||
1. Gere um ca.key com 2048bit:
|
||||
|
||||
openssl genrsa -out ca.key 2048
|
||||
1. De acordo com o ca.key, gere um ca.crt (use -days para definir o tempo efetivo do certificado):
|
||||
|
||||
openssl req -x509 -new -nodes -key ca.key -subj "/CN=${MASTER_IP}" -days 10000 -out ca.crt
|
||||
1. Gere um server.key com 2048bit:
|
||||
|
||||
openssl genrsa -out server.key 2048
|
||||
1. Crie um arquivo de configuração para gerar uma solicitação de assinatura de certificado (CSR - Certificate Signing Request). Certifique-se de substituir os valores marcados com colchetes angulares (por exemplo, `<MASTER_IP>`) com valores reais antes de salvá-lo em um arquivo (por exemplo, `csr.conf`). Note que o valor para o `MASTER_CLUSTER_IP` é o IP do cluster de serviços para o Servidor de API, conforme descrito na subseção anterior. O exemplo abaixo também assume que você está usando `cluster.local` como DNS de domínio padrão
|
||||
|
||||
[ req ]
|
||||
default_bits = 2048
|
||||
prompt = no
|
||||
default_md = sha256
|
||||
req_extensions = req_ext
|
||||
distinguished_name = dn
|
||||
|
||||
[ dn ]
|
||||
C = <country>
|
||||
ST = <state>
|
||||
L = <city>
|
||||
O = <organization>
|
||||
OU = <organization unit>
|
||||
CN = <MASTER_IP>
|
||||
|
||||
[ req_ext ]
|
||||
subjectAltName = @alt_names
|
||||
|
||||
[ alt_names ]
|
||||
DNS.1 = kubernetes
|
||||
DNS.2 = kubernetes.default
|
||||
DNS.3 = kubernetes.default.svc
|
||||
DNS.4 = kubernetes.default.svc.cluster
|
||||
DNS.5 = kubernetes.default.svc.cluster.local
|
||||
IP.1 = <MASTER_IP>
|
||||
IP.2 = <MASTER_CLUSTER_IP>
|
||||
|
||||
[ v3_ext ]
|
||||
authorityKeyIdentifier=keyid,issuer:always
|
||||
basicConstraints=CA:FALSE
|
||||
keyUsage=keyEncipherment,dataEncipherment
|
||||
extendedKeyUsage=serverAuth,clientAuth
|
||||
subjectAltName=@alt_names
|
||||
1. Gere a solicitação de assinatura de certificado com base no arquivo de configuração:
|
||||
|
||||
openssl req -new -key server.key -out server.csr -config csr.conf
|
||||
1. Gere o certificado do servidor usando o ca.key, ca.crt e server.csr:
|
||||
|
||||
openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key \
|
||||
-CAcreateserial -out server.crt -days 10000 \
|
||||
-extensions v3_ext -extfile csr.conf
|
||||
1. Veja o certificado:
|
||||
|
||||
openssl x509 -noout -text -in ./server.crt
|
||||
|
||||
Por fim, adicione os mesmos parâmetros nos parâmetros iniciais do Servidor de API.
|
||||
|
||||
### cfssl
|
||||
|
||||
**cfssl** é outra ferramenta para geração de certificados.
|
||||
|
||||
1. Baixe, descompacte e prepare as ferramentas de linha de comando, conforme mostrado abaixo. Observe que você pode precisar adaptar os comandos de exemplo abaixo com base na arquitetura do hardware e versão cfssl que você está usando.
|
||||
|
||||
curl -L https://pkg.cfssl.org/R1.2/cfssl_linux-amd64 -o cfssl
|
||||
chmod +x cfssl
|
||||
curl -L https://pkg.cfssl.org/R1.2/cfssljson_linux-amd64 -o cfssljson
|
||||
chmod +x cfssljson
|
||||
curl -L https://pkg.cfssl.org/R1.2/cfssl-certinfo_linux-amd64 -o cfssl-certinfo
|
||||
chmod +x cfssl-certinfo
|
||||
1. Crie um diretório para conter os artefatos e inicializar o cfssl:
|
||||
|
||||
mkdir cert
|
||||
cd cert
|
||||
../cfssl print-defaults config > config.json
|
||||
../cfssl print-defaults csr > csr.json
|
||||
1. Crie um arquivo de configuração JSON para gerar o arquivo CA, por exemplo, `ca-config.json`:
|
||||
|
||||
{
|
||||
"signing": {
|
||||
"default": {
|
||||
"expiry": "8760h"
|
||||
},
|
||||
"profiles": {
|
||||
"kubernetes": {
|
||||
"usages": [
|
||||
"signing",
|
||||
"key encipherment",
|
||||
"server auth",
|
||||
"client auth"
|
||||
],
|
||||
"expiry": "8760h"
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
1. Crie um arquivo de configuração JSON para o CA - solicitação de assinatura de certificado (CSR - Certificate Signing Request), por exemplo, `ca-csr.json`. Certifique-se de substituir os valores marcados com colchetes angulares por valores reais que você deseja usar.
|
||||
|
||||
{
|
||||
"CN": "kubernetes",
|
||||
"key": {
|
||||
"algo": "rsa",
|
||||
"size": 2048
|
||||
},
|
||||
"names":[{
|
||||
"C": "<country>",
|
||||
"ST": "<state>",
|
||||
"L": "<city>",
|
||||
"O": "<organization>",
|
||||
"OU": "<organization unit>"
|
||||
}]
|
||||
}
|
||||
1. Gere a chave CA (`ca-key.pem`) e o certificado (` ca.pem`):
|
||||
|
||||
../cfssl gencert -initca ca-csr.json | ../cfssljson -bare ca
|
||||
1. Crie um arquivo de configuração JSON para gerar chaves e certificados para o Servidor de API, por exemplo, `server-csr.json`. Certifique-se de substituir os valores entre colchetes angulares por valores reais que você deseja usar. O `MASTER_CLUSTER_IP` é o IP do serviço do cluster para o servidor da API, conforme descrito na subseção anterior. O exemplo abaixo também assume que você está usando `cluster.local` como DNS de domínio padrão
|
||||
|
||||
{
|
||||
"CN": "kubernetes",
|
||||
"hosts": [
|
||||
"127.0.0.1",
|
||||
"<MASTER_IP>",
|
||||
"<MASTER_CLUSTER_IP>",
|
||||
"kubernetes",
|
||||
"kubernetes.default",
|
||||
"kubernetes.default.svc",
|
||||
"kubernetes.default.svc.cluster",
|
||||
"kubernetes.default.svc.cluster.local"
|
||||
],
|
||||
"key": {
|
||||
"algo": "rsa",
|
||||
"size": 2048
|
||||
},
|
||||
"names": [{
|
||||
"C": "<country>",
|
||||
"ST": "<state>",
|
||||
"L": "<city>",
|
||||
"O": "<organization>",
|
||||
"OU": "<organization unit>"
|
||||
}]
|
||||
}
|
||||
1. Gere a chave e o certificado para o Servidor de API, que são, por padrão, salvos nos arquivos `server-key.pem` e` server.pem` respectivamente:
|
||||
|
||||
../cfssl gencert -ca=ca.pem -ca-key=ca-key.pem \
|
||||
--config=ca-config.json -profile=kubernetes \
|
||||
server-csr.json | ../cfssljson -bare server
|
||||
|
||||
|
||||
## Distribuindo Certificado CA auto assinado
|
||||
|
||||
Um nó cliente pode se recusar a reconhecer o certificado CA self-signed como válido.
|
||||
Para uma implementação de não produção ou para uma instalação que roda atrás de um firewall, você pode distribuir certificados auto-assinados para todos os clientes e atualizar a lista de certificados válidos.
|
||||
|
||||
Em cada cliente, execute as seguintes operações:
|
||||
|
||||
```bash
|
||||
sudo cp ca.crt /usr/local/share/ca-certificates/kubernetes.crt
|
||||
sudo update-ca-certificates
|
||||
```
|
||||
|
||||
```
|
||||
Updating certificates in /etc/ssl/certs...
|
||||
1 added, 0 removed; done.
|
||||
Running hooks in /etc/ca-certificates/update.d....
|
||||
done.
|
||||
```
|
||||
|
||||
## API de certificados
|
||||
|
||||
Você pode usar a API `certificates.k8s.io` para provisionar
|
||||
certificados x509 a serem usados para autenticação conforme documentado
|
||||
[aqui](/docs/tasks/tls/managing-tls-in-a-cluster).
|
||||
|
||||
|
||||
@@ -0,0 +1,76 @@
|
||||
---
|
||||
reviewers:
|
||||
- davidopp
|
||||
- lavalamp
|
||||
title: Visão Geral da Administração de Cluster
|
||||
content_type: concept
|
||||
weight: 10
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
A visão geral da administração de cluster é para qualquer um criando ou administrando um cluster Kubernetes. Assume-se que você tenha alguma familiaridade com os [conceitos](/docs/concepts/) centrais do Kubernetes.
|
||||
|
||||
|
||||
<!-- body -->
|
||||
## Planejando um cluster
|
||||
|
||||
Veja os guias em [Setup](/docs/setup/) para exemplos de como planejar, iniciar e configurar clusters Kubernetes. As soluções listadas neste artigo são chamadas *distros*.
|
||||
|
||||
Antes de escolher um guia, aqui estão algumas considerações.
|
||||
|
||||
- Você quer experimentar o Kubernetes no seu computador, ou você quer construir um cluster de alta disponibilidade e multi-nós? Escolha as distros mais adequadas às suas necessidades.
|
||||
- **Se você esta projetando para alta-disponibilidade**, saiba mais sobre configuração [clusters em múltiplas zonas](/docs/concepts/cluster-administration/federation/).
|
||||
- Você usará **um cluster Kubernetes hospedado**, como [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/), ou **hospedará seu próprio cluster**?
|
||||
- Seu cluster será **on-premises**, ou **in the cloud (IaaS)**? Kubernetes não suporta diretamente clusters híbridos. Em vez disso, você pode configurar vários clusters.
|
||||
- **Se você estiver configurando um Kubernetes on-premisess**, considere qual [modelo de rede](/docs/concepts/cluster-administration/networking/) melhor se adequa.
|
||||
- Você estará executando o Kubernetes em hardware **"bare metal"** ou em **máquinas virtuais (VMs)**?
|
||||
|
||||
- Você **quer apenas rodar um cluster**, ou você espera fazer **desenvolvimento ativo do código de projeto do Kubernetes**? Se for a segunda opção, escolha uma distro mais ativa. Algumas distros fornecem apenas binários, mas oferecem uma maior variedade de opções.
|
||||
|
||||
- Familiarize-se com os [componentes](/docs/admin/cluster-components/) necessários para rodar um cluster.
|
||||
|
||||
Nota: Nem todas as distros são ativamente mantidas. Escolha as distros que foram testadas com uma versão recente do Kubernetes.
|
||||
|
||||
## Gerenciando um cluster
|
||||
|
||||
* [Gerenciando um cluster](/docs/tasks/administer-cluster/cluster-management/) descreve vários tópicos relacionados ao ciclo de vida de um cluster: criando um novo cluster, atualizando o nó mestre e os nós de trabalho do cluster, executando manutenção de nó (por exemplo, atualizações de kernel) e atualizando a versão da API do Kubernetes de um cluster em execução.
|
||||
|
||||
* Aprender como [gerenciar um nó](/docs/concepts/nodes/node/).
|
||||
|
||||
* Aprender como configurar e gerenciar o [recurso de quota](/docs/concepts/policy/resource-quotas/) para um cluster compartilhado.
|
||||
|
||||
## Protegendo um cluster
|
||||
|
||||
* [Certificados](/docs/concepts/cluster-administration/certificates/) descreve as etapas para gerar certificados usando diferentes ferramentas.
|
||||
|
||||
* [Ambiente de Container Kubernetes](/docs/concepts/containers/container-environment-variables/) descreve o ambiente para contêineres gerenciados pelo Kubelet em um nó do Kubernetes.
|
||||
|
||||
* [Controlando Acesso a API Kubernetes API](/docs/reference/access-authn-authz/controlling-access/) descreve como configurar
|
||||
a permissão para usuários e contas de serviço.
|
||||
|
||||
* [Autenticando](/docs/reference/access-authn-authz/authentication/) explica a autenticação no Kubernetes, incluindo as várias opções de autenticação.
|
||||
|
||||
* [Autorização](/docs/reference/access-authn-authz/authorization/) é separada da autenticação e controla como as chamadas HTTP são tratadas.
|
||||
|
||||
* [Usando Controladores de Admissão](/docs/reference/access-authn-authz/admission-controllers/) explica plug-ins que interceptam solicitações ao servidor da API do Kubernetes após autenticação e autorização.
|
||||
|
||||
* [Usando Sysctls em um Cluster Kubernetes](/docs/concepts/cluster-administration/sysctl-cluster/) descreve a um administrador como usar a ferramenta de linha de comando `sysctl` para definir os parâmetros do kernel.
|
||||
|
||||
|
||||
* [Auditando](/docs/tasks/debug-application-cluster/audit/)
|
||||
descreve como interagir com os logs de auditoria do Kubernetes.
|
||||
|
||||
### Protegendo o kubelet
|
||||
* [Comunicação Master-Node ](/docs/concepts/architecture/master-node-communication/)
|
||||
* [TLS bootstrapping](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/)
|
||||
* [Autenticação/Autorização Kubelet](/docs/admin/kubelet-authentication-authorization/)
|
||||
|
||||
## Serviços Opcionais do Cluster
|
||||
|
||||
* [Integração DNS](/docs/concepts/services-networking/dns-pod-service/) descreve como resolver um nome DNS diretamente para um serviço do Kubernetes.
|
||||
|
||||
* [Logando e monitorando a atividade de cluster](/docs/concepts/cluster-administration/logging/) explica como o log funciona no Kubernetes e como implementá-lo.
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,72 @@
|
||||
---
|
||||
reviewers:
|
||||
title: Configurando o Garbage Collection do kubelet
|
||||
content_type: concept
|
||||
weight: 70
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
O Garbage collection(Coleta de lixo) é uma função útil do kubelet que limpa imagens e contêineres não utilizados. O kubelet executará o garbage collection para contêineres a cada minuto e para imagens a cada cinco minutos.
|
||||
|
||||
Ferramentas externas de garbage collection não são recomendadas, pois podem potencialmente interromper o comportamento do kubelet removendo os contêineres que existem.
|
||||
|
||||
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## Coleta de imagens
|
||||
|
||||
O Kubernetes gerencia o ciclo de vida de todas as imagens através do imageManager, com a cooperação do cadvisor.
|
||||
|
||||
A política para o garbage collection de imagens leva dois fatores em consideração:
|
||||
`HighThresholdPercent` e `LowThresholdPercent`. Uso do disco acima do limite acionará o garbage collection. O garbage collection excluirá as imagens que foram menos usadas recentemente até que o nível fique abaixo do limite.
|
||||
|
||||
## Coleta de container
|
||||
|
||||
A política para o garbage collection de contêineres considera três variáveis definidas pelo usuário. `MinAge` é a idade mínima em que um contêiner pode ser coletado. `MaxPerPodContainer` é o número máximo de contêineres mortos que todo par de pod (UID, container name) pode ter. `MaxContainers` é o número máximo de contêineres mortos totais. Essas variáveis podem ser desabilitadas individualmente, definindo `MinAge` como zero e definindo `MaxPerPodContainer` e `MaxContainers` respectivamente para menor que zero.
|
||||
|
||||
O Kubelet atuará em contêineres não identificados, excluídos ou fora dos limites definidos pelos sinalizadores mencionados. Os contêineres mais antigos geralmente serão removidos primeiro. `MaxPerPodContainer` e `MaxContainer` podem potencialmente conflitar entre si em situações em que a retenção do número máximo de contêineres por pod (`MaxPerPodContainer`) estaria fora do intervalo permitido de contêineres globais mortos (`MaxContainers`). O `MaxPerPodContainer` seria ajustado nesta situação: O pior cenário seria fazer o downgrade do `MaxPerPodContainer` para 1 e remover os contêineres mais antigos. Além disso, os contêineres pertencentes a pods que foram excluídos são removidos assim que se tornem mais antigos que `MinAge`.
|
||||
|
||||
Os contêineres que não são gerenciados pelo kubelet não estão sujeitos ao garbage collection de contêiner.
|
||||
|
||||
## Configurações do usuário
|
||||
|
||||
Os usuários podem ajustar os seguintes limites para ajustar o garbage collection da imagem com os seguintes sinalizadores do kubelet:
|
||||
|
||||
1. `image-gh-high-threshold`, a porcentagem de uso de disco que aciona o garbage collection da imagem. O padrão é 85%.
|
||||
2. `image-gc-low-threshold`, a porcentagem de uso de disco com o qual o garbage collection da imagem tenta liberar. O padrão é 80%.
|
||||
|
||||
Também permitimos que os usuários personalizem a política do garbagem collection através dos seguintes sinalizadores do kubelet:
|
||||
|
||||
1. `minimum-container-ttl-duration`, idade mínima para um contêiner finalizado antes de ser colectado. O padrão é 0 minuto, o que significa que todo contêiner finalizado será coletado como lixo.
|
||||
2. `maximum-dead-containers-per-container`, número máximo de instâncias antigas a serem retidas por contêiner. O padrão é 1.
|
||||
3. `maximum-dead-containers`, número máximo de instâncias antigas de contêineres para retenção global. O padrão é -1, o que significa que não há limite global.
|
||||
|
||||
Os contêineres podem ser potencialmente coletados como lixo antes que sua utilidade expire. Esses contêineres podem conter logs e outros dados que podem ser úteis para solucionar problemas. Um valor suficientemente grande para `maximum-dead-containers-per-container` é altamente recomendado para permitir que pelo menos 1 contêiner morto seja retido por contêiner esperado. Um valor maior para `maximum-dead-containers` também é recomendados por um motivo semelhante.
|
||||
Consulte [esta issue](https://github.com/kubernetes/kubernetes/issues/13287) para obter mais detalhes.
|
||||
|
||||
## Descontinuado
|
||||
|
||||
Alguns recursos do Garbage Collection neste documento serão substituídos pelo kubelet eviction no futuro.
|
||||
|
||||
Incluindo:
|
||||
|
||||
| Flag Existente | Nova Flag | Fundamentação |
|
||||
| ----------------------------------------- | --------------------------------------- | ------------------------------------------------------------------------------------ |
|
||||
| `--image-gc-high-threshold` | `--eviction-hard` ou `--eviction-soft` | os sinais existentes de despejo podem acionar o garbage collection da imagem |
|
||||
| `--image-gc-low-threshold` | `--eviction-minimum-reclaim` | recuperações de despejo atinge o mesmo comportamento |
|
||||
| `--maximum-dead-containers` | | descontinuado quando os logs antigos forem armazenados fora do contexto do contêiner |
|
||||
| `--maximum-dead-containers-per-container` | | descontinuado quando os logs antigos forem armazenados fora do contexto do contêiner |
|
||||
| `--minimum-container-ttl-duration` | | descontinuado quando os logs antigos forem armazenados fora do contexto do contêiner |
|
||||
| `--low-diskspace-threshold-mb` | `--eviction-hard` ou `eviction-soft` | O despejo generaliza os limites do disco para outros recursos |
|
||||
| `--outofdisk-transition-frequency` | `--eviction-pressure-transition-period` | O despejo generaliza a transição da pressão do disco para outros recursos |
|
||||
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
Consulte [Configurando a Manipulação de Recursos Insuficientes](/docs/tasks/administer-cluster/out-of-resource/) para mais detalhes.
|
||||
|
||||
|
||||
@@ -0,0 +1,206 @@
|
||||
---
|
||||
reviewers:
|
||||
- piosz
|
||||
- x13n
|
||||
title: Arquitetura de Log
|
||||
content_type: concept
|
||||
weight: 60
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
Os logs de aplicativos e sistemas podem ajudá-lo a entender o que está acontecendo dentro do seu cluster. Os logs são particularmente úteis para depurar problemas e monitorar a atividade do cluster. A maioria das aplicações modernas possui algum tipo de mecanismo de logs; como tal, a maioria dos mecanismos de contêineres também é projetada para suportar algum tipo de log. O método de log mais fácil e abrangente para aplicações em contêiner é gravar nos fluxos de saída e erro padrão.
|
||||
|
||||
No entanto, a funcionalidade nativa fornecida por um mecanismo de contêiner ou tempo de execução geralmente não é suficiente para uma solução completa de log. Por exemplo, se um contêiner travar, um pod for despejado ou um nó morrer, geralmente você ainda desejará acessar os logs do aplicativo. Dessa forma, os logs devem ter armazenamento e ciclo de vida separados, independentemente de nós, pods ou contêineres. Este conceito é chamado _cluster-level-logging_. O log no nível de cluster requer um back-end separado para armazenar, analisar e consultar logs. O kubernetes não fornece uma solução de armazenamento nativa para dados de log, mas você pode integrar muitas soluções de log existentes no cluster do Kubernetes.
|
||||
|
||||
|
||||
|
||||
<!-- body -->
|
||||
|
||||
As arquiteturas de log no nível de cluster são descritas no pressuposto de que um back-end de log esteja presente dentro ou fora do cluster. Se você não estiver interessado em ter o log no nível do cluster, ainda poderá encontrar a descrição de como os logs são armazenados e manipulados no nó para serem úteis.
|
||||
|
||||
## Log básico no Kubernentes
|
||||
|
||||
Nesta seção, você pode ver um exemplo de log básico no Kubernetes que gera dados para o fluxo de saída padrão(standard output stream). Esta demostração usa uma [especificação de pod](/examples/debug/counter-pod.yaml) com um contêiner que grava algum texto na saída padrão uma vez por segundo.
|
||||
|
||||
{{< codenew file="debug/counter-pod.yaml" >}}
|
||||
|
||||
Para executar este pod, use o seguinte comando:
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/debug/counter-pod.yaml
|
||||
```
|
||||
|
||||
A saída será:
|
||||
|
||||
```
|
||||
pod/counter created
|
||||
```
|
||||
|
||||
Para buscar os logs, use o comando `kubectl logs`, da seguinte maneira:
|
||||
|
||||
```shell
|
||||
kubectl logs counter
|
||||
```
|
||||
|
||||
A saída será:
|
||||
|
||||
```
|
||||
0: Mon Jan 1 00:00:00 UTC 2001
|
||||
1: Mon Jan 1 00:00:01 UTC 2001
|
||||
2: Mon Jan 1 00:00:02 UTC 2001
|
||||
...
|
||||
```
|
||||
|
||||
Você pode usar `kubectl logs` para recuperar logs de uma instanciação anterior de um contêiner com o sinalizador `--previous`, caso o contêiner tenha falhado. Se o seu pod tiver vários contêineres, você deverá especificar quais logs do contêiner você deseja acessar anexando um nome de contêiner ao comando. Veja a [documentação do `kubectl logs`](/docs/reference/generated/kubectl/kubectl-commands#logs) para mais destalhes.
|
||||
|
||||
## Logs no nível do Nó
|
||||
|
||||
|
||||
|
||||
Tudo o que um aplicativo em contêiner grava no `stdout` e `stderr` é tratado e redirecionado para algum lugar por dentro do mecanismo de contêiner. Por exemplo, o mecanismo de contêiner do Docker redireciona esses dois fluxos para [um driver de log](https://docs.docker.com/engine/admin/logging/overview), configurado no Kubernetes para gravar em um arquivo no formato json.
|
||||
|
||||
{{< note >}}
|
||||
O driver de log json do Docker trata cada linha como uma mensagem separada. Ao usar o driver de log do Docker, não há suporte direto para mensagens de várias linhas. Você precisa lidar com mensagens de várias linhas no nível do agente de log ou superior.
|
||||
{{< /note >}}
|
||||
|
||||
Por padrão, se um contêiner reiniciar, o kubelet manterá um contêiner terminado com seus logs. Se um pod for despejado do nó, todos os contêineres correspondentes também serão despejados, juntamente com seus logs.
|
||||
|
||||
Uma consideração importante no log no nível do nó está implementado a rotação de log, para que os logs não consumam todo o armazenamento disponível no nó. Atualmente, o Kubernentes não é responsável pela rotação de logs, mas uma ferramenta de deployment deve configurar uma solução para resolver isso.
|
||||
Por exemplo, nos clusters do Kubernetes, implementados pelo script `kube-up.sh`, existe uma ferramenta [`logrotate`](https://linux.die.net/man/8/logrotate) configurada para executar a cada hora. Você pode configurar um tempo de execução do contêiner para girar os logs do aplicativo automaticamente, por exemplo, usando o `log-opt` do Docker.
|
||||
No script `kube-up.sh`, a última abordagem é usada para imagem COS no GCP, e a anterior é usada em qualquer outro ambiente. Nos dois casos por padrão, a rotação é configurada para ocorrer quando o arquivo de log exceder 10MB.
|
||||
|
||||
Como exemplo, você pode encontrar informações detalhadas sobre como o `kube-up.sh` define o log da imagem COS no GCP no [script][cosconfigurehelper] correspondente.
|
||||
|
||||
Quando você executa [`kubectl logs`](/docs/reference/generated/kubectl/kubectl-commands#logs) como no exemplo de log básico acima, o kubelet no nó lida com a solicitação e lê diretamente do arquivo de log, retornando o conteúdo na resposta.
|
||||
|
||||
{{< note >}}
|
||||
Atualmente, se algum sistema externo executou a rotação, apenas o conteúdo do arquivo de log mais recente estará disponível através de `kubectl logs`. Por exemplo, se houver um arquivo de 10MB, o `logrotate` executa a rotação e existem dois arquivos, um com 10MB de tamanho e um vazio, o `kubectl logs` retornará uma resposta vazia.
|
||||
{{< /note >}}
|
||||
|
||||
[cosConfigureHelper]: https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/cluster/gce/gci/configure-helper.sh
|
||||
|
||||
### Logs de componentes do sistema
|
||||
|
||||
Existem dois tipos de componentes do sistema: aqueles que são executados em um contêiner e aqueles que não são executados em um contêiner. Por exemplo:
|
||||
|
||||
- O scheduler Kubernetes e o kube-proxy são executados em um contêiner.
|
||||
- O tempo de execução do kubelet e do contêiner, por exemplo, Docker, não é executado em contêineres.
|
||||
|
||||
Nas máquinas com systemd, o tempo de execução do kubelet e do container é gravado no journald. Se systemd não estiver presente, eles gravam em arquivos `.log` no diretório `/var/log`.
|
||||
Os componentes do sistema dentro dos contêineres sempre gravam no diretório `/var/log`, ignorando o mecanismo de log padrão. Eles usam a biblioteca de logs [klog][klog]. Você pode encontrar as convenções para a gravidade do log desses componentes nos [documentos de desenvolvimento sobre log](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/logging.md).
|
||||
|
||||
Da mesma forma que os logs de contêiner, os logs de componentes do sistema no diretório `/var/log` devem ser rotacionados. Nos clusters do Kubernetes criados pelo script `kube-up.sh`, esses logs são configurados para serem rotacionados pela ferramenta `logrotate` diariamente ou quando o tamanho exceder 100MB.
|
||||
|
||||
[klog]: https://github.com/kubernetes/klog
|
||||
|
||||
## Arquiteturas de log no nível de cluster
|
||||
|
||||
Embora o Kubernetes não forneça uma solução nativa para o log em nível de cluster, há várias abordagens comuns que você pode considerar. Aqui estão algumas opções:
|
||||
|
||||
- Use um agente de log no nível do nó que seja executado em todos os nós.
|
||||
- Inclua um contêiner sidecar dedicado para efetuar logging em um pod de aplicativo.
|
||||
- Envie logs diretamente para um back-end de dentro de um aplicativo.
|
||||
|
||||
### Usando um agente de log de nó
|
||||
|
||||
|
||||
|
||||
Você pode implementar o log em nível de cluster incluindo um _agente de log em nível de nó_ em cada nó. O agente de log é uma ferramenta dedicada que expõe logs ou envia logs para um back-end. Geralmente, o agente de log é um contêiner que tem acesso a um diretório com arquivos de log de todos os contêineres de aplicativos nesse nó.
|
||||
|
||||
Como o agente de log deve ser executado em todos os nós, é comum implementá-lo como uma réplica do DaemonSet, um pod de manifesto ou um processo nativo dedicado no nó. No entanto, as duas últimas abordagens são obsoletas e altamente desencorajadas.
|
||||
|
||||
O uso de um agente de log no nível do nó é a abordagem mais comum e incentivada para um cluster Kubernetes, porque ele cria apenas um agente por nó e não requer alterações nos aplicativos em execução no nó. No entanto, o log no nível do nó _funciona apenas para a saída padrão dos aplicativos e o erro padrão_.
|
||||
|
||||
O Kubernetes não especifica um agente de log, mas dois agentes de log opcionais são fornecidos com a versão Kubernetes: [Stackdriver Logging](/docs/user-guide/logging/stackdriver) para uso com o Google Cloud Platform e [Elasticsearch](/docs/user-guide/logging/elasticsearch). Você pode encontrar mais informações e instruções nos documentos dedicados. Ambos usam [fluentd](http://www.fluentd.org/) com configuração customizada como um agente no nó.
|
||||
|
||||
### Usando um contêiner sidecar com o agente de log
|
||||
|
||||
Você pode usar um contêiner sidecar de uma das seguintes maneiras:
|
||||
|
||||
- O container sidecar transmite os logs do aplicativo para seu próprio `stdout`.
|
||||
- O contêiner do sidecar executa um agente de log, configurado para selecionar logs de um contêiner de aplicativo.
|
||||
|
||||
#### Streaming sidecar conteiner
|
||||
|
||||
|
||||
|
||||
Fazendo com que seus contêineres de sidecar fluam para seus próprios `stdout` e `stderr`, você pode tirar proveito do kubelet e do agente de log que já executam em cada nó. Os contêineres sidecar lêem logs de um arquivo, socket ou journald. Cada contêiner sidecar individual imprime o log em seu próprio `stdout` ou `stderr` stream.
|
||||
|
||||
Essa abordagem permite separar vários fluxos de logs de diferentes partes do seu aplicativo, algumas das quais podem não ter suporte para gravar em `stdout` ou `stderr`. A lógica por trás do redirecionamento de logs é mínima, portanto dificilmente representa uma sobrecarga significativa. Além disso, como `stdout` e `stderr` são manipulados pelo kubelet, você pode usar ferramentas internas como o `kubectl logs`.
|
||||
|
||||
Considere o seguinte exemplo. Um pod executa um único contêiner e grava em dois arquivos de log diferentes, usando dois formatos diferentes. Aqui está um arquivo de configuração para o Pod:
|
||||
|
||||
{{< codenew file="admin/logging/two-files-counter-pod.yaml" >}}
|
||||
|
||||
Seria uma bagunça ter entradas de log de diferentes formatos no mesmo fluxo de logs, mesmo se você conseguisse redirecionar os dois componentes para o fluxo `stdout` do contêiner. Em vez disso, você pode introduzir dois contêineres sidecar. Cada contêiner sidecar pode direcionar um arquivo de log específico de um volume compartilhado e depois redirecionar os logs para seu próprio fluxo `stdout`.
|
||||
|
||||
Aqui está um arquivo de configuração para um pod que possui dois contêineres sidecar:
|
||||
|
||||
{{< codenew file="admin/logging/two-files-counter-pod-streaming-sidecar.yaml" >}}
|
||||
|
||||
Agora, quando você executa este pod, é possível acessar cada fluxo de log separadamente, executando os seguintes comandos:
|
||||
|
||||
```shell
|
||||
kubectl logs counter count-log-1
|
||||
```
|
||||
|
||||
```
|
||||
0: Mon Jan 1 00:00:00 UTC 2001
|
||||
1: Mon Jan 1 00:00:01 UTC 2001
|
||||
2: Mon Jan 1 00:00:02 UTC 2001
|
||||
...
|
||||
```
|
||||
|
||||
```shell
|
||||
kubectl logs counter count-log-2
|
||||
```
|
||||
|
||||
```
|
||||
Mon Jan 1 00:00:00 UTC 2001 INFO 0
|
||||
Mon Jan 1 00:00:01 UTC 2001 INFO 1
|
||||
Mon Jan 1 00:00:02 UTC 2001 INFO 2
|
||||
...
|
||||
```
|
||||
|
||||
O agente no nível do nó instalado em seu cluster coleta esses fluxos de logs automaticamente sem nenhuma configuração adicional. Se desejar, você pode configurar o agente para analisar as linhas de log, dependendo do contêiner de origem.
|
||||
|
||||
Observe que, apesar do baixo uso da CPU e da memória (ordem de alguns milicores por CPU e ordem de vários megabytes de memória), gravar logs em um arquivo e depois transmiti-los para o `stdout` pode duplicar o uso do disco. Se você tem um aplicativo que grava em um único arquivo, geralmente é melhor definir `/dev/stdout` como destino, em vez de implementar a abordagem de contêiner de transmissão no sidecar.
|
||||
|
||||
Os contêineres sidecar também podem ser usados para rotacionar arquivos de log que não podem ser rotacionados pelo próprio aplicativo. Um exemplo dessa abordagem é um pequeno contêiner executando `logrotate` periodicamente.
|
||||
No entanto, é recomendável usar o `stdout` e o `stderr` diretamente e deixar as políticas de rotação e retenção no kubelet.
|
||||
|
||||
#### Contêiner sidecar com um agente de log
|
||||
|
||||
|
||||
|
||||
Se o agente de log no nível do nó não for flexível o suficiente para sua situação, você poderá criar um contêiner secundário com um agente de log separado que você configurou especificamente para executar com seu aplicativo.
|
||||
|
||||
{{< note >}}
|
||||
O uso de um agente de log em um contêiner sidecar pode levar a um consumo significativo de recursos. Além disso, você não poderá acessar esses logs usando o comando `kubectl logs`, porque eles não são controlados pelo kubelet.
|
||||
{{< /note >}}
|
||||
|
||||
Como exemplo, você pode usar o [Stackdriver](/docs/tasks/debug-application-cluster/logging-stackdriver/), que usa fluentd como um agente de log. Aqui estão dois arquivos de configuração que você pode usar para implementar essa abordagem. O primeiro arquivo contém um [ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/) para configurar o fluentd.
|
||||
|
||||
{{< codenew file="admin/logging/fluentd-sidecar-config.yaml" >}}
|
||||
|
||||
{{< note >}}
|
||||
A configuração do fluentd está além do escopo deste artigo. Para obter informações sobre como configurar o fluentd, consulte a [documentação oficial do fluentd](http://docs.fluentd.org/).
|
||||
{{< /note >}}
|
||||
|
||||
O segundo arquivo descreve um pod que possui um contêiner sidecar rodando fluentemente.
|
||||
O pod monta um volume onde o fluentd pode coletar seus dados de configuração.
|
||||
|
||||
{{< codenew file="admin/logging/two-files-counter-pod-agent-sidecar.yaml" >}}
|
||||
|
||||
Depois de algum tempo, você pode encontrar mensagens de log na interface do Stackdriver.
|
||||
|
||||
Lembre-se de que este é apenas um exemplo e você pode realmente substituir o fluentd por qualquer agente de log, lendo de qualquer fonte dentro de um contêiner de aplicativo.
|
||||
|
||||
### Expondo logs diretamente do aplicativo
|
||||
|
||||
|
||||
|
||||
Você pode implementar o log no nível do cluster, expondo ou enviando logs diretamente de todos os aplicativos; no entanto, a implementação desse mecanismo de log está fora do escopo do Kubernetes.
|
||||
|
||||
|
||||
@@ -0,0 +1,250 @@
|
||||
---
|
||||
title: Conectividade do Cluster
|
||||
content_type: concept
|
||||
weight: 50
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
Conectividade é uma parte central do Kubernetes, mas pode ser desafiador
|
||||
entender exatamente como é o seu funcionamento esperado. Existem 4 problemas
|
||||
distintos em conectividade que devem ser tratados:
|
||||
|
||||
1. Comunicações contêiner-para-contêiner altamente acopladas: Isso é resolvido
|
||||
por {{< glossary_tooltip text="Pods" term_id="pod" >}} e comunicações através do `localhost`.
|
||||
2. Comunicações pod-para-pod: Esse é o foco primário desse documento.
|
||||
3. Comunicações pod-para-serviço (_service_): Isso é tratado em [Services](/docs/concepts/services-networking/service/).
|
||||
4. Comunicações Externas-para-serviços: Isso é tratado em [services](/docs/concepts/services-networking/service/).
|
||||
|
||||
<!-- body -->
|
||||
|
||||
Kubernetes é basicamente o compartilhamento de máquinas entre aplicações. Tradicionalmente,
|
||||
compartilhar máquinas requer a garantia de que duas aplicações não tentem utilizar
|
||||
as mesmas portas. Coordenar a alocação de portas entre múltiplos desenvolvedores é
|
||||
muito dificil de fazer em escala e expõe os usuários a problemas em nível do cluster e
|
||||
fora de seu controle.
|
||||
|
||||
A alocação dinâmica de portas traz uma série de complicações para o sistema - toda
|
||||
aplicação deve obter suas portas através de flags de configuração, os servidores de API
|
||||
devem saber como inserir números dinämicos de portas nos blocos de configuração, serviços
|
||||
precisam saber como buscar um ao outro, etc. Ao invés de lidar com isso, o Kubernetes
|
||||
faz de uma maneira diferente.
|
||||
|
||||
## O modelo de conectividade e rede do Kubernetes
|
||||
|
||||
Todo `Pod` obtém seu próprio endereço IP. Isso significa que vocë não precisa
|
||||
criar links explícitos entre os `Pods` e vocë quase nunca terá que lidar com o
|
||||
mapeamento de portas de contêineres para portas do host. Isso cria um modelo simples,
|
||||
retro-compatível onde os `Pods` podem ser tratados muito mais como VMs ou hosts
|
||||
físicos da perspectiva de alocação de portas, nomes, descobrimento de serviços
|
||||
(_service discovery_), balanceamento de carga, configuração de aplicações e migrações.
|
||||
|
||||
O Kubernetes impõe os seguintes requisitos fundamentais para qualquer implementação de
|
||||
rede (exceto qualquer política de segmentação intencional):
|
||||
* pods em um nó podem se comunicar com todos os pods em todos os nós sem usar _NAT_.
|
||||
* agentes em um nó (por exemplo o kubelet ou um serviço local) podem se comunicar com
|
||||
todos os Pods naquele nó.
|
||||
|
||||
Nota: Para as plataformas que suportam `Pods` executando na rede do host (como o Linux):
|
||||
|
||||
* pods alocados na rede do host de um nó podem se comunicar com todos os pods
|
||||
em todos os nós sem _NAT_.
|
||||
|
||||
Esse modelo não só é menos complexo, mas é principalmente compatível com o
|
||||
desejo do Kubernetes de permitir a portabilidade com baixo esforço de aplicações
|
||||
de VMs para contêineres. Se a sua aplicação executava anteriormente em uma VM, sua VM
|
||||
possuía um IP e podia se comunicar com outras VMs no seu projeto. Esse é o mesmo
|
||||
modelo básico.
|
||||
|
||||
Os endereços de IP no Kubernetes existem no escopo do `Pod` - contêineres em um `Pod`
|
||||
compartilham o mesmo _network namespace_ - incluíndo seu endereço de IP e MAC.
|
||||
Isso significa que contêineres que compõem um `Pod` podem se comunicar entre eles
|
||||
através do endereço `localhost` e respectivas portas. Isso também significa que
|
||||
contêineres em um mesmo `Pod` devem coordenar a alocação e uso de portas, o que não
|
||||
difere do modelo de processos rodando dentro de uma mesma VM. Isso é chamado de
|
||||
modelo "IP-por-pod".
|
||||
|
||||
Como isso é implementado é um detalhe do agente de execução de contêiner em uso.
|
||||
|
||||
É possível solicitar uma porta no nó que será encaminhada para seu `Pod` (chamado
|
||||
de _portas do host_), mas isso é uma operação muito específica. Como esse encaminhamento
|
||||
é implementado é um detalhe do agente de execução do contêiner. O `Pod` mesmo
|
||||
desconhece a existência ou não de portas do host.
|
||||
|
||||
## Como implementar o modelo de conectividade do Kubernetes
|
||||
|
||||
Existe um número de formas de implementar esse modelo de conectividade. Esse
|
||||
documento não é um estudo exaustivo desses vários métodos, mas pode servir como
|
||||
uma introdução de várias tecnologias e serve como um ponto de início.
|
||||
|
||||
A conectividade no Kubernetes é fornecida através de plugins de
|
||||
{{< glossary_tooltip text="CNIs" term_id="cni" >}}
|
||||
|
||||
As seguintes opções estão organizadas alfabeticamente e não implicam preferência por
|
||||
qualquer solução.
|
||||
|
||||
{{% thirdparty-content %}}
|
||||
|
||||
### Antrea
|
||||
|
||||
O projeto [Antrea](https://github.com/vmware-tanzu/antrea) é uma solução de
|
||||
conectividade para Kubernetes que pretende ser nativa. Ela utiliza o Open vSwitch
|
||||
na camada de conectividade de dados. O Open vSwitch é um switch virtual de alta
|
||||
performance e programável que suporta Linux e Windows. O Open vSwitch permite
|
||||
ao Antrea implementar políticas de rede do Kubernetes (_NetworkPolicies_) de
|
||||
uma forma muito performática e eficiente.
|
||||
|
||||
Graças à característica programável do Open vSwitch, o Antrea consegue implementar
|
||||
uma série de funcionalidades de rede e segurança.
|
||||
|
||||
### AWS VPC CNI para Kubernetes
|
||||
|
||||
O [AWS VPC CNI](https://github.com/aws/amazon-vpc-cni-k8s) oferece conectividade
|
||||
com o AWS Virtual Private Cloud (VPC) para clusters Kubernetes. Esse plugin oferece
|
||||
alta performance e disponibilidade e baixa latência. Adicionalmente, usuários podem
|
||||
aplicar as melhores práticas de conectividade e segurança existentes no AWS VPC
|
||||
para a construção de clusters Kubernetes. Isso inclui possibilidade de usar o
|
||||
_VPC flow logs_, políticas de roteamento da VPC e grupos de segurança para isolamento
|
||||
de tráfego.
|
||||
|
||||
O uso desse plugin permite aos Pods no Kubernetes ter o mesmo endereço de IP dentro do
|
||||
pod como se eles estivessem dentro da rede do VPC. O CNI (Container Network Interface)
|
||||
aloca um _Elastic Networking Interface_ (ENI) para cada nó do Kubernetes e usa uma
|
||||
faixa de endereços IP secundário de cada ENI para os Pods no nó. O CNI inclui
|
||||
controles para pré alocação dos ENIs e endereços IP para um início mais rápido dos
|
||||
pods e permite clusters com até 2,000 nós.
|
||||
|
||||
Adicionalmente, esse CNI pode ser utilizado junto com o [Calico](https://docs.aws.amazon.com/eks/latest/userguide/calico.html)
|
||||
para a criação de políticas de rede (_NetworkPolicies_). O projeto AWS VPC CNI
|
||||
tem código fonte aberto com a [documentação no Github](https://github.com/aws/amazon-vpc-cni-k8s).
|
||||
|
||||
### Azure CNI para o Kubernetes
|
||||
[Azure CNI](https://docs.microsoft.com/en-us/azure/virtual-network/container-networking-overview) é um
|
||||
plugin de [código fonte aberto](https://github.com/Azure/azure-container-networking/blob/master/docs/cni.md)
|
||||
que integra os Pods do Kubernetes com uma rede virtual da Azure (também conhecida como VNet)
|
||||
provendo performance de rede similar à de máquinas virtuais no ambiente. Os Pods
|
||||
podem se comunicar com outras VNets e com ambientes _on-premises_ com o uso de
|
||||
funcionalidades da Azure, e também podem ter clientes com origem dessas redes.
|
||||
Os Pods podem acessar serviços da Azure, como armazenamento e SQL, que são
|
||||
protegidos por _Service Endpoints_ e _Private Link_. Você pode utilizar as políticas
|
||||
de segurança e roteamento para filtrar o tráfico do Pod. O plugin associa IPs da VNet
|
||||
para os Pods utilizando um pool de IPs secundário pré-configurado na interface de rede
|
||||
do nó Kubernetes.
|
||||
|
||||
O Azure CNI está disponível nativamente no [Azure Kubernetes Service (AKS)](https://docs.microsoft.com/en-us/azure/aks/configure-azure-cni).
|
||||
|
||||
### Calico
|
||||
|
||||
[Calico](https://docs.projectcalico.org/) é uma solução de conectividade e
|
||||
segurança para contêineres, máquinas virtuais e serviços nativos em hosts. O
|
||||
Calico suporta múltiplas camadas de conectividade/dados, como por exemplo:
|
||||
uma camada Linux eBPF nativa, uma camada de conectividade baseada em conceitos
|
||||
padrão do Linux e uma camada baseada no HNS do Windows. O calico provê uma
|
||||
camada completa de conectividade e rede, mas também pode ser usado em conjunto com
|
||||
[CNIs de provedores de nuvem](https://docs.projectcalico.org/networking/determine-best-networking#calico-compatible-cni-plugins-and-cloud-provider-integrations)
|
||||
para permitir a criação de políticas de rede.
|
||||
|
||||
### Cilium
|
||||
|
||||
[Cilium](https://github.com/cilium/cilium) é um software de código fonte aberto
|
||||
para prover conectividade e segurança entre contêineres de aplicação. O Cilium
|
||||
pode lidar com tráfego na camada de aplicação (ex. HTTP) e pode forçar políticas
|
||||
de rede nas camadas L3-L7 usando um modelo de segurança baseado em identidade e
|
||||
desacoplado do endereçamento de redes, podendo inclusive ser utilizado com outros
|
||||
plugins CNI.
|
||||
|
||||
### Flannel
|
||||
|
||||
[Flannel](https://github.com/coreos/flannel#flannel) é uma camada muito simples
|
||||
de conectividade que satisfaz os requisitos do Kubernetes. Muitas pessoas
|
||||
reportaram sucesso em utilizar o Flannel com o Kubernetes.
|
||||
|
||||
### Google Compute Engine (GCE)
|
||||
|
||||
Para os scripts de configuração do Google Compute Engine, [roteamento
|
||||
avançado](https://cloud.google.com/vpc/docs/routes) é usado para associar
|
||||
para cada VM uma sub-rede (o padrão é `/24` - 254 IPs). Qualquer tráfico direcionado
|
||||
para aquela sub-rede será roteado diretamente para a VM pela rede do GCE. Isso é
|
||||
adicional ao IP principal associado à VM, que é mascarado para o acesso à Internet.
|
||||
Uma _brige_ Linux (chamada `cbr0`) é configurada para existir naquela sub-rede, e é
|
||||
configurada no docker através da opção `--bridge`.
|
||||
|
||||
O Docker é iniciado com:
|
||||
|
||||
|
||||
```shell
|
||||
DOCKER_OPTS="--bridge=cbr0 --iptables=false --ip-masq=false"
|
||||
```
|
||||
|
||||
Essa _bridge_ é criada pelo Kubelet (controlada pela opção `--network-plugin=kubenet`)
|
||||
de acordo com a informação `.spec.podCIDR` do Nó.
|
||||
|
||||
O Docker irá agora alocar IPs do bloco `cbr-cidr`. Contêineres podem alcançar
|
||||
outros contêineres e nós através da interface `cbr0`. Esses IPs são todos roteáveis
|
||||
dentro da rede do projeto do GCE.
|
||||
|
||||
O GCE mesmo não sabe nada sobre esses IPs, então não irá mascará-los quando tentarem
|
||||
se comunicar com a internet. Para permitir isso uma regra de IPTables é utilizada para
|
||||
mascarar o tráfego para IPs fora da rede do projeto do GCE (no exemplo abaixo, 10.0.0.0/8):
|
||||
|
||||
```shell
|
||||
iptables -t nat -A POSTROUTING ! -d 10.0.0.0/8 -o eth0 -j MASQUERADE
|
||||
```
|
||||
|
||||
Por fim, o encaminhamento de IP deve ser habilitado no Kernel de forma a processar
|
||||
os pacotes vindos dos contêineres:
|
||||
|
||||
```shell
|
||||
sysctl net.ipv4.ip_forward=1
|
||||
```
|
||||
|
||||
O resultado disso tudo é que `Pods` agora podem alcançar outros `Pods` e podem também
|
||||
se comunicar com a Internet.
|
||||
|
||||
### Kube-router
|
||||
|
||||
[Kube-router](https://github.com/cloudnativelabs/kube-router) é uma solução construída
|
||||
que visa prover alta performance e simplicidade operacional. Kube-router provê um
|
||||
proxy de serviços baseado no [LVS/IPVS](https://www.linuxvirtualserver.org/software/ipvs.html),
|
||||
uma solução de comunicação pod-para-pod baseada em encaminhamento de pacotes Linux e sem camadas
|
||||
adicionais, e funcionalidade de políticas de redes baseadas no IPTables/IPSet.
|
||||
|
||||
### Redes L2 e bridges Linux
|
||||
|
||||
Se você tem uma rede L2 "burra", como um switch em um ambiente "bare-metal",
|
||||
você deve conseguir fazer algo similar ao ambiente GCE explicado acima.
|
||||
Note que essas instruções foram testadas casualmente - parece funcionar, mas
|
||||
não foi propriamente testado. Se você conseguir usar essa técnica e aperfeiçoar
|
||||
o processo, por favor nos avise!!
|
||||
|
||||
Siga a parte _"With Linux Bridge devices"_ desse
|
||||
[tutorial super bacana](https://blog.oddbit.com/2014/08/11/four-ways-to-connect-a-docker/) do
|
||||
Lars Kellogg-Stedman.
|
||||
|
||||
### Multus (Plugin multi redes) {#multus}
|
||||
|
||||
[Multus](https://github.com/Intel-Corp/multus-cni) é um plugin Multi CNI para
|
||||
suportar a funcionalidade multi redes do Kubernetes usando objetos baseados em {{< glossary_tooltip text="CRDs" term_id="CustomResourceDefinition" >}}.
|
||||
|
||||
Multus suporta todos os [plugins referência](https://github.com/containernetworking/plugins) (ex. [Flannel](https://github.com/containernetworking/plugins/tree/master/plugins/meta/flannel),
|
||||
[DHCP](https://github.com/containernetworking/plugins/tree/master/plugins/ipam/dhcp),
|
||||
[Macvlan](https://github.com/containernetworking/plugins/tree/master/plugins/main/macvlan))
|
||||
que implementam a especificação de CNI e plugins de terceiros
|
||||
(ex. [Calico](https://github.com/projectcalico/cni-plugin), [Weave](https://github.com/weaveworks/weave),
|
||||
[Cilium](https://github.com/cilium/cilium), [Contiv](https://github.com/contiv/netplugin)).
|
||||
Adicionalmente, Multus suporta cargas de trabalho no Kubernetes que necessitem de funcionalidades como
|
||||
[SRIOV](https://github.com/hustcat/sriov-cni), [DPDK](https://github.com/Intel-Corp/sriov-cni),
|
||||
[OVS-DPDK & VPP](https://github.com/intel/vhost-user-net-plugin).
|
||||
|
||||
### OVN (Open Virtual Networking)
|
||||
|
||||
OVN é uma solução de virtualização de redes de código aberto desenvolvido pela
|
||||
comunidade Open vSwitch. Permite a criação de switches lógicos, roteadores lógicos,
|
||||
listas de acesso, balanceadores de carga e mais, para construir diferences topologias
|
||||
de redes virtuais. Esse projeto possui um plugin específico para o Kubernetes e a
|
||||
documentação em [ovn-kubernetes](https://github.com/openvswitch/ovn-kubernetes).
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
Design inicial do modelo de conectividade do Kubernetes e alguns planos futuros
|
||||
estão descritos com maiores detalhes no
|
||||
[documento de design de redes](https://git.k8s.io/community/contributors/design-proposals/network/networking.md).
|
||||
Reference in New Issue
Block a user