Olá, habrozhiteli! Kubernetes é um dos elementos-chave do ecossistema moderno de nuvens. Essa tecnologia fornece a confiabilidade, escalabilidade e resiliência da virtualização de contêiner. John Arundel e Justin Domingus conversam sobre o ecossistema Kubernetes e apresentam soluções comprovadas para os problemas do dia a dia. Passo a passo, você criará seu próprio aplicativo baseado em nuvem e criará a infraestrutura para suportá-lo, configurará o ambiente de desenvolvimento e o pipeline de implantação contínua, o que será útil para você ao trabalhar nos aplicativos a seguir.• Comece a usar contêineres e Kubernetes a partir do zero: nenhuma experiência especial é necessária para aprender o tópico. • Inicie seus próprios clusters ou escolha um serviço Kubernetes gerenciado da Amazon, Google, etc. • Use o Kubernetes para gerenciar o ciclo de vida do contêiner e o consumo de recursos. • Otimize os clusters para obter custo, desempenho, resiliência, energia e escalabilidade. • Aprenda as melhores ferramentas para desenvolver, testar e implantar seus aplicativos. • Aproveite as práticas atuais da indústria para segurança e controle. • Implemente os princípios de DevOps em sua empresa para que as equipes de desenvolvimento se tornem mais flexíveis, rápidas e eficientes.Para quem é o livro?
O livro é mais relevante para funcionários dos departamentos de administração responsáveis por servidores, aplicativos e serviços, bem como para desenvolvedores envolvidos na criação de novos serviços em nuvem ou na migração de aplicativos existentes para o Kubernetes e a nuvem. Não se preocupe, não é necessário saber como trabalhar com Kubernetes e recipientes - ensinaremos tudo.Os usuários experientes do Kubernetes também encontrarão muito a descobrir: tópicos como RBAC, implantação contínua, gerenciamento de dados confidenciais e observabilidade são abordados detalhadamente. Esperamos que as páginas do livro certamente tenham algo interessante para você, independentemente de suas habilidades e experiência.Que perguntas o livro responde
Durante o planejamento e a redação do livro, discutimos tecnologias de nuvem e Kubernetes com centenas de pessoas, conversamos com líderes e especialistas do setor, bem como com iniciantes absolutos. A seguir, são apresentadas perguntas individuais às quais eles gostariam de ver respostas nesta publicação.- “Estou interessado em saber por que o tempo deve ser gasto com essa tecnologia. Que problemas ela ajudará a mim e à minha equipe?
- “Kubernetes parece interessante, mas tem um limite bastante alto de entrada. Preparar um exemplo simples não é difícil, mas administração e depuração adicionais são assustadoras. "Gostaríamos de obter conselhos confiáveis sobre como as pessoas gerenciam os clusters Kubernetes na vida real e que problemas provavelmente encontraremos".
- “O conselho subjetivo seria útil. O ecossistema Kubernetes oferece às equipes iniciantes muitas opções para escolher. Quando a mesma coisa pode ser feita de várias maneiras, como entender qual é a melhor? Como fazer uma escolha? ”
E, provavelmente, a mais importante de todas as perguntas:- "Como usar o Kubernetes sem atrapalhar minha empresa?"
Excerto. Objetos de configuração e segredo
A capacidade de separar a lógica do aplicativo Kubernetes de sua configuração (ou seja, de quaisquer valores ou configurações que possam mudar com o tempo) é muito útil. Os valores de configuração geralmente incluem configurações para um ambiente específico, os endereços DNS de serviços de terceiros e credenciais para autenticação.Obviamente, tudo isso pode ser colocado diretamente no código, mas essa abordagem não é suficientemente flexível. Por exemplo, para alterar o valor da configuração, você precisará remontar e implantar seu código. Uma solução muito melhor seria separar a configuração do código e lê-la das variáveis de arquivo ou ambiente.O Kubernetes fornece várias maneiras diferentes de gerenciar sua configuração. Primeiro, você pode passar valores para o aplicativo através das variáveis de ambiente especificadas na especificação do shell do pod (consulte a seção "Variáveis de ambiente" na página 192). Em segundo lugar, os dados de configuração podem ser armazenados diretamente no Kubernetes usando os objetos ConfigMap e Secret.Neste capítulo, examinaremos esses objetos em detalhes e consideraremos algumas abordagens práticas para gerenciar configurações e dados confidenciais usando um aplicativo de demonstração.Atualizando shells de pods ao alterar configurações
Imagine que seu cluster possui uma implantação e você deseja alterar alguns valores no seu ConfigMap. Se você usar o gráfico Helm (consulte a seção “Helm: Gerenciador de Pacotes para Kubernetes” na página 102), poderá detectar uma alteração na configuração e reiniciar seus shells de pod com um truque elegante. Adicione a seguinte anotação à sua especificação de implantação:checksum/config: {{ include (print $.Template.BasePath "/configmap.yaml") .
| sha256sum }}
Agora, o modelo de implantação contém a soma de verificação dos parâmetros de configuração: quando os parâmetros são alterados, a soma é atualizada. Se você executar o comando helm upgrade, o Helm descobrirá que a especificação de implantação foi alterada e reiniciará todos os shells de pod.Dados Confidenciais na Kubernetes
Já sabemos que o objeto ConfigMap fornece um mecanismo flexível para armazenar e acessar dados de configuração em um cluster. No entanto, a maioria dos aplicativos possui informações secretas e confidenciais: por exemplo, senhas ou chaves de API. Também pode ser armazenado no ConfigMap, mas essa solução não é ideal.Em vez disso, o Kubernetes oferece um tipo especial de objeto projetado para armazenar dados confidenciais: Segredo. A seguir, consideramos um exemplo de como esse objeto pode ser aplicado em nosso aplicativo de demonstração.Para começar, dê uma olhada no manifesto do Kubernetes para o objeto Secret (consulte hello-secret-env / k8s / secret.yaml):apiVersion: v1
kind: Secret
metadata:
name: demo-secret
stringData:
magicWord: xyzzy
Neste exemplo, a chave privada magicWord é xyzzy (en.wikipedia.org/wiki/Xyzzy_(computing)). A palavra xyzzy é geralmente muito útil no mundo dos computadores. Semelhante ao ConfigMap, você pode colocar muitas chaves e valores em um objeto Secreto. Aqui, por simplicidade, usamos apenas um par de valores-chave.Usando objetos secretos como variáveis de ambiente
Como o ConfigMap, o objeto Secreto pode ser disponibilizado no contêiner como variáveis de ambiente ou como um arquivo em seu disco. No exemplo a seguir, atribuiremos à variável de ambiente o valor de Secret:spec:
containers:
- name: demo
image: cloudnatived/demo:hello-secret-env
ports:
- containerPort: 8888
env:
- name: GREETING
valueFrom:
secretKeyRef:
name: demo-secret
key: magicWord
Execute o seguinte comando no repositório de demonstração para aplicar manifestos:kubectl apply -f hello-secret-env/k8s/
deployment.extensions "demo" configured
secret "demo-secret" created
Como antes, redirecione a porta local para a implantação para ver o resultado no seu navegador:kubectl port-forward deploy/demo 9999:8888
Forwarding from 127.0.0.1:9999 -> 8888
Forwarding from [::1]:9999 -> 8888
Quando você abre o endereço do host local : 9999 / você deve ver o seguinte:The magic word is "xyzzy"Gravando objetos secretos em arquivos
Neste exemplo, anexaremos o objeto Secreto ao contêiner como um arquivo. O código está na pasta hello-secret-file do repositório demo.Para conectar o Secret como um arquivo, usaremos a seguinte implantação:spec:
containers:
- name: demo
image: cloudnatived/demo:hello-secret-file
ports:
- containerPort: 8888
volumeMounts:
- name: demo-secret-volume
mountPath: "/secrets/"
readOnly: true
volumes:
- name: demo-secret-volume
secret:
secretName: demo-secret
Como na subseção “Criando arquivos de configuração a partir de objetos do ConfigMap” na p. 240, criamos um volume (neste caso, demo-secret-volume) e o conectamos ao contêiner na seção de especificação volumeMounts. MountPath é / secrets; portanto, o Kubernetes criará um arquivo para cada par de valores-chave definido no objeto Secreto nesta pasta.Em nosso exemplo, definimos apenas um par de valores-chave chamado magicWord; portanto, o manifesto criará um único arquivo / secrets / magicWord com dados confidenciais no contêiner que é somente leitura.Se você aplicar esse manifesto da mesma maneira que no exemplo anterior, deverá obter o mesmo resultado:The magic word is "xyzzy"Lendo objetos secretos
Na seção anterior, usamos o comando kubectl description para exibir o conteúdo do ConfigMap. Você pode fazer o mesmo com o Secret?kubectl describe secret/demo-secret
Name: demo-secret
Namespace: default
Labels: <none>
Annotations:
Type: Opaque
Data
====
magicWord: 5 bytes
Observe que os dados em si não são exibidos. Objetos secretos no Kubernetes são do tipo Opaco: isso significa que seu conteúdo não é mostrado na saída do kubectl description, nos lançamentos contábeis manuais e no terminal, tornando impossível a revelação acidental de informações confidenciais.Para visualizar a versão codificada de dados confidenciais no formato YAML, use o comando kubectl get:kubectl get secret/demo-secret -o yaml
apiVersion: v1
data:
magicWord: eHl6enk=
kind: Secret
metadata:
...
type: Opaque
base64
O que é eHl6enk =, que é completamente diferente do nosso valor original? Na verdade, este é um objeto secreto, representado na codificação base64. Base64 é um esquema de codificação para dados binários arbitrários como uma sequência de caracteres.Como as informações confidenciais podem ser binárias e inacessíveis para saída (como, por exemplo, no caso da chave de criptografia TLS), os objetos secretos são sempre armazenados no formato base64.O texto beHl6enk = é a versão codificada em base64 da nossa palavra secreta xyzzy. Você pode verificar isso se executar o comando base64 --decode no terminal:echo "eHl6enk=" | base64 --decode
xyzzy
Portanto, apesar do Kubernetes proteger você contra a exibição acidental de dados confidenciais nos arquivos de terminal ou de log, se você tiver o direito de ler objetos Secretos em um espaço para nome específico, esses dados poderão ser recebidos no formato base64 e posteriormente decodificados.Se você precisar codificar algum texto em base64 (por exemplo, para colocá-lo em Segredo), use o comando base64 sem argumentos:echo xyzzy | base64
eHl6enkK
Acesso a objetos secretos
Quem pode ler e editar objetos secretos? Isso é determinado pelo RBAC, o mecanismo de controle de acesso (discutiremos detalhadamente na seção “Introdução ao controle de acesso baseado em funções” na página 258). Se você usar um cluster no qual o sistema RBAC está ausente ou não está ativado, todos os seus objetos Secretos estarão acessíveis a todos os usuários e contêineres (explicaremos mais adiante que você não deve ter nenhum cluster industrial sem o RBAC).Criptografia passiva de dados
E aqueles que têm acesso ao banco de dados etcd, no qual o Kubernetes armazena todas as suas informações? Eles podem ler dados confidenciais sem o direito de ler objetos secretos por meio da API?A partir da versão 1.7, o Kubernetes suporta criptografia passiva de dados. Isso significa que as informações confidenciais contidas no etcd são armazenadas no disco em formato criptografado e não podem ser lidas nem mesmo por quem tem acesso direto ao banco de dados. Para descriptografá-lo, você precisa de uma chave que apenas o servidor da API Kubernetes tenha. Em um cluster configurado corretamente, a criptografia passiva deve estar ativada.Verifique se a criptografia passiva funciona no seu cluster, fazendo o seguinte:kubectl describe pod -n kube-system -l component=kube-apiserver |grep encryption
--experimental-encryption-provider-config=...
Se você não vir o sinalizador experimental-encryption-provider-config, a criptografia passiva não estará ativada. Ao usar o Google Kubernetes Engine ou outros serviços de gerenciamento Kubernetes, seus dados são criptografados usando um mecanismo diferente; portanto, o sinalizador estará ausente. Verifique com seu provedor Kubernetes para ver se o conteúdo do etcd está criptografado.Armazenamento Confidencial de Dados
Existem recursos do Kubernetes que nunca devem ser removidos de um cluster: por exemplo, objetos secretos especialmente importantes. Você pode proteger o recurso de ser excluído usando a anotação fornecida pelo Helm Manager:kind: Secret
metadata:
annotations:
"helm.sh/resource-policy": keep
Estratégias de gerenciamento de objetos secretos
No exemplo da seção anterior, os dados confidenciais foram protegidos contra acesso não autorizado imediatamente após serem armazenados no cluster. Mas nos arquivos de manifesto, eles foram armazenados em texto sem formatação.Você nunca deve colocar informações confidenciais nos arquivos que estão no sistema de controle de versão. Como administrar e armazenar essas informações com segurança antes de aplicá-las a um cluster Kubernetes?Você pode escolher quaisquer ferramentas ou estratégias para trabalhar com dados confidenciais em seus aplicativos, mas ainda precisa responder pelo menos às seguintes perguntas.- Onde armazenar dados confidenciais para que sejam altamente acessíveis?
- Como disponibilizar dados confidenciais para seus aplicativos ativos?
- , ?
John Arundel é consultor com 30 anos de experiência na indústria de computadores. Ele escreveu vários livros e trabalha com muitas empresas de diferentes países, aconselhando-as sobre infraestrutura baseada em nuvem e Kubernetes. Em seu tempo livre, ele gosta de surfar, dispara uma boa pistola e toca piano amadoramente. Vive em uma casa fabulosa na Cornualha, Inglaterra.Justin Domingus é um engenheiro de administração de sistemas que trabalha em um ambiente DevOps com Kubernetes e tecnologias em nuvem. Ele gosta de passar o tempo ao ar livre, tomar café, pegar caranguejos e sentar-se ao computador. Vive em Seattle, Washington, junto com um gato maravilhoso e uma esposa ainda mais maravilhosa e a melhor amiga de meio período Adrienne.»Mais informações sobre o livro podem ser encontradas no site da editora» Conteúdo» Trecho docupom Khabrozhiteley de 25% de desconto no cupom - KubernetesApós o pagamento da versão impressa do livro, um livro eletrônico é enviado por e-mail.