Guia Kubernetes, Parte 2: Criando e trabalhando com um cluster

Na última vez, examinamos duas abordagens para trabalhar com microsserviços. Em particular, um deles envolve o uso de contêineres Docker, nos quais você pode executar o código de microsserviços e programas auxiliares. Hoje, usando nossas imagens de contêiner existentes, trabalharemos com o Kubernetes.

Apresentando o Kubernetes

Eu prometo e não exagero quando você lê este artigo, pergunte-se: "Por que os Kubernetes não são chamados de Supernetes?"


Supernetes

Se você leu a parte anterior deste material, sabe que examinamos muitas coisas relacionadas à preparação de aplicativos para contêiner e ao trabalho com contêineres do Docker. Pode parecer para você que a coisa mais difícil espera por você agora, mas, de fato, o que falaremos aqui é muito mais simples do que o que já descobrimos. A única razão pela qual aprender Kubernetes pode parecer uma tarefa assustadora para alguém é a quantidade de informações extras necessárias para entender o Kubernetes e usá-lo de forma eficaz. Já discutimos todas as "informações adicionais" necessárias para o desenvolvimento bem-sucedido do Kubernetes.

▍O que é o Kubernetes?

Na primeira parte deste artigo, após o lançamento de microsserviços em contêineres, você foi solicitado a pensar no problema de dimensionar aplicativos em contêiner.
Sugiro refletir juntos sobre isso, no formato de perguntas e respostas:

Pergunta: Como os aplicativos em contêiner são dimensionados?
Resposta: Lance contêineres adicionais.

Pergunta: E como a carga é distribuída entre eles? E se um determinado servidor já estiver usado ao máximo e o contêiner precisar ser implantado em outro servidor? Como encontrar a maneira mais eficiente de usar hardware?
Resposta: Então ... vou procurar na Internet ...

Pergunta: Como atualizar programas sem interromper o sistema? E, se a atualização contiver um erro, como retornar à versão funcional do aplicativo?

De fato, é a tecnologia Kubernetes que fornece respostas dignas para essas e muitas outras perguntas. Tentarei restringir a definição de Kubernetes a uma frase: "Kubernetes é um sistema de gerenciamento de contêineres que abstrai a infraestrutura subjacente (o ambiente em que os contêineres são executados)".

Acredito que agora você não está particularmente claro sobre o conceito de "gerenciamento de contêineres", embora já tenhamos mencionado isso. Abaixo, consideraremos essa tecnologia na prática. No entanto, o conceito de "abstrair a infraestrutura básica" é encontrado pela primeira vez. Portanto, agora vamos considerar isso.

StrAbstração da infraestrutura básica

O Kubernetes permite que os aplicativos se afastem da infraestrutura, fornecendo uma API simples para a qual você pode enviar solicitações. O Kubernetes tenta atender a essas solicitações usando todos os seus recursos. Por exemplo, em um idioma comum, uma solicitação semelhante pode ser descrita da seguinte forma: “Kubernetes, expanda 4 contêineres de imagens X”. Após receber o comando, o Kubernetes encontrará nós que não estão muito ocupados (eles também são chamados de "nós" - do "nó" inglês), nos quais você pode implantar novos contêineres.


Solicitação do servidor de API

O que isso significa para o desenvolvedor? Isso significa que ele não precisa se preocupar com o número de nós, exatamente onde os contêineres são lançados ou como eles interagem. Ele não precisa lidar com a otimização de hardware ou se preocupar com os nós que podem estar com defeito (e algo semelhante, de acordo com a lei de Murphy, certamente acontecerá), pois, se necessário, novos nós podem ser adicionados ao cluster Kubernetes. Se algo estiver errado com alguns nós existentes, o Kubernetes implantará contêineres nos nós que ainda estão em um estado íntegro.

Muito do que é mostrado na figura anterior já é familiar para você. Mas há também algo novo:

• Servidor API Fazer chamadas para este servidor é a única maneira de interagir com o cluster que temos, se estamos falando sobre iniciar ou parar contêineres, verificar o status do sistema, trabalhar com logs ou executar outras ações.
• Kubelet. Este é um agente que monitora os contêineres dentro do nó e interage com o nó principal.

