Aplicar atualizações de kernel e segurança aos nós do Linux no AKS (Serviço de Kubernetes do Azure)

Para proteger os clusters, as atualizações de segurança são aplicadas automaticamente aos nós do Linux no AKS. Essas atualizações incluem correções de segurança do SO ou atualizações de kernel. Algumas dessas atualizações exigem uma reinicialização do nó para concluir o processo. O AKS não reinicializa automaticamente esses nós do Linux para concluir o processo de atualização.

O processo para manter os nós do Windows Server atualizados é um pouco diferente. Os nós do Windows Server não recebem atualizações diárias. Em vez disso, você executa uma atualização do AKS que implanta novos nós com a mais recente imagem e patches do Windows Server. Para clusters do AKS que usam nós do Windows Server, confira Atualizar um pool de nós no AKS.

Este artigo mostra como usar o kured (KUbernetes REboot Daemon) de software livre para inspecionar os nós do Linux que exigem uma reinicialização e, em seguida, manipular automaticamente o reagendamento de pods em execução e o processo de reinicialização do nó.

Antes de começar

Será necessária a CLI do Azure versão 2.0.59 ou posterior instalada e configurada. Execute az --version para encontrar a versão. Se você precisa instalar ou atualizar, consulte Instalar a CLI do Azure.

Compreender a experiência de atualização do nó AKS

Em um cluster do AKS, os nós do Kubernetes executam como VMs (máquinas virtuais) do Azure. Essas VMs baseadas em Linux usam uma imagem do Ubuntu ou Azure Linux, com o SO configurado para verificar automaticamente as atualizações todos dias. Se as atualizações de segurança ou do kernel estiverem disponíveis, elas serão baixadas e instaladas automaticamente.

Algumas atualizações de segurança, como atualizações de kernel, exigem uma reinicialização do nó para finalizar o processo. Um nó do Linux que requer uma reinicialização cria um arquivo nomeado /var/run/reboot-required. Esse processo de reinicialização não ocorre automaticamente.

Você pode usar seus próprios fluxos de trabalho e processos para manipular reinicializações de nós ou usar kured para orquestrar o processo. Com kured, é implantado um DaemonSet que executa um pod em cada nó do Linux no cluster. Esses pods no DaemonSet verificam se o arquivo /var/run/reboot-required existe e, em seguida, iniciam um processo para reinicializar os nós.

Atualizações da imagem do nó

As atualizações autônomas aplicam atualizações ao SO do nó do Linux, mas a imagem usada para criar nós para o cluster permanece inalterada. Se um novo nó do Linux for adicionado ao cluster, a imagem original será usada para criar o nó. Esse novo nó recebe diariamente todas as atualizações de segurança e kernel disponíveis durante a verificação automática, mas permanece sem correção até que todas as verificações e reinicializações sejam concluídas.

Como alternativa, você pode usar a atualização de imagem do nó para verificar e atualizar as imagens de nó usadas pelo cluster. Para obter mais informações sobre a atualização de imagem de nó, confira Atualização da imagem do nó do AKS (Serviço de Kubernetes do Azure).

Upgrades de nós

Há outro processo no AKS que permite que você atualize um cluster. Um upgrade é basicamente passar para uma versão mais nova do Kubernetes, e não apenas aplicar atualizações de segurança do nó. Um upgrade de AKS executa as seguintes ações:

• Um novo nó é implantado com as atualizações de segurança mais recentes e a versão do Kubernetes aplicada.
• Um nó antigo é isolado e drenado.
• Os pods estão agendados no novo nó.
• O nó antigo é excluído.

Não será possível permanecer na mesma versão do Kubernetes durante um evento de upgrade. Você deverá especificar uma versão mais nova do Kubernetes. Para fazer upgrade para a última versão do Kubernetes, você pode fazer upgrade do seu cluster do AKS.

Implantar em um cluster do AKS

