[Cloud Native] Ferramenta de orquestração de contêineres Kubernetes

Kubernetes, a palavra se origina da palavra grega para timoneiro e piloto. Também é chamado de k8s na China (porque existem 8 letras entre k e s, por isso é chamado de "Humor dos programadores domésticos"). Um sistema de código aberto para implantação, dimensionamento e gerenciamento automático de "aplicativos em contêineres". Pode-se entender que K8S é um cluster responsável pela operação e manutenção automatizada de múltiplos programas conteinerizados (como Docker), sendo uma ferramenta de framework de orquestração de contêineres com um ecossistema extremamente rico.

K8S é baseado no sistema Borg do Google (sistema Borg, uma ferramenta de orquestração de contêineres em grande escala usada internamente pelo Google) como protótipo, sendo posteriormente reescrito usando as ideias de Borg na linguagem GO e doado à Fundação CNCF para código aberto.

A Cloud Native Foundation (CNCF) foi criada em dezembro de 2015 e é afiliada à Linux Foundation. O primeiro projeto incubado pela CNCF foi o Kubernetes.Com o uso generalizado de contêineres, o Kubernetes se tornou o padrão de fato para ferramentas de orquestração de contêineres.

Link para Download

官网：
https://kubernetes.io

GitHub：
https://github.com/kubernetes/kubernetes

1.2 Comparação entre orquestração docker e orquestração k8s

Só pode ser usado em uma única máquina, sem redundância mestre-escravo de cluster.
Quando o número de contêineres é grande, os custos de gerenciamento são elevados
Sem recuperação de desastres ou mecanismo de autocorreção
Não existe um arranjo predefinido e não pode ser programado em grande escala.
Nenhum centro unificado de gerenciamento e configuração
Sem interface gráfica
Nenhum centro de gerenciamento do ciclo de vida

1.3 Comparação entre implantação de back-end tradicional e k8s

Implantação tradicional

Método tradicional de implantação de back-end: coloque o pacote do programa (incluindo arquivos binários executáveis, arquivos de configuração, etc.) no servidor, execute o script de inicialização para executar o programa e, ao mesmo tempo, inicie o script daemon para verificar regularmente o status de execução do programa e reinicie-o se necessário.

Neste momento, uma vez que o volume de solicitações do serviço aumenta, o serviço implantado não pode responder.A abordagem tradicional é que se o volume de solicitações, memória e CPU excederem o limite e um alarme for emitido, o pessoal de operação e manutenção adicionará imediatamente mais alguns servidores e, após implantar o serviço, acesse o balanceamento de carga para compartilhar a pressão dos serviços existentes . Surge um problema: desde o monitoramento de alarmes até a implantação de serviços, é necessária intervenção humana! Não há como implantar, atualizar, desinstalar, expandir e reduzir serviços automaticamente

implantação k8s

Os problemas mencionados acima da implantação de back-end tradicional são os problemas que o k8s precisa resolver. Programa automatizado de conteinerização de gerenciamento de operação e manutenção (Docker). K8S é o sistema de gerenciamento de cluster de contêiner de código aberto do Google. Baseado em tecnologias de contêiner como Docker, ele fornece uma série de funções completas, como implantação e operação, agendamento de recursos, descoberta de serviços e escalonamento dinâmico para aplicativos em contêineres, melhorando a eficiência de aplicativos em grande escala. gerenciamento de cluster de contêineres. Conveniência

2. Arquitetura e componentes do cluster k8s

（1） Era um apiserver

Usado para expor a API Kubernetes. Qualquer solicitação de recurso ou operação de chamada é executada por meio da interface fornecida por kube-apiserver . A API HTTP Restful é usada para fornecer serviços de interface. Todas as operações de adição, exclusão, modificação, consulta e monitoramento de recursos de objeto são entregues ao servidor API para processamento e depois enviadas ao armazenamento Etcd.

Pode-se entender que API Server é o serviço de entrada de solicitações do K8S. O API Server é responsável por receber todas as solicitações K8S (da interface UI ou ferramenta de linha de comando CLI) e, em seguida, notificar outros componentes para funcionarem de acordo com as solicitações específicas do usuário. Pode-se dizer que o API Server é o cérebro da arquitetura do cluster K8S.

（2） Gerenciador de controlador Kube

O controlador de gerenciamento de operações é um thread de segundo plano que lida com tarefas regulares no cluster K8S.É o centro de controle automatizado para todos os objetos de recursos no cluster K8S.
Em um cluster K8S, um recurso corresponde a um controlador, e o gerenciador do controlador é responsável por gerenciar esses controladores .