Observe que em algumas frases anteriores usamos o termo "contêiner", mas aqui seria mais correto usar o termo "pod". Essas entidades são freqüentemente chamadas de "vagens" em publicações em russo e, às vezes - "vagens", na documentação , esclarecendo o conceito de "vagem", elas falam de um "bando de baleias" (vagem de baleias) ou de um "vagem de ervilha" mas ninguém os chama de "bandos" ou "vagens". Falando deles, usaremos a palavra "abaixo". Agora você pode considerá-los contêineres, falaremos mais sobre os pods abaixo.

Pararemos com isso por enquanto, pois podemos falar sobre tudo isso ainda mais, e, além disso, existem muitos materiais bons sobre a teoria de Kubernetes. Por exemplo, essa é uma documentação oficial, embora não seja fácil de ler, ou livros como este .

▍ Padronização do trabalho com provedores de serviços em nuvem

Outro ponto forte do Kubernetes reside no fato de que essa tecnologia contribui para a padronização do trabalho com provedores de serviços em nuvem (Cloud Service Provider, CSP). Esta é uma afirmação ousada. Considere o seguinte exemplo. Um especialista que conhece bem o Azure ou o Google Cloud Platform precisa trabalhar em um projeto projetado para um ambiente em nuvem completamente novo para ele, com o qual não está familiarizado. Nesta situação, muita coisa pode dar errado. Por exemplo, os prazos para a entrega do projeto podem ser atrasados, a empresa cliente do projeto pode precisar alugar mais recursos de nuvem do que o planejado, e assim por diante.

Ao usar o Kubernetes, esse problema simplesmente não pode surgir, pois, independentemente de qual provedor de serviços em nuvem específico, estamos trabalhando, o trabalho com o Kubernetes sempre parece o mesmo. O desenvolvedor, em estilo declarativo, diz ao servidor da API o que ele precisa e o Kubernetes trabalha com os recursos do sistema, permitindo que o desenvolvedor ignore os detalhes da implementação desse sistema.

Demore um pouco nessa idéia, já que esta é uma oportunidade muito poderosa para o Kubernetes. Para as empresas, isso significa que suas decisões não estão vinculadas a um CSP específico. Se uma empresa encontrar uma oferta melhor no mercado de serviços em nuvem, poderá tirar proveito dessa oferta livremente mudando para um novo provedor. Além disso, a experiência adquirida pelos especialistas da empresa não se perde em lugar algum.

Agora vamos falar sobre o uso prático do Kubernetes

Prática de Kubernetes: Pods

Configuramos o lançamento de microsserviços em contêineres, o processo de instalação foi bastante tedioso, mas conseguimos acessar um sistema em funcionamento. Além disso, como já mencionado, nossa solução não é bem dimensionada e não é resistente a falhas. Vamos resolver esses problemas com o Kubernetes. Em seguida, traremos nosso sistema para um formulário correspondente ao esquema a seguir. Ou seja, os contêineres serão gerenciados pelo Kubernetes.


Os microsserviços funcionam em um cluster gerenciado pelo Kubernetes

Aqui, usaremos o Minikube para implantação local do cluster e para testar os recursos do Kubernetes, embora tudo o que faremos aqui possa ser feito usando plataformas em nuvem como o Azure ou o Google Cloud Platform.

▍Instalação e início do Minikube

Para instalar o Minikube, siga as instruções encontradas na documentação . Durante a instalação do Minikube, você também instalará o Kubectl. Este é um cliente que permite que solicitações sejam feitas ao servidor da API Kubernetes.

Para iniciar o Minikube, execute o comando minikube start e, após a conclusão, execute o comando kubectl get nodes . Como resultado, você deve ver algo como o seguinte:

 kubectl get nodes NAME       STATUS ROLES     AGE VERSION minikube   Ready <none>    11m v1.9.0 

