O ACK Edge permite implantar pods de aplicação em nós de borda e acessar o servidor de API do Kubernetes via InClusterConfig, sem modificar os próprios pods. Este tópico explica como o edge-hub intercepta e redireciona o tráfego de API de forma transparente e como ativar o cache local para permitir a reinicialização correta dos pods durante interrupções na conexão com a nuvem.
Como funciona
Ao mover um pod de aplicação de um cluster na nuvem para um nó de borda, dois problemas surgem se o pod utilizar InClusterConfig:
Isolamento de rede: O InClusterConfig lê
KUBERNETES_SERVICE_HOSTeKUBERNETES_SERVICE_PORTpara localizar o servidor de API do Kubernetes. Na borda, o pod está em uma rede diferente da rede do servidor de API na nuvem, tornando o endereço padrão inacessível.Falha na reinicialização: Se a conexão com a nuvem for interrompida e o pod reiniciar, ele não conseguirá contatar o servidor de API para obter sua configuração de carga de trabalho, bloqueando a reinicialização.
O edge-hub resolve ambos os problemas sem exigir alterações no pod.
Quando a conexão com a nuvem está estável
O edge-hub intercepta o tráfego do pod destinado ao servidor de API ao reescrever transparentemente as variáveis de ambiente do pod. Ele altera KUBERNETES_SERVICE_HOST para 169.254.2.1 e KUBERNETES_SERVICE_PORT para 10268 (o endpoint HTTPS local do edge-hub).
Como o edge-hub reescreve esses valores no nível do nó, o pod se conecta ao proxy local do edge-hub em vez do servidor de API remoto, sem perceber o redirecionamento.
Além disso, o edge-hub armazena em cache localmente as respostas da API conforme as recebe do servidor, mantendo o cache atualizado enquanto a conexão estiver estável.
Quando a conexão com a nuvem é interrompida
Se o recurso de cache estiver ativado, o edge-hub atenderá às solicitações do pod a partir de seu cache em disco local. Isso permite que os pods iniciem e recuperem suas configurações de carga de trabalho mesmo sem conexão com a nuvem.
Caso o cache não esteja ativado, os pods que reiniciarem durante uma interrupção de rede não conseguirão recuperar suas configurações de carga de trabalho e falharão ao iniciar.
Pré-requisitos
Antes de começar, verifique se você tem:
Um cluster ACK Edge com o edge-hub em execução nos nós de borda
O pod de aplicação implantado em um nó de borda e configurado para usar InClusterConfig
Ative o recurso de cache do edge-hub
Para ativar o cache do seu pod de aplicação, adicione seu User-Agent ao campo cache_agents no ConfigMap edge-hub-cfg.
Desative o cache para pods que emitem um alto volume de solicitações list ou watch, pois os dados em cache são armazenados no disco local e podem consumir espaço significativo. Reinicie os pods após ativar o cache.
Passo 1: Encontre o User-Agent do pod
O User-Agent é o nome do componente que seu pod usa ao fazer solicitações ao servidor de API. Encontre-o em um destes dois locais:
No comando de inicialização do pod: O User-Agent corresponde ao nome do binário no comando de inicialização.
apiVersion: v1
kind: Pod
metadata:
name: edge-app-pod
spec:
containers:
- name: "edge-app"
image: "xxx/edge-app-amd64:1.18.8"
command:
- /bin/sh
- -ec
- |
# User-Agent is derived from the binary name: edge-app
/usr/local/bin/edge-app --v=2
Nos logs do edge-hub: Pesquise por linhas de log que correspondam ao padrão {User-Agent} get/watch {resource}. Por exemplo:
I0820 07:50:18.899015 1 util.go:221] edge-app get services: /api/v1/services/xxx with status code 200, spent 21.035061152ms
Neste exemplo, o User-Agent é edge-app.
Passo 2: Adicione o User-Agent ao ConfigMap
Edite o ConfigMap edge-hub-cfg no namespace kube-system e adicione o User-Agent do pod em cache_agents. Separe vários valores com vírgulas.
apiVersion: v1
kind: ConfigMap
metadata:
name: edge-hub-cfg
namespace: kube-system
data:
# Cache API responses for the pod whose User-Agent is "edge-app".
# Restart the pod after making this change.
cache_agents: "edge-app" # Separate multiple components with commas (,).
Após salvar o ConfigMap, reinicie o pod de aplicação para que a alteração tenha efeito.
Passo 3: Verifique se o cache está ativo
No nó de borda que hospeda o pod de aplicação, verifique se existem dados de cache em:
/etc/kubernetes/cache/{User-Agent}
Próximos passos
Saiba mais sobre Acessando a API a partir de um pod