Gerenciando o ciclo de vida do app

Use ferramentas de Kubernetes-nativos e de terceiros para realizar atualizações de rolamento e rollbacks de apps sem downtime para seus usuários.

Estratégias de atualização

Para atualizar o seu app, é possível escolher entre várias estratégias como as seguintes. É possível começar com uma implementação contínua ou uma alternância instantânea antes de continuar para uma implementação canary mais complicada.

Implementação contínua: É possível usar a funcionalidade nativa do Kubernetes para criar uma implementação da v2 e substituir gradualmente sua implementação anterior da v1. Essa abordagem requer que os apps sejam compatíveis com versões anteriores para que os usuários que são atendidos pela versão do app v2 não sofram nenhuma mudança radical. Para obter mais informações, consulte Gerenciando implementações contínuas para atualizar seus apps.
Alternância instantânea: Também conhecida como uma implementação azul-verde, uma alternância instantânea requer o dobro dos recursos de cálculo para ter duas versões de um mesmo app em execução ao mesmo tempo. Com essa abordagem, é possível alternar seus usuários para a versão mais recente em tempo quase real. Certifique-se de usar seletores de etiqueta de serviço (como version: green e version: blue) para garantir que as solicitações sejam enviadas para a versão correta do aplicativo. É possível criar a nova implementação version: green, aguardar até que ela esteja pronta e, em seguida, excluir a implementação version: blue. Ou é possível executar uma atualização contínua, mas configurar o parâmetro maxUnavailable para 0% e o parâmetro maxSurge para 100%.
Implementação canary ou A/B: Uma implementação canary, que é uma estratégia de atualização mais complexa, consiste na escolha de uma porcentagem de usuários, como 5%, e seu envio para a nova versão do app. Você coleta métricas em suas ferramentas de criação de log e monitoramento sobre como a nova versão do app está sendo executada, realiza testes A/B e, em seguida, apresenta a atualização para mais usuários. Como com todas as implementações, rotular o app (como version: stable e version: canary) é crítico. Para gerenciar implementações canárias, é possível instalar a malha de serviço do complemento do Istio gerenciado, configurar o Monitoring para o cluster e, em seguida, usar a malha de serviço do Istio para teste A/B, conforme descrito nesta postagem do blog.

Ajuste de escala de apps

Com o Kubernetes, é possível ativar o ajuste automático de escala de pod horizontal para aumentar ou diminuir automaticamente o número de instâncias dos apps com base na CPU.

Deseja escalar seus nós do trabalhador em vez de seus pods? Efetue check-out do cluster autoscaler .

Antes de Iniciar:

Efetue login na sua conta. If applicable, target the appropriate resource group. Configure o contexto para o seu cluster.
Certifique-se de que esteja designado a uma função de acesso de serviço que conceda a função RBAC apropriada do Kubernetes para poder trabalhar com recursos do Kubernetes no namespace.

Para dimensionar seus aplicativos:

Implemente seu app em um cluster por meio da CLI. Para implementações mais complexas, você pode precisar criar um arquivo de configuração.
```
kubectl create deployment <app_name> --image=<image>
```
Configure os limites de recursos da CPU em milicores para os contêineres que são executados em sua implementação, como 100m. Também é possível configurar limites de memória, mas o autoscaler de pod horizontal só considera os limites de recursos da CPU para propósitos de ajuste de escala. Para obter mais informações, consulte a documentação do kubectl set resources.
```
kubectl set resources deployment <app_name> --limits=cpu=100m
```

Crie um autoscaler de pod horizontal e defina sua política. Para obter mais informações, consulte a documentação do kubectl autoscale.

kubectl autoscale deployment <deployment_name> --cpu-percent=<percentage> --min=<min_value> --max=<max_value>

Entendendo suas opções de comando
Opções	Descrição
`--cpu-percent`	A utilização média da CPU que é mantida pelo Escalador automático de ajuste de pod horizontal, que é especificada em porcentagem.
`--min`	O número mínimo de pods implementados que são usados para manter a porcentagem de utilização da CPU especificada.
`--max`	O número máximo de pods implementados que são usados para manter a porcentagem de utilização da CPU especificada.

Gerenciando implementações contínuas para atualizar seus apps