O Minikube coloca à nossa disposição um cluster que consiste em apenas um nó. É verdade que isso nos convém muito bem. Quem trabalha com o Kubernetes não precisa se preocupar exatamente com quantos nós existem no cluster, pois o Kubernetes permite abstrair esses detalhes.

Agora vamos falar sobre vagens.

▍Pods

Eu realmente gosto de contêineres, e você provavelmente também gosta deles agora. Por que o Kubernetes nos oferece o uso de pods, entidades que são as unidades de computação mínimas implantáveis ​​neste sistema? Em que funções ele executa? O fato é que a lareira pode incluir um ou mais contêineres que compartilham o mesmo tempo de execução.

Mas é necessário realizar, por exemplo, dois contêineres em uma lareira? Como dizer ... Normalmente, há apenas um contêiner por contêiner, e é isso que vamos fazer. Mas para os casos em que, por exemplo, dois contêineres precisam de acesso compartilhado ao mesmo data warehouse, ou se estão conectados usando a técnica de comunicação entre processos, ou se estão intimamente conectados por algum outro motivo, tudo isso pode ser realizado executando-os em uma lareira. Outra possibilidade em que os pods diferem é que eles não precisam usar contêineres do Docker. Se necessário, aqui você pode aplicar outras tecnologias para conteinerização de aplicativos, por exemplo - Rkt .

O diagrama a seguir mostra as propriedades numeradas da lareira.


Propriedades da lareira

Considere essas propriedades.

1. Cada pod em um cluster Kubernetes possui um endereço IP exclusivo.
2. Uma lareira pode conter muitos recipientes. Eles compartilham números de portas disponíveis, ou seja, por exemplo, eles podem trocar informações entre si via localhost (naturalmente, eles não podem usar as mesmas portas). A interação com contêineres localizados em outros pods é organizada usando os endereços IP desses pods.
3. Os contêineres nos pods compartilham volumes de armazenamento de dados, endereço IP, números de porta e espaço para nome do IPC.

Deve-se observar que os contêineres têm seus próprios sistemas de arquivos isolados, mas eles podem compartilhar dados usando o recurso Kubernetes chamado Volume .

Para nós, o que já foi dito sobre as lareiras é suficiente para continuar a dominar os Kubernetes. Leia mais sobre eles aqui .

▍ Descrição da lareira

A seguir, um arquivo de manifesto para o aplicativo sa-frontend .

 apiVersion: v1 kind: Pod                                            # 1 metadata: name: sa-frontend                                  # 2 spec:                                                # 3 containers:   - image: rinormaloku/sentiment-analysis-frontend # 4     name: sa-frontend                              # 5     ports:       - containerPort: 80 

Vamos explicar alguns dos parâmetros especificados nele.

1. Kind : especifica o tipo de recurso do Kubernetes que queremos criar. No nosso caso, este é o Pod .
2. Name : nome do recurso. Chamamos isso sa-frontend .
3. Spec : um objeto que descreve o estado desejado do recurso. A propriedade mais importante aqui é a matriz de contêineres.
4. Image : a imagem do contêiner que queremos executar neste pod.
5. Name : um nome exclusivo para o contêiner abaixo.
6. ContainerPort : a porta em que o contêiner está escutando. Este parâmetro pode ser considerado uma indicação para quem lê este arquivo (se você omitir este parâmetro, isso não limitará o acesso à porta).

▍Criando um SA-Frontend da lareira

O arquivo de descrição do pod de que falamos pode ser encontrado em resource-manifests/sa-frontend-pod.yaml . Você deve ir para esta pasta usando as ferramentas do terminal ou, quando chamar o comando apropriado, especificar o caminho completo para o arquivo. Aqui está este comando e um exemplo de uma reação do sistema a ele:

 kubectl create -f sa-frontend-pod.yaml pod "sa-frontend" created 

Para descobrir se funciona, execute o seguinte comando:

 kubectl get pods NAME                          READY STATUS RESTARTS AGE sa-frontend                   1/1 Running 0 7s 

Se o estado da lareira durante a execução deste comando for ContainerCreating , você poderá executar o mesmo comando com a --watch . Por esse motivo, quando a lareira estiver no estado Running , informações sobre isso serão exibidas automaticamente.