Para implantar o DaemonSet kured, instale o gráfico oficial do Kured Helm a seguir. Isso cria uma função e uma função de cluster, associações e uma conta de serviço e, em seguida, implanta o DaemonSet usando kured.

# Add the Kured Helm repository
helm repo add kubereboot https://kubereboot.github.io/charts/

# Update your local Helm chart repository cache
helm repo update

# Create a dedicated namespace where you would like to deploy kured into
kubectl create namespace kured

# Install kured in that namespace with Helm 3 (only on Linux nodes, kured is not working on Windows nodes)
helm install my-release kubereboot/kured --namespace kured --set controller.nodeSelector."kubernetes\.io/os"=linux

Você também pode configurar parâmetros extras para kured, como a integração com Prometheus ou Slack. Para obter mais informações sobre os parâmetros de configuração, consulte o gráfico Helm kured.

Atualizar nós do cluster

Por padrão, os nós do Linux no AKS procuram atualizações todas as noites. Se não quiser esperar, poderá executar manualmente uma atualização para verificar se kured executa corretamente. Primeiro, siga as etapas para SSH para um dos nós do AKS. Quando houver uma conexão SSH com o nó do Linux, verifique as atualizações e aplique-as conforme o seguinte:

sudo apt-get update && sudo apt-get upgrade -y

Se forem aplicadas atualizações que exigem uma reinicialização do nó, um arquivo será gravado em /var/run/reboot-required. Kured verifica por nós que exigem uma reinicialização a cada 60 minutos por padrão.

Monitorar e revisar o processo de reinicialização

Quando uma das réplicas no DaemonSet detecta que é necessária uma reinicialização do nó, um bloqueio é colocado no nó por meio da API Kubernetes. Esse bloqueio impede que mais pods sejam agendados no nó. O bloqueio também indica que apenas um nó deverá ser reinicializado de cada vez. Com o nó isolado, os pods em execução serão drenados do nó e o nó será reinicializado.

É possível monitorar o status dos nós usando o comando kubectl get nodes. A seguinte saída de exemplo mostra um nó com um status SchedulingDisabled, na medida em que o nó se prepara para o processo de reinicialização:

NAME                       STATUS                     ROLES     AGE       VERSION
aks-nodepool1-28993262-0   Ready,SchedulingDisabled   agent     1h        v1.11.7

Quando o processo de atualização estiver concluído, você poderá exibir o status dos nós usando o comando kubectl get nodes com o parâmetro --output wide. Essa saída permite que você veja uma diferença na KERNEL-VERSION dos nós subjacentes, conforme mostrado no exemplo de saída a seguir. O nó aks-nodepool1-28993262-0 foi atualizado em uma etapa anterior e mostra a versão do kernel 4.15.0-1039-azure. O nó aks-nodepool1-28993262-1 que não foi atualizado mostra a versão do kernel 4.15.0-1037-azure.

NAME                       STATUS    ROLES     AGE       VERSION   INTERNAL-IP   EXTERNAL-IP   OS-IMAGE             KERNEL-VERSION      CONTAINER-RUNTIME
aks-nodepool1-28993262-0   Ready     agent     1h        v1.11.7   10.240.0.4    <none>        Ubuntu 16.04.6 LTS   4.15.0-1039-azure   docker://3.0.4
aks-nodepool1-28993262-1   Ready     agent     1h        v1.11.7   10.240.0.5    <none>        Ubuntu 16.04.6 LTS   4.15.0-1037-azure   docker://3.0.4

Próximas etapas

Este artigo detalhou como usar kured para reinicializar os nós do Linux automaticamente como parte do processo de atualização de segurança. Para fazer upgrade para a última versão do Kubernetes, você pode fazer upgrade do seu cluster do AKS.

Para clusters do AKS que usam nós do Windows Server, confira Atualizar um pool de nós no AKS.

Para obter uma discussão detalhada sobre as melhores práticas de atualização e outras considerações, veja Diretrizes de patch e atualização do AKS.