Composto por uma série de controladores, ele monitora o status de todo o cluster por meio do API Server e garante que o cluster esteja no estado de funcionamento esperado. Por exemplo, quando um Node trava inesperadamente, o Controller Manager descobrirá e executará imediatamente um comando automatizado. processo de reparo para garantir que o cluster esteja sempre em boas condições de funcionamento.Condição de funcionamento esperada.

Esses controladores incluem principalmente:

Controlador de nó: Responsável por detectar e responder a falhas de nó.

Controlador de replicação: Responsável por garantir que o número de cópias do Pod associadas a um RC (controlador de replicação de objeto de recurso) no cluster sempre mantenha o valor predefinido. Pode ser entendido como uma garantia de que existem e existem apenas N instâncias de Pod no cluster, onde N é o número de cópias de Pod definidas em RC.

Controlador de endpoints: preenche objetos de endpoint (ou seja, conecta serviços e pods) e é responsável por monitorar alterações em serviços e cópias de pods correspondentes. Pode-se entender que um endpoint é um ponto de acesso exposto por um serviço, se você precisar acessar um serviço, deverá conhecer seu endpoint.

Controladores de conta de serviço e token: crie contas padrão e tokens de acesso de API para novos namespaces.

Controlador ResourceQuota: Garante que os objetos de recursos especificados não ocupem demais os recursos físicos do sistema em nenhum momento.

Controlador de namespace: gerencia o ciclo de vida do namespace.

Controlador de serviço: um controlador de interface entre o cluster K8S e a plataforma de nuvem externa.

（3） Agendador Kube

É o processo responsável pelo agendamento de recursos e seleciona um nó Node apropriado para o Pod recém-criado de acordo com o algoritmo de agendamento.

Pode ser entendido como o agendador de todos os nós do nó K8S. Quando um usuário deseja implantar um serviço, o Agendador selecionará o Node mais apropriado para implantar o Pod com base no algoritmo de agendamento .
Algoritmo de agendamento:

• Predicado
• Prioridades

O servidor API recebe a solicitação para criar um lote de pods. O servidor API solicitará ao gerente do controlador para criar pods de acordo com o modelo predefinido. O gerente do controlador irá ao agendador através do servidor API para selecionar o nó mais adequado nó para o pod recém-criado.

Por exemplo, a execução deste pod requer recursos 2C4G, e o Agendador filtrará os nós do Node que não atendem à política por meio da política de pré-seleção. Os recursos restantes no nó Node são relatados ao servidor API e armazenados no etcd. O servidor API chamará um método para encontrar os recursos restantes de todos os nós Node no etcd e, em seguida, compará-los-á com os recursos exigidos pelo pod. Se um nó do nó tem recursos insuficientes Ou se você não atender às condições da estratégia de pré-seleção, não conseguirá passar na pré-seleção. Os nós selecionados na fase de pré-seleção serão pontuados e classificados de acordo com a estratégia de otimização na fase de pré-seleção, sendo selecionado o nó com maior pontuação. Por exemplo, um Node com recursos mais ricos e carga menor pode ter uma classificação mais elevada.

Centro de armazenamento de configuração 2.2 k8s

etcd é o centro de serviços de armazenamento do k8s

etcd é um sistema de armazenamento de valor-chave distribuído que armazena configurações de chave e configurações de usuário do K8S. Somente o servidor API no K8S tem permissões de leitura e gravação, e outros componentes devem passar pela interface do servidor API para ler e gravar dados.

2.3 Componente de nó de k8s

（1）Kubelet

O monitor do nó Node e o comunicador com o nó Master. Kubelet é o "delineador" do nó Mestre instalado no nó Nó. Ele reportará regularmente ao Servidor API o status dos serviços em execução em seu nó Nó e aceitará instruções do nó Mestre para tomar medidas de ajuste.

Obtenha o status esperado do pod em seu próprio nó do nó mestre (como qual contêiner executar, o número de réplicas em execução, como configurar a rede ou armazenamento, etc.) e interaja diretamente com o mecanismo de contêiner para implementar o gerenciamento do ciclo de vida do contêiner. Se o status do pod em seu próprio nó for diferente de Se o estado esperado for inconsistente, chame a interface da plataforma do contêiner correspondente (ou seja, a interface do docker) para atingir esse estado.

Gerencie a limpeza de imagens e contêineres para garantir que as imagens nos nós não ocupem espaço total em disco e que os contêineres encerrados não ocupem muitos recursos.