CessAcesso ao aplicativo de fora

Para organizar o acesso ao aplicativo de fora, será correto criar um recurso Kubernetes do tipo Serviço, sobre o qual falaremos abaixo, mas aqui, por questões de brevidade, usaremos um encaminhamento de porta simples:

 kubectl port-forward sa-frontend 88:80 Forwarding from 127.0.0.1:88 -> 80 

Se você agora acessa um navegador em 127.0.0.1:88 , pode ver a página do aplicativo React.

Approach Abordagem de escala incorreta

Já dissemos que um dos recursos do Kubernetes é o dimensionamento de aplicativos. Para aproveitar esta oportunidade, abordaremos outra. Crie uma descrição de outro recurso de Pod , colocando o seguinte código no arquivo sa-frontend-pod2.yaml :

 apiVersion: v1 kind: Pod                                           metadata: name: sa-frontend2      #   spec:                                                containers:   - image: rinormaloku/sentiment-analysis-frontend     name: sa-frontend                                  ports:       - containerPort: 80 

Como você pode ver, se você comparar essa descrição com o que examinamos acima, a única alteração será o valor da propriedade Name .

Crie um novo em:

 kubectl create -f sa-frontend-pod2.yaml pod "sa-frontend2" created 

Verifique se está em execução:

 kubectl get pods NAME                          READY STATUS RESTARTS AGE sa-frontend                   1/1 Running 0 7s sa-frontend2                  1/1 Running 0 7s 

Agora temos duas lareiras! É verdade que não há nada de especial para desfrutar aqui. Observe que a solução para o problema de dimensionamento de aplicativos mostrado aqui tem muitas desvantagens. Falaremos sobre como fazer isso corretamente na seção em outro recurso do Kubernetes chamado Deployment.

Agora considere o que obtivemos após o lançamento de duas lareiras idênticas. Ou seja, o servidor da web Nginx agora roda em dois pods diferentes. Nesse sentido, podemos fazer duas perguntas:

1. Como dar acesso a esses servidores de fora, por URL?
2. Como organizar o balanceamento de carga entre eles?

Abordagem de escala incorreta

Entre as ferramentas do Kubernetes, existem recursos do formulário Serviço. Vamos conversar sobre eles.

Kubernetes Practice: Serviços

Os serviços Kubernetes atuam como pontos de acesso a conjuntos de fornos que fornecem a mesma funcionalidade que esses fornos. Os serviços executam a solução de tarefas difíceis de trabalhar com lareiras e equilibrar a carga entre elas.


O serviço Kubernetes atende endereços IP

No nosso cluster Kubernetes, haverá pods que implementam funções diferentes. Este é um aplicativo front-end, um aplicativo Web Spring e um aplicativo Flask escrito em Python. Isso levanta a questão de como o serviço precisa entender com quais pods ele precisa trabalhar, ou seja, como descobrir com base em quais informações o sistema deve gerar uma lista de pontos de extremidade para os pods.

Isso é feito com outra abstração do Kubernetes chamada Label. O trabalho com tags consiste em dois estágios:

1. A atribuição de etiqueta fornecerá o serviço para trabalhar.
2. Aplicando um "seletor" ao serviço, que determina quais pods às quais etiquetas são atribuídas, o serviço funcionará.

Talvez seja mais fácil imaginar isso como ilustração do que descrever.


Pods rotulados e seus arquivos de manifesto

Vemos aqui dois lares que, usando o app: sa-frontend construção app: sa-frontend , recebem os mesmos rótulos. O serviço está interessado em pods com essas marcas.

▍Tags

Os rótulos oferecem aos desenvolvedores uma maneira simples de organizar os recursos do Kubernetes. Eles são pares de valores-chave; você pode atribuí-los a qualquer recurso. Modifique os arquivos de descrição da lareira do aplicativo frontend e traga-os para a exibição mostrada na figura anterior. Depois disso, salve esses arquivos e execute os seguintes comandos:

 kubectl apply -f sa-frontend-pod.yaml Warning: kubectl apply should be used on resource created by either kubectl create --save-config or kubectl apply pod "sa-frontend" configured kubectl apply -f sa-frontend-pod2.yaml Warning: kubectl apply should be used on resource created by either kubectl create --save-config or kubectl apply pod "sa-frontend2" configured 