É possível gerenciar o lançamento de suas mudanças de app em um modo automatizado e controlado para cargas de trabalho com um modelo de pod, como implementações. Se a sua apresentação não estiver indo de acordo com o plano, será possível recuperar a sua implementação para a revisão anterior.

Deseja evitar o tempo de inatividade durante a atualização contínua? Certifique-se de especificar uma análise de prontidão em sua implementação para que o lançamento continue no próximo pod de app após o pod atualizado mais recentemente estar pronto.

Antes de Iniciar:

Efetue login na sua conta. If applicable, target the appropriate resource group. Configure o contexto para o seu cluster.
Crie uma implementação.
Certifique-se de que tenha uma função de acesso ao serviço que concede a função apropriada de RBAC do Kubernetes para poder trabalhar com recursos do Kubernetes no namespace.

Para gerenciar atualizações contínuas para seus apps:

Para certificar-se de que suas implementações sejam marcadas como prontas apenas quando o contêiner estiver em execução e pronto para solicitações de serviço, inclua análises de atividade e prontidão em sua implementação.
Atualize sua implementação para incluir uma estratégia de atualização contínua que especifique o aumento máximo e os pods indisponíveis ou a porcentagem de pods durante a atualização.
```
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-test
spec:
  replicas: 10
  selector:
    matchLabels:
      service: http-server
  minReadySeconds: 5
  progressDeadlineSeconds: 600
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 50%
      maxSurge: 2
...
```
spec.minReadySeconds

Por padrão, as implementações aguardam até que o pod seja marcado como ready para continuar com o lançamento. Se perceber que a implementação continua criando pods mesmo que seu app no pod mais recente ainda não esteja pronto, use esse campo para desacelerar o lançamento da implementação. Por exemplo, se você especificar 5, a implementação aguardará por 5 segundos após o pod estar ready antes de criar o próximo pod.

spec.progressDeadlineSeconds

Configure um tempo limite, em segundos, antes de considerar que uma implementação falhou. Por exemplo, sem um tempo limite, se a nova versão do app tiver um bug e parar imediatamente, o lançamento não poderá continuar porque o pod nunca chegará a um estado ready. Se você configurar esse tempo limite para 600 segundos e ocorrer uma falha na continuação de qualquer fase do lançamento por 10 minutos, a implementação será marcada como com falha e o lançamento será interrompido.

spec.strategy.type

Especifique o tipo de estratégia RollingUpdate.

spec.strategy.rollingUpdate.maxUnavailable

Configure o número máximo de pods que podem ficar indisponíveis durante uma atualização, como um número (2) ou uma porcentagem (50%). Use, de maneira geral, uma porcentagem para que não seja preciso se lembrar de atualizar o número caso você mude o número de réplicas posteriormente, a menos que queira limitar o lançamento para permitir que apenas um pod fique inativo por vez. Se você não quiser que a capacidade caia abaixo de 100%, defina esse valor como “ 0% ” e especifique o parâmetro “ spec.strategy.type.rollingUpdate.maxSurge ”.

spec.strategy.rollingUpdate.maxSurge

Configure quantos recursos extras a implementação pode usar durante o lançamento, como um número (2) ou porcentagem (50%). Por exemplo, se sua implementação especificar 10 réplicas e você configurar o maxSurge como 2, então, durante o lançamento, duas novas réplicas serão criadas. Agora, você tem 12 réplicas (10 existentes, duas novas). Após as duas novas réplicas estarem prontas, a implementação reduzirá a escala das réplicas antigas para 8 para atender às 10 réplicas especificadas. Esse processo continua até a conclusão do lançamento e até que todas as 10 réplicas executem a nova versão.

Para realizar uma atualização de estilo comutador instantâneo azul-verde, configure o maxSurge para 100%. A implementação cria todas as novas réplicas necessárias e, em seguida, diminui a capacidade das réplicas da versão antiga para 0.

Apresente uma mudança. Por exemplo, talvez você queira mudar a imagem usada na implementação inicial.