Resumindo, em um cluster Kubernetes, um processo de serviço kubelet é iniciado em cada nó (também chamado de nó de trabalho). Este processo é usado para processar tarefas atribuídas pelo Master a este nó e gerenciar Pods e contêineres nos Pods. Cada processo kubelet registrará as próprias informações do nó no servidor API, relatará regularmente o uso dos recursos do nó ao mestre e monitorará os recursos do contêiner e do nó por meio do cAdvisor.

（2）Para proxy

O proxy de rede Pod é implementado em cada nó Node, que é o portador dos recursos do Serviço Kubernetes e é responsável por manter as regras de rede e o balanceamento de carga de quatro camadas. Responsável por escrever regras em iptables e ipvs para implementar mapeamento de acesso ao serviço.

O Kube-Proxy em si não fornece diretamente uma rede para pods. A rede do pod é fornecida pelo Kubelet. Na verdade, o Kube-Proxy mantém uma rede de cluster de pod virtual.
Kube-apiserver atualiza o serviço Kubernetes e mantém endpoints monitorando Kube-Proxy.

O balanceamento de carga de microsserviços no cluster K8S é implementado pelo Kube-proxy. Kube-proxy é o balanceador de carga dentro do cluster K8S. É um servidor proxy distribuído que executa um componente proxy Kube em cada nó do K8S.

(3) Motor de contêiner (docker ou foguete )

O mecanismo de contêiner executa o contêiner e é responsável pela criação e gerenciamento local do contêiner.
Quando o kubernetes agenda um pod para um nó, o kubelet no nó instrui o docker a iniciar um contêiner específico. Em seguida, o kubelet coletará continuamente informações do contêiner por meio do docker e as enviará ao nó mestre. O Docker extrairá a imagem do contêiner e iniciará ou interromperá o contêiner normalmente. A única diferença é que isso é controlado por um sistema automatizado, em vez de ser executado manualmente por um administrador em cada nó.

3. Conceitos básicos do K8s

Kubernetes contém muitos tipos de objetos de recursos: Pod, Label, Service, Replication Controller , etc.

Todos os objetos de recursos podem ser adicionados, excluídos, modificados, verificados, etc. por meio da ferramenta kubectl fornecida pelo Kubernetes e armazenados no etcd para armazenamento persistente.

Kubernets é na verdade um sistema de controle de recursos altamente automatizado que realiza funções avançadas, como controle automático e correção automática de erros, rastreando e comparando a diferença entre o status esperado dos recursos salvos no armazenamento etcd e o status real dos recursos no ambiente atual.

3.1 Entendimento, aplicação e processo de criação do pod

Pod é a menor/mais simples unidade básica criada ou implantada pelo Kubernetes. Um Pod representa um processo em execução no cluster. As vagens podem ser entendidas como vagens de ervilha, e cada recipiente na mesma vagem é uma ervilha. Um Pod consiste em um ou mais contêineres. Os contêineres no Pod compartilham recursos de rede, armazenamento e computação e são executados no mesmo host Docker.

Vários contêineres podem ser executados em um pod, também chamado de modo SideCar. Em um ambiente de produção, um único contêiner ou vários contêineres com forte correlação e complementaridade formam um Pod. Os contêineres no mesmo pod podem acessar uns aos outros por meio do host local e montar todos os volumes de dados no pod; no entanto, os contêineres entre pods diferentes não podem acessar por meio do host local nem montar os volumes de dados de outros pods.

Fluxo de trabalho K8S para criação de pods

(1) O usuário envia uma solicitação para criar um pod para o apiserver no nó mestre por meio do cliente

(2) o apiserver primeiro gravará as informações de solicitação relevantes no etcd e, em seguida, encontrará o gerenciador do controlador

Crie um manifesto de pod com base em um modelo de recurso predefinido

(3) Então o gerenciador do controlador encontrará o agendador através do apiserver.

Selecione o nó mais adequado para o pod recém-criado

(4) O agendador selecionará o nó Node mais adequado por meio da estratégia de pré-seleção e estratégia de otimização do algoritmo de escalonamento.

(5) Em seguida, encontre o kubelet no nó correspondente por meio do apiserver para criar e gerenciar pods

(6) Kubelet irá interagir diretamente com o mecanismo de contêiner para gerenciar o ciclo de vida do contêiner.

(7) Os usuários escrevem regras de rede relevantes criando recursos de serviço hospedados no kube-proxy.

Implementar descoberta de serviço e balanceamento de carga para pods

Controlador de pod

O controlador de pod é um modelo para inicialização de pod, usado para garantir que os pods iniciados no K8S sempre sejam executados de acordo com as expectativas do usuário (número de cópias, ciclo de vida, verificação de status de integridade, etc.).