Quando esses comandos são executados, o sistema emitirá avisos (não nos convém usar o apply vez de create , entendemos isso), mas, após um aviso, ele informa que os pods correspondentes estão configurados. Podemos verificar se os rótulos foram atribuídos, filtrando os logs para os quais queremos exibir informações:

 kubectl get pod -l app=sa-frontend NAME           READY STATUS    RESTARTS AGE sa-frontend    1/1 Running   0 2h sa-frontend2   1/1 Running   0 2h 

Outra maneira de verificar se as etiquetas foram realmente atribuídas é anexar a chave --show-labels ao comando anterior. Devido a isso, as informações sobre seus pods também incluirão dados em suas marcas.

Agora as tags foram atribuídas e estamos prontos para configurar o serviço para trabalhar com elas. Portanto, assumiremos a descrição de um serviço como o LoadBalancer .


Balanceamento de carga usando um serviço como o LoadBalancer

▍ Descrição do serviço

Aqui está uma descrição do YAML de um serviço como o LoadBalancer :

 apiVersion: v1 kind: Service              # 1 metadata: name: sa-frontend-lb spec: type: LoadBalancer       # 2 ports: - port: 80               # 3   protocol: TCP          # 4   targetPort: 80         # 5 selector:                # 6   app: sa-frontend       # 7 

Explique este texto:

1. Kind : criamos um serviço, um recurso de Service .
2. Type : o tipo de recurso indicado em sua especificação. Escolhemos o tipo LoadBalancer , porque com este serviço queremos resolver o problema de equilibrar a carga entre as lareiras.
3. Port : porta na qual o serviço aceita solicitações.
4. Protocol : o protocolo usado pelo serviço.
5. TargetPort : porta para a qual as solicitações recebidas são redirecionadas.
6. Selector : um objeto que contém informações sobre com quais pods o serviço deve funcionar.
7. app: sa-frontend : essa propriedade indica com quais pods o serviço trabalhará. Nomeadamente, esses são os pods aos quais o rótulo app: sa-frontend foi atribuído.

Para criar um serviço, você precisa executar o seguinte comando:

 kubectl create -f service-sa-frontend-lb.yaml service "sa-frontend-lb" created 

Você pode verificar o status do serviço da seguinte maneira:

 kubectl get svc NAME             TYPE CLUSTER-IP      EXTERNAL-IP PORT(S) AGE sa-frontend-lb   LoadBalancer 10.101.244.40   <pending> 80:30708/TCP 7m 

Aqui você pode ver que a propriedade EXTERNAL-IP está no estado <pending> , mas não pode esperar que ela mude. Isso se deve ao fato de usarmos o Minikube. Se criarmos um serviço semelhante ao trabalhar com um determinado provedor de serviços em nuvem, como o Azure ou o Google Cloud Platform, o serviço terá um endereço IP público que tornará possível acessá-lo pela Internet.

Apesar disso, o Minikube não nos permitirá mexer, dando-nos um comando útil para a depuração local do sistema:

 minikube service sa-frontend-lb Opening kubernetes service default/sa-frontend-lb in default browser... 

Graças a este comando, será lançado um navegador que acessará o serviço. Depois que o serviço receber a solicitação, ele será redirecionado para um dos lares (não importa em qual deles estará). Essa abstração nos permite perceber um grupo de lares como uma única entidade e trabalhar com eles, usando o serviço como um único ponto de acesso a eles.

Nesta seção, falamos sobre como atribuir rótulos a recursos, como usá-los ao configurar serviços como seletores. Aqui nós descrevemos e criamos um serviço como o LoadBalancer . Graças a isso, resolvemos o problema de dimensionar o aplicativo (o dimensionamento consiste em adicionar novos lares com as etiquetas correspondentes ao cluster) e organizar o balanceamento de carga entre os lares, usando o serviço como ponto de entrada.