Obtenha o nome da implementação.

    kubectl get deployments
    ```
2. Obtenha o nome do pod.

```sh {: pre}
    kubectl get pods
    ```
3. Obtenha o nome do contêiner que é executado no pod.

```sh {: pre}
    kubectl describe pod <pod_name>
    ```
4. Configure a nova imagem para a implementação para usar.

```sh {: pre}
    kubectl set image deployment/<deployment_name> <container_name>=<image_name>
    ```
Ao executar os comandos, a mudança é imediatamente aplicada e registrada no histórico de apresentação.

Verifique o status de sua implementação.
```
kubectl rollout status deployments/<deployment_name>
```
Se observar algo no status que queira acompanhar por um tempo, será possível pausar e continuar o lançamento com os comandos a seguir.
```
kubectl rollout pause deployment <deployment_name>
```
```
kubectl rollout resume deployment <deployment_name>
```

Recupere uma mudança.

Visualize o histórico de apresentação da implementação e identifique o número da revisão de sua última implementação.

    kubectl rollout history deployment/<deployment_name>
    ```
    Para ver os detalhes para uma revisão específica, inclua o número
    da revisão.
    {: tip}

    ```sh {: pre}
    kubectl rollout history deployment/<deployment_name> --revision=<number>
    ```
2. Recupere para a versão anterior ou especifique uma revisão. Para recuperar para a versão anterior, use o comando a seguir.

```sh {: pre}
    kubectl rollout undo deployment/<deployment_name> --to-revision=<number>
    ```

Configurando integração e entrega contínuas

Com o IBM Cloud e outras ferramentas de software livre, é possível configurar integração e entrega contínuas (CI/CD), controle de versão, cadeias de ferramentas e mais para ajudar a automatizar o desenvolvimento e a implementação do app.

Para ver uma lista de integrações compatíveis e as etapas para configurar um pipeline de entrega contínua, consulte as integrações disponíveis no console IBM Cloud e a documentação relacionada ao cluster.

Copiando implementações em outro cluster

Ao utilizar um sistema de controle de versão, como o Git, projetos de gerenciamento de configuração ou ferramentas de entrega contínua em seu cluster, você pode implantar os arquivos de configuração do seu aplicativo rapidamente de um cluster para outro. Às vezes, você tem apenas algumas implementações testadas em um cluster e prefere copiar essas implementações e realizar a reimplementação em outro cluster.

Antes de começa, são necessários dois clusters e a função de acesso de serviço Gerenciador para todos os namespaces em ambos os clusters para que seja possível copiar todos os recursos de um cluster e implementá-los em outro.

Efetue login na sua conta. If applicable, target the appropriate resource group. Configure o contexto para o seu cluster.

Liste todos os arquivos de configuração em seu cluster e verifique se deseja copiar essas configurações.

kubectl get all

Saída de exemplo

NAME                                   READY   STATUS             RESTARTS   AGE
pod/java-web-6955bdbcdf-l756b          1/1     Running            0          59d
NAME                                   TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)          AGE
service/java-web                       NodePort    172.21.xxx.xxx   <none>        8080:30889/TCP   59d
NAME                                   READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/java-web               1/1     1            1           59d
NAME                                   DESIRED   CURRENT   READY   AGE
replicaset.apps/java-web-6955bdbcdf    1         1         1       59d

Copie os arquivos de configuração em seu cluster para um diretório local. Em seguida, remova manualmente os campos específicos do cluster, como resourceVersion, uid, creationTimestamp e status, do arquivo YAML exportado antes de aplicar os arquivos a outro cluster.
```
kubectl get all -o yaml > myconfigs.yaml
```
Efetue login na sua conta. If applicable, target the appropriate resource group. Configure o contexto para o seu cluster.
Opcional: Se o seu cluster utilizava vários namespaces, crie os mesmos namespaces no cluster padrão e copie o segredo de pull da imagem para cada namespace.
Implemente os arquivos de configuração copiados em seu cluster. Se um arquivo de configuração tiver informações específicas que não podem ser aplicadas, será necessário atualizar o arquivo de configuração e reaplicar.
```
kubectl apply -f myconfigs.yaml
```
Saída de exemplo
```
pod/java-web-6955bdbcdf-l756b created
service/java-web created
deployment.apps/java-web created
replicaset.apps/java-web-6955bdbcdf created
```
Verifique se seus arquivos de configuração foram aplicados.
```
kubectl get all
```