K8S fornece vários controladores de Pod, os seguintes são comumente usados:

• Implantação: implantação de aplicativos sem estado. A função do Deployment é gerenciar e controlar Pods e ReplicaSets e controlá-los para serem executados no estado esperado pelo usuário.

• Replicaset: garante o número esperado de réplicas de pod. A função do ReplicaSet é gerenciar e controlar os pods e controlá-los para que funcionem bem. No entanto, o ReplicaSet é controlado pelo Deployment.

• Daemonset: certifique-se de que todos os nós executem o mesmo tipo de pod e que um desses pods esteja sendo executado em cada nó. Geralmente é usado para implementar tarefas em segundo plano no nível do sistema.

• Statefulset: implantação de aplicativos com estado

• Trabalho: tarefa única. De acordo com as configurações do usuário, o Pod gerenciado pelo Job será encerrado automaticamente após a conclusão da tarefa com sucesso.

• Cronjob: tarefas agendadas periódicas

3.2 Etiqueta da etiqueta

Tags são um método de gerenciamento exclusivo do K8S, que facilita a classificação e gerenciamento de objetos de recursos.
Os rótulos podem ser anexados a vários objetos de recursos, como Node, Pod, Service, RC, etc., e são usados para associar objetos, consultar e filtrar.
Um rótulo é um par chave-valor, onde a chave e o valor são especificados pelo usuário.
Um objeto de recurso pode definir qualquer número de rótulos, e o mesmo rótulo também pode ser adicionado a qualquer número de objetos de recurso ou pode ser adicionado ou excluído dinamicamente após a criação do objeto.
As funções de gerenciamento de agrupamento de recursos multidimensionais podem ser alcançadas agrupando um ou mais rótulos diferentes com objetos de recursos especificados.

Semelhante ao Label, também existe a Anotação.
A diferença é que um valor de tag válido deve ter 63 caracteres ou menos e deve estar vazio ou começar e terminar com caracteres alfanuméricos ([a-z0-9A-Z]) e pode incluir traços (-), sublinhados ( _) , ponto (.) e letras ou números. Os valores dos comentários não têm limite de comprimento de caracteres.

3.3 Seletor de etiqueta (seletor de etiqueta)

Definir um rótulo para um objeto de recurso equivale a atribuir um rótulo a ele; então você pode consultar e filtrar objetos de recurso que possuem determinados rótulos por meio do seletor de rótulo (seletor de rótulo).
Atualmente existem dois tipos de seletores de tags: baseados em relacionamentos de equivalência (igual a, diferente de) e baseados em relacionamentos de conjunto (pertence a, não pertence a, existe).

3.4 Serviço

Em um cluster K8S, embora cada pod receba um endereço IP separado, como os pods têm um ciclo de vida (eles podem ser criados e não serão reiniciados após serem destruídos), eles podem mudar a qualquer momento devido a mudanças nos negócios. Como resultado, esse endereço IP também desaparecerá quando o pod for destruído.

Serviço é o conceito central usado para resolver este problema. Serviço no K8S não significa “serviço” como costumamos dizer, mas sim como uma camada de gateway, que pode ser considerada como a interface de acesso externo e balanceador de tráfego de um grupo de Pods que fornecem o mesmo serviço.
Os pods em que o serviço atua são definidos por meio de seletores de rótulos.
Em um cluster K8S, Serviço pode ser considerado como a interface de acesso externo de um grupo de Pods que fornecem o mesmo serviço. O serviço que o cliente precisa acessar é o objeto Service. Cada serviço tem um IP virtual fixo (esse IP também é chamado de IP de cluster), que é vinculado automática e dinamicamente ao pod de back-end. Todas as solicitações de rede acessam diretamente o IP virtual do serviço, e o serviço será encaminhado automaticamente para o back-end. .
Além de fornecer um método de acesso externo estável, o Serviço também pode funcionar como um balanceador de carga, distribuindo automaticamente o tráfego de solicitações para todos os serviços de back-end. O Serviço pode ser dimensionado horizontalmente de forma transparente para os clientes.
A chave para realizar a função de serviço é o kube-proxy. kube-proxy é executado em cada nó e monitora alterações nos objetos de serviço no servidor API. A rede pode ser implementada por meio dos três modos de agendamento de tráfego a seguir: espaço do usuário (obsoleto), iptables (prestes a serem abandonados) e ipvs (recomendado , melhor desempenho) encaminhamento.