Prática Kubernetes: implantações

A implantação é uma abstração do Kubernetes que nos permite controlar o que está sempre presente no ciclo de vida do aplicativo. É sobre o gerenciamento de alterações de aplicativos. Aplicativos que não mudam são, por assim dizer, aplicativos "mortos". Se o aplicativo "permanecer", você poderá encontrar o fato de que seus requisitos mudam periodicamente, seu código se expande, esse código é empacotado e implantado. Além disso, erros podem ser cometidos em todas as etapas do processo.

Um recurso do tipo Implantação permite automatizar o processo de transição de uma versão de um aplicativo para outra. Isso é feito sem interromper o sistema e, se ocorrer um erro durante esse processo, teremos a oportunidade de retornar rapidamente à versão de trabalho anterior do aplicativo.

SeUso de implantações

Agora, o cluster tem duas lareiras e um serviço que dá acesso a elas de fora e equilibra a carga nelas.


Status atual do cluster

Falamos sobre o fato de que administrar dois lares diferentes com a mesma funcionalidade não é uma boa ideia. Ao usar esse esquema, precisamos trabalhar com cada lareira individualmente, criando, atualizando e excluindo cada lareira específica, observando seu estado. Com essa abordagem, não é necessário falar sobre uma atualização rápida do sistema ou a reversão rápida de uma atualização malsucedida. Não estamos satisfeitos com esse estado de coisas, portanto, vamos recorrer à possibilidade de recurso de implantação, que visa solucionar os problemas acima.

Antes de continuarmos o trabalho, vamos formular seus objetivos, que nos fornecerão diretrizes que serão úteis ao analisar o arquivo de manifesto de implantação. Então, aqui está o que precisamos:

1. Queremos ser capazes de criar dois lares com base em um contêiner rinormaloku/sentiment-analysis-frontend .
2. Precisamos de um sistema de implantação de aplicativos que permita que ele funcione sem interrupções quando for atualizado.
3. Queremos que o rótulo do app: sa-frontend seja atribuído app: sa-frontend , que permitirá que o serviço sa-frontend-lb detecte esses pods.

Agora, expressaremos esses requisitos como uma descrição do recurso Deployment.

▍ Descrição da implantação

Aqui está uma descrição do YAML de um recurso do tipo Implantação, criado tendo em conta os requisitos de sistema acima:

 apiVersion: extensions/v1beta1 kind: Deployment                                          # 1 metadata: name: sa-frontend spec: replicas: 2                                             # 2 minReadySeconds: 15 strategy:   type: RollingUpdate                                   # 3   rollingUpdate:     maxUnavailable: 1                                   # 4     maxSurge: 1                                         # 5 template:                                               # 6   metadata:     labels:       app: sa-frontend                                  # 7   spec:     containers:       - image: rinormaloku/sentiment-analysis-frontend         imagePullPolicy: Always                         # 8         name: sa-frontend         ports:           - containerPort: 80 

Vamos analisar esta descrição:

1. Kind : diz aqui que estamos descrevendo um recurso da visualização Deployment .
2. Replicas : uma propriedade do objeto de especificação de implantação que define quantas instâncias (réplicas) de lares serão executadas.
3. Type : descreve a estratégia usada nesta implantação ao alternar da versão atual para uma nova. RollingUpdate estratégia RollingUpdate fornece zero tempo de inatividade do sistema durante as atualizações.
4. MaxUnavailable : esta é uma propriedade do objeto RollingUpdate , que define o número máximo de lares indisponíveis (comparado ao número desejado de lares) ao executar uma atualização seqüencial do sistema. Em nossa implantação, que implica a presença de duas réplicas, o valor dessa propriedade indica que após a conclusão de um pod, outro pod será executado, o que torna o aplicativo disponível durante a atualização.
5. MaxSurge : esta é uma propriedade do objeto RollingUpdate que descreve o número máximo de fornos que podem ser adicionados a uma implantação (em comparação com um determinado número de fornos). No nosso caso, seu valor 1 significa que, ao mudar para uma nova versão do programa, podemos adicionar outra sub para o cluster, o que levará ao fato de que até três lareiras podem ser lançadas simultaneamente.
6. Template : este objeto define o modelo de lareira que o recurso de Deployment descrito utilizará para criar novas lareiras. Você provavelmente encontrará essa configuração familiar.
7. app: sa-frontend : etiqueta para lareiras criadas de acordo com um determinado padrão.
8. ImagePullPolicy : define a ordem do trabalho com imagens. No nosso caso, essa propriedade é configurada como Always , ou seja, durante cada implantação, a imagem correspondente será baixada do repositório.

Tendo examinado tudo isso, vamos continuar praticando. Execute a implantação:

 kubectl apply -f sa-frontend-deployment.yaml deployment "sa-frontend" created 

Verifique o status do sistema:

 kubectl get pods NAME                           READY STATUS RESTARTS AGE sa-frontend                    1/1 Running 0 2d sa-frontend-5d5987746c-ml6m4   1/1 Running 0 1m sa-frontend-5d5987746c-mzsgg   1/1 Running 0 1m sa-frontend2                   1/1 Running 0 2d 

Como você pode ver, agora temos 4 pods. Dois deles foram criados usando o recurso Deployment, outros dois são aqueles que nós mesmos criamos. Agora você pode remover os pods criados por nós usando comandos do seguinte tipo:

 kubectl delete pod <pod-name> 

A propósito, aqui está uma tarefa para um trabalho independente. Exclua uma das lareiras criadas usando o recurso Deployment e monitore o sistema. Pense nas razões do que está acontecendo antes de ler mais.

Ao excluir uma lareira, o recurso de Implantação descobre que o estado atual do sistema (1 sub) é diferente do desejado (2 sub), portanto, outra sub é iniciada.

Qual é a utilização dos recursos de implantação, além do fato de que, quando usado, o sistema é mantido no estado correto? Considere os pontos fortes desses recursos.

▍ Executando implantações com zero tempo de inatividade do sistema

Suponha que um gerente de produto chegue até nós e relate que o cliente para quem criamos este produto deseja um botão verde no aplicativo cliente. Os desenvolvedores implementam esse requisito e nos dão a única coisa que precisamos deles - um contêiner de imagem chamado rinormaloku/sentiment-analysis-frontend:green . Agora chega a nossa hora. Nós, a equipe do DevOps, precisamos implantar o sistema atualizado e garantir zero tempo de inatividade. Agora vamos ver se os esforços para desenvolver e configurar o recurso Deployment são justificados.

Edite o arquivo sa-frontend-deployment.yaml , substituindo o nome do contêiner de imagem por um novo, com rinormaloku/sentiment-analysis-frontend:green , salve esse arquivo como sa-frontend-deployment-green.yaml e execute o seguinte comando:

 kubectl apply -f sa-frontend-deployment-green.yaml --record deployment "sa-frontend" configured 

Verifique o status do sistema com o seguinte comando:

 kubectl rollout status deployment sa-frontend Waiting for rollout to finish: 1 old replicas are pending termination... Waiting for rollout to finish: 1 old replicas are pending termination... Waiting for rollout to finish: 1 old replicas are pending termination... Waiting for rollout to finish: 1 old replicas are pending termination... Waiting for rollout to finish: 1 old replicas are pending termination... Waiting for rollout to finish: 1 of 2 updated replicas are available... deployment "sa-frontend" successfully rolled out 

De acordo com os dados exibidos em resposta a este comando, podemos concluir que a implantação da atualização foi bem-sucedida. Durante a atualização, as réplicas antigas, uma de cada vez, foram substituídas por novas. , , , . , , .

, , :

 minikube service sa-frontend-lb 

, .




, , — .

RollingUpdate

, kubectl apply -f sa-frontend-deployment-green.yaml --record , Kubernetes , , . , , rinormaloku/sentiment-analysis-frontend:green . , , .




RollingUpdate , , maxUnavailable: 1 maxSurge: 1 . , Deployment , , , . , , , .

