Autores do artigo: Ana Cunha, José Yapur,
Defensor do desenvolvedor, Amazon Web Services
Tradutor do artigo: Zheng Yubin
Desenvolvedor Evangelista Sênior de Tecnologia em Nuvem da Amazon
No artigo anterior, Picturesocial | Development in Practice: How to Containerize Your App in 15 Minutes , discutimos contêineres e as etapas necessárias para conteinerizar seu aplicativo. Criar um contêiner sem pensar onde ele será implantado, como colocar sua casa em um contêiner flutuando no oceano, parece romântico e assustador. Se você quer viver uma vida segura e confortável, definitivamente precisa de eletricidade, água, gás, comida, coleta de lixo... e de preferência algumas atividades sociais.
Neste artigo, aprenderemos sobre o Kubernetes, uma ferramenta de compilação de contêineres que ajuda você a transformar um contêiner flutuando no mar em um lar seguro e confortável. Esta é uma parte muito importante da arquitetura do Picturesocial.
Picturesocial terá várias APIs e queremos que elas sejam mantidas separadas umas das outras em diferentes estágios de manutenção, implantação e desenvolvimento. Portanto, decidimos usar uma arquitetura conteinerizada.
Realmente não é tão complicado, apenas significa que você está usando um contêiner e um compilador de contêiner. O Container Orchestrator lida com todos os contêineres, réplicas de contêineres, rede, armazenamento e componentes de infraestrutura necessários para a orquestração. Para orquestradores de contêineres, o mais popular hoje é o Kubernetes. Isso se deve à sua comunidade ativa, suporte técnico contínuo e eficaz e rico ecossistema.
Chamamos Kubernetes k8s, que é um orquestrador de contêineres de código aberto cujo ecossistema está se desenvolvendo rápida e extensivamente. O Kubernetes não apenas ajuda os desenvolvedores a gerenciar o escalonamento de contêineres e o tratamento de falhas, mas também ajuda os desenvolvedores a:
Descoberta de serviço e balanceamento de carga: permite balanceamento de carga do tráfego de rede entre contêineres e infraestrutura e descoberta de novas cópias de contêineres ou contêineres com falha a serem removidos.
Implantação e reversão automatizadas: você pode escolher como deseja implantar seus contêineres, como lidar com atualizações e como se proteger contra o tempo de inatividade devido a atualizações, falhas de infraestrutura ou erros de contêiner.
Empacotamento automático: o Kubernetes usará, otimizará e ajustará o poder de computação disponível de acordo com os limites definidos.
Autocorreção: se um contêiner falhar, o Kubernetes reiniciará o contêiner até que esteja íntegro ou o excluirá e criará um novo.
Não é fácil implantar e operar seu próprio cluster Kubernetes do zero, e você precisa ter um conhecimento profundo de Kubernetes, Linux, virtualização, rede, segurança e outras tecnologias. Portanto, a Amazon Cloud Technology fornece aos desenvolvedores os serviços Amazon Elastic Kubernetes (Amazon EKS). Esta é uma solução Kubernetes totalmente gerenciada, que reduz a complexidade da infraestrutura dos desenvolvedores e da configuração e gerenciamento do Kubernetes, garantindo a segurança do ambiente operacional. Os patches de segurança são aplicados automaticamente aos clusters em execução.
// Manifesto (também conhecido como YAML)
Os desenvolvedores podem implementar a comunicação local com o cluster Kubernetes de duas maneiras: Kubectl (Kube Control) ou chamando a API REST. Ambos os métodos usam uma estrutura YAML comum para enviar cargas para o cluster.
Nós o chamamos de manifesto e contém instruções detalhadas para:
o que estamos implantando
como o implantamos
o que expor
como o expomos
Abaixo está um exemplo de modelo YAML que podemos usar para muitos aplicativos de contêiner. O seguinte apresenta o conceito básico de manifesto:
// Rótulo/rótulo
Tudo dentro do Kubernetes precisa de um rótulo, é assim que identificamos todos os recursos no cluster e é como dizemos ao Kubernetes o que procurar usando comandos Kubectl ou solicitações de API.
// cápsulas
Pods são os menores objetos no Kubernetes e onde existem contêineres.
Um pod pode ter vários contêineres, mas uma relação de 1 para 1 é recomendada para evitar pontos de falha altamente acoplados. Alguns recursos importantes a serem observados sobre os pods são:
Os pods são efêmeros, o que significa que, se um contêiner interno falhar, o resultado mais provável é que o Kubernetes exclua o pod e crie um novo. Quando implantamos uma nova versão de um contêiner, normalmente um novo pod é criado e o Kubernetes se encarregará de atualizar o back-end do serviço de balanceamento.
Uma imagem de contêiner deve ser especificada. É definido como nome do repositório e nome da imagem, por exemplo: [aws account id].dkr.ecr.[aws region].amazonaws.com/imageName
Definir limites de recursos é uma prática recomendada. Temos dois tipos de limites:
1. Solicitações: é isso que o Pod é garantido. É como pedir uma pizza com garantia de entrega em 30 minutos. Isso não significa que a pizza não pode ser entregue mais rápido, é apenas um indicador de quantos pedidos um único entregador pode atender. Para Requests, eles especificam garantias para a alocação de recursos computacionais no cluster. Se você tiver apenas um Pod, há uma boa chance de obter mais recursos de computação do que o garantido;
2. Limits/Limits: Este é o limite rígido para qualquer Pod. Se especificarmos limites, o Pod não consumirá mais do que os limites especificados, mesmo que haja recursos disponíveis. Usando o mesmo exemplo do entregador, é como dizer a eles que em hipótese alguma eles podem entregar mais de 3 pizzas ao mesmo tempo.
As unidades que normalmente usamos no Kubernetes são:
1. Mebibytes/Megabyte (MiB) expresso como Mi: Usado como uma medida de memória. Para converter de miB para MB, você precisa de miB x 1,049;
2. Millicores(mc) denotado como m: Usado como medida de CPU. 1 núcleo de CPU é expresso como 1000 milicores. Por exemplo, 250m é ¼ núcleo da CPU.
// ReplicaSet
Os pods deveriam ter sido replicados com base em métricas diferentes, como CPU ou consumo de memória. Também é possível definir um valor estático conforme mostrado no exemplo abaixo quando estamos configurando apenas 1 réplica. Chamamos esse conjunto de réplicas e regras de dimensionamento automático de ReplicaSet.
Não recomendamos que os desenvolvedores chamem os pods diretamente. Como discutimos antes, eles são efêmeros, o que significa que os nomes dos pods e IPs são dinâmicos.
É aqui que entra o Serviço. Ele fornece um único ponto de acesso para invocar um ou mais Pods do mesmo ReplicaSet. Vamos nos concentrar em dois tipos de Serviços:
LoadBalancer/Load Balancer: Este tipo de serviço é usado quando precisamos expor o ReplicaSet para fora do cluster Kubernetes. Pode ser uma rede privada ou pode ser exposta à Internet. No que diz respeito ao Amazon EKS, há duas coisas a serem observadas:
1. Os nomes dos serviços devem sempre começar com uma letra e usar "-" como separador, por exemplo: picturesocial-pictures;
2. Para balanceadores de carga privados: deve haver uma anotação de serviço. O exemplo a seguir especifica que o serviço é exposto apenas internamente:
clusterIP: Este serviço é usado quando precisamos fornecer aos usuários ReplicaSets no cluster Kubernetes. Essa também é a abordagem mais comum, pois é mais segura se você mantiver os pods dentro dos limites do cluster. Dessa forma, mais camadas de segurança podem ser adicionadas ao uso de Pods, como controladores de entrada, autenticação bidirecional, gateways de API etc. Explicaremos mais sobre esses conceitos em artigos futuros.
O serviço sempre detecta alterações de back-end, portanto, se um pod ficar offline ou for substituído por um novo pod, o serviço para de enviar tráfego e redireciona para o pod de trabalho. É por isso que enfatizamos que, mesmo que a API seja composta por apenas um Pod, ela deve usar os Serviços para comunicação síncrona em vez de chamar os Pods diretamente.
// Namespace de imagens
O Kubernetes é um orquestrador de contêiner multilocatário. Isso significa que ele foi projetado para soluções que lidam com vários aplicativos e ambientes simultaneamente.
É aqui que entram os namespaces. Namespac atua como um separador lógico para recursos internos do Kubernetes, que podem vincular recursos (Pods, serviços etc.) a namepacs específicos e definir permissões específicas. Por exemplo, ele pode ser configurado para que os pods no namespace A não possam acessar os pods no namespace B.
Eu recomendo agrupar recursos de domínio de negócios em um namespace, isso torna mais fácil encontrar os recursos necessários e também permite que as equipes mantenham domínios de negócios específicos de forma independente em um projeto de software.
Kubernetes
Que tipo de aplicativo é adequado para hospedagem
Usar o Kubernetes em qualquer caso é como dirigir um carro de F1 até o supermercado. Embora eu espere fazer isso, ainda é um pouco difícil. Quando escolho quando usar o kubernetes, uso os seguintes critérios (é claro que preciso ajustar de acordo com a situação real):
Minha arquitetura em contêiner consiste em pelo menos 10 serviços diferentes em execução e dimensionados de forma independente na mesma infraestrutura.
Meu serviço tem dependências que existem no ambiente de rede local e requer políticas de tráfego e autenticação para chamar essas dependências.
Estou trabalhando com diferentes equipes mantendo e desenvolvendo diferentes componentes do mesmo aplicativo.
Preciso controlar computação, rede, política de rede, política contínua e controle de versão do orquestrador.
Preciso de uma solução que se expanda do local para a nuvem com um conjunto de ferramentas e uma estratégia de implantação consistentes.
Se duas ou mais das opções acima forem atendidas, o Kubernetes será uma boa escolha.
Como um artigo de ciência popular, a quantidade de informações neste artigo é um pouco grande e pode demorar um pouco para os desenvolvedores que são novos em contêineres entenderem, mas esperamos ajudar os desenvolvedores que estão apenas começando a entender o princípio de funcionamento do contêiner compilação e estar familiarizado com alguns termos especiais. Na sequência de artigos do Picturesocial, demonstraremos como esses conceitos são aplicados por meio de uma demonstração de caso específico.
Em um artigo posterior, aprenderemos juntos como realmente criar um cluster do Amazon EKS usando o Terraform!
Espero que você trabalhe feliz e viva muito ~
Continue atento à conta oficial do WeChat "Amazon Cloud Developer" para saber mais sobre compartilhamento de tecnologia e tendências de desenvolvimento de nuvem para desenvolvedores!
Eu ouvi, clique nos 4 botões abaixo
Você não encontrará bugs!