O serviço é o núcleo dos serviços K8S. Ele protege os detalhes do serviço e expõe a interface do serviço para o exterior de forma unificada, alcançando verdadeiramente "microsserviços". Por exemplo, um de nossos serviços A implantou 3 cópias, ou seja, 3 Pods; para os usuários, eles só precisam ficar atentos à entrada de um Serviço, e não precisam se preocupar com qual Pod deve ser solicitado.
As vantagens são muito óbvias: por um lado, os usuários externos não precisam estar cientes das alterações de IP causadas por falhas inesperadas de serviços nos Pods ou K8S reiniciando Pods. Os usuários externos também não precisam estar cientes das alterações de IP causadas pelo Pod. substituições devido a atualizações ou alterações de serviço.

3.5 Entrada

O serviço é o principal responsável pela topologia de rede dentro do cluster K8S. Então, como a parte externa do cluster acessa o interior do cluster? O ingresso é necessário neste momento. Ingress é a camada de acesso de todo o cluster K8S e é responsável pela comunicação dentro e fora do cluster.
Ingress é um aplicativo de camada 7 que funciona sob o modelo de referência de rede OSI no cluster K8S. É uma interface exposta externamente. O método de acesso típico é http/https.
O serviço só pode realizar agendamento de tráfego na quarta camada, na forma de ip+porta. O Ingress pode agendar o tráfego comercial em diferentes domínios comerciais e diferentes caminhos de acesso de URL.

O processo é aproximadamente o seguinte: Nome de domínio solicitado pelo cliente ---> Ingress (proxy de sete camadas) ---> Serviço (proxy de quatro camadas) ---> Pod

3.5 Nome

Como o K8S utiliza “recursos” internamente para definir cada conceito lógico (função), cada “recurso” deve ter seu próprio “nome”.

"Recursos" incluem versão da API (apiversion), categoria (tipo), metadados (metadados), lista de definições (especificações), status (status) e outras informações de configuração.
O “nome” geralmente é definido nas informações de “metadados” do “recurso”. Deve ser exclusivo dentro do mesmo namespace.

3.6 Espaço para nome

À medida que os projetos aumentam, o pessoal aumenta e a escala do cluster se expande, é necessário um método que possa isolar logicamente vários "recursos" dentro do K8S. Este é o Namespace.

O Namespace nasceu para dividir um cluster K8S em vários grupos de clusters virtuais cujos recursos não podem ser compartilhados.

Os nomes dos "recursos" em diferentes namespaces podem ser iguais, mas os "nomes" do mesmo tipo de "recursos" no mesmo namespace não podem ser os mesmos.

O uso adequado do Namespace do K8S pode permitir que os administradores de cluster classifiquem, gerenciem e naveguem melhor nos serviços entregues ao K8S.

Os namespaces que existem por padrão no K8S incluem: default, kube-system, kube-public, etc.

Para consultar um “recurso” específico no K8S, é necessário trazer o Namespace correspondente.

4. Métodos comuns de implantação do K8S

4.1 Métodos comuns de implantação de k8s

●Minikube
Minikube是一个工具，可以在本地快速运行一个单节点微型K8S，仅用于学习、预览K8S的一些特性使用。
部署地址：https://kubernetes.io/docs/setup/minikube

●Kubeadm
Kubeadm也是一个工具，提供kubeadm init和kubeadm join，用于快速部署K8S集群，相对简单。
https://kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm/

●二进制安装部署
生产首选，从官方下载发行版的二进制包，手动部署每个组件和自签TLS证书，组成K8S集群，新手推荐。
https://github.com/kubernetes/kubernetes/releases


Kubeadm降低部署门槛，但屏蔽了很多细节，遇到问题很难排查。如果想更容易可控，推荐使用二进制包部署Kubernetes集群，虽然手动部署麻烦点，期间可以学习很多工作原理，也利于后期维护。

4.2 A diferença entre o binário de implantação k8s e a alta disponibilidade

●A implantação binária
é difícil de implantar, fácil de gerenciar, tem bom desempenho de expansão de cluster e é mais
estável.Quando a escala do cluster atinge uma determinada escala (centenas de nós, dezenas de milhares de pods), a estabilidade binária é maior do que a de implantação do kubeadm
. Quando ocorre uma falha, a máquina host irá, o processo também será iniciado

●A implantação do kubeadm é
simples de implantar, mas difícil de gerenciar.
Ele permite que componentes e serviços sejam gerenciados por contêineres. O tempo de recuperação de falhas é mais lento que o binário. Quando ocorre uma falha,
inicie o host, depois inicie o processo e, finalmente, inicie o contêiner, para que o cluster possa ser restaurado. Mais lento que o binário