Deployment. , . .

▍

, , . «! ! !», — . . , , :

 kubectl rollout history deployment sa-frontend deployments "sa-frontend" REVISION  CHANGE-CAUSE 1         <none>    2         kubectl.exe apply --filename=sa-frontend-deployment-green.yaml --record=true 

: «, , ?».

«. , ?», — .

, , :

 kubectl rollout undo deployment sa-frontend --to-revision=1 deployment "sa-frontend" rolled back 

. , .

.

.

!

, . Kubernetes , , . , !

. , . CHANGE-CAUSE <none> , — kubectl.exe apply –filename=sa-frontend-deployment-green.yaml –record=true ?

, -- record , .

, , , .

Kubernetes:

Kubernetes, , . , .




.

▍ sa-logic

resource-manifests :

 kubectl apply -f sa-logic-deployment.yaml --record deployment "sa-logic" created 

sa-logic . Python-. app: sa-logic . sa-logic , . sa-logic-deployment.yaml .

-, , — sa-logic .

▍ sa-logic

, Service. , Java-, sa-webapp , , Python-. , , , Python-, . , , , .

, , , , . , sa-logic , sa-logic .

:

 kubectl apply -f service-sa-logic.yaml service "sa-logic" created 

, .




sa-logic , sa-webapp , , .

sa-webapp .

▍ sa-webapp

, Deployment - . , sa-web-app-deployment.yaml , :

 - image: rinormaloku/sentiment-analysis-web-app imagePullPolicy: Always name: sa-web-app env:   - name: SA_LOGIC_API_URL     value: "http://sa-logic" ports:   - containerPort: 8080 

env ? , , , SA_LOGIC_API_URL http://sa-logic . , , . ?

kube-dns.

▍DNS- Kubernetes

Kubernetes , kube-dns . DNS-. kube-dns , DNS- .

, sa-logic , IP-. kube-dns IP- . http://sa-logic IP-.

Deployment sa-webapp .

▍ sa-webapp

:

 kubectl apply -f sa-web-app-deployment.yaml --record deployment "sa-web-app" created 

sa-webapp , . React- , sa-webapp .

▍ sa-webapp

service-sa-web-app-lb.yaml , , , , . , , :

 kubectl apply -f service-sa-web-app-lb.yaml service "sa-web-app-lb" created 

. , , . , sa-frontend , Java- sa-webapp , http://localhost:8080/sentiment . , , sa-webapp , React- , Java-.

, . , — , , .

, :

1. IP- sa-webapp , :
   
   minikube service list
|-------------|----------------------|-----------------------------|
| NAMESPACE | NAME | URL |
|-------------|----------------------|-----------------------------|
| default | kubernetes | No node port |
| default | sa-frontend-lb | http://192.168.99.100:30708 |
| default | sa-logic | No node port |
| default | sa-web-app-lb | http://192.168.99.100:31691 |
| kube-system | kube-dns | No node port |
| kube-system | kubernetes-dashboard | http://192.168.99.100:30000 |
|-------------|----------------------|-----------------------------|
2. IP- sa-frontend/src/App.js . , :
   
   

    analyzeSentence() {       fetch('http://192.168.99.100:31691/sentiment', { /*    */})           .then(response => response.json())           .then(data => this.setState(data));   } 

3. React-, sa-frontend npm run build .
4. :
   
   

    docker build -f Dockerfile -t $DOCKER_USER_ID/sentiment-analysis-frontend:minikube. 

5. Docker Hub:
   
   

    docker push $DOCKER_USER_ID/sentiment-analysis-frontend:minikube 

6. sa-frontend-deployment.yaml , .
7. :
   
   

    kubectl apply -f sa-frontend-deployment.yaml 

, , , , minikube service sa-frontend-lb . , - .

Sumário

Kubernetes , , , , . Kubernetes , , . Kubernetes Supernetes.

, :

• , , React, Java Python.
• Docker, , Dockerfile .
• , , Docker Hub.

, Kubernetes:

, , Kubernetes.

Caros leitores! Kubernetes?