Visão geral
Um limite de ID do processo (PID) é uma restrição de recursos do Kubernetes em nós e pods para evitar a criação excessiva de processos, o que pode afetar a estabilidade do nó. A Apigee híbrida oferece suporte ao recurso do Kubernetes para definir limites de ID de processo. Este documento fornece instruções sobre como definir esses limites, com recomendações de valores para serviços da Apigee em plataformas específicas.
Quando os usuários da Apigee híbrida gerenciam os próprios clusters, definir limites de PID no Kubernetes pode melhorar a estabilidade, a segurança e o gerenciamento de recursos do sistema. Isso também está de acordo com as práticas recomendadas do Kubernetes.
Definições de limites de ID de processo
Os limites de ID do processo incluem limites de PID do nó e do pod.
Os limites de PID do nó incluem PIDs reservados pelo Kube e pelo sistema. O número total de PIDs alocáveis é o máximo do kernel menos os PIDs kube-reserved, os PIDs system-reserved e os PIDs de limite de remoção:
Limites máximos de ID do kernel |
|
|
|
= Alocável |
- Limites máximos de ID do kernel: determinados pelo sistema operacional e pelas configurações do kernel. Como o Apigee híbrido é executado exclusivamente em um kernel do Linux, este guia aborda os limites baseados em Linux nos nós do Kubernetes. O número máximo de limites de ID de processo para um kernel do Linux é 4194304.
- Kube-reserved e system-reserved: para reserva de recursos para daemons do sistema do Kubernetes ou do SO.
- Limite de remoção: o limite que indica pressão no nó. O nó será removido quando o limite for atingido. Consulte Remoção baseada em PID para mais detalhes.
- Alocável: o número de PIDs disponíveis. Consulte Kubernetes: recursos alocáveis do nó para mais informações. As configurações kube-reserved e system-reserved podem ser configuradas com as configurações de limite de PID do nó.
O limite de PID do pod pode ser configurado para o nó e compartilhado entre todos os pods dentro dele.
Preparar-se para gerenciar os limites de ID do processo
Esses procedimentos usam as seguintes variáveis de ambiente:
export PROJECT_ID=MY_PROJECT_IDexport CLUSTER_NAME=MY_CLUSTER_NAME
export LOCATION=MY_CLUSTER_LOCATION
export APIGEE_NAMESPACE=MY_APIGEE_NAMESPACE # Default: apigee
Verifique o acesso
Antes de configurar o limite de ID do processo, verifique se você tem acesso para editar clusters do Kubernetes.
As etapas a seguir são para instalações no GKE. Para outras plataformas, consulte a documentação específica.
-
Verifique se você tem roles/container.clusterAdmin na política do IAM:
gcloud projects get-iam-policy ${PROJECT_ID} \ --flatten="bindings[].members" \ --format='table(bindings.role)' \ --filter="bindings.members:your_account_email"
- Se você não tiver acesso, adicione a função à sua conta:
gcloud projects add-iam-policy-binding ${PROJECT_ID} \ --member user:your_account_email \ --role roles/container.clusterAdmin
Verificar os limites de PID atuais
Verifique se o nó tem limites de PID antes de configurar novos limites.
-
Extraia um nó do cluster para verificar os valores. Você precisa verificar os nós dos pools
apigee-data
eapigee-runtime
:kubectl get nodes -n ${APIGEE_NAMESPACE}
A saída será parecida com esta:
NAME STATUS ROLES AGE VERSION gke-my-hybrid-apigee-data-0a1b2c3d-efgh Ready
2d8h v1.31.5-gke.1169000 gke-my-hybrid-apigee-runtime-1b2c3d4e-fghi Ready 2d8h v1.31.5-gke.1169000 -
Exporte o nome do nó da saída da etapa anterior. Execute a próxima etapa primeiro para um nó
apigee-data
e depois para um nóapigee-runtime
:Código
export NODE_NAME=MY_NODE_NAME
Exemplo
export NODE_NAME="gke-my-hybrid-apigee-data-0a1b2c3d-efgh"
- Verifique os limites de PID do nó. Use os comandos a seguir para verificar os valores reservados. Se o valor for nulo, ele não estará configurado:
kubectl get --raw "/api/v1/nodes/${NODE_NAME}/proxy/configz" | jq '.kubeletconfig.kubeReserved'
kubectl get --raw "/api/v1/nodes/${NODE_NAME}/proxy/configz" | jq '.kubeletconfig.systemReserved'
kubectl get --raw "/api/v1/nodes/${NODE_NAME}/proxy/configz" | jq '.kubeletconfig.evictionHard'
- Verifique o limite de PID do pod. Use o comando a seguir para verificar o limite de PID do pod atual. Se o valor retornado for
-1
ou estiver vazio, o limite não será definido:kubectl get --raw "/api/v1/nodes/${NODE_NAME}/proxy/configz" | jq '.kubeletconfig.podPidsLimit'
Gerenciar os limites de ID do processo
Gerenciar os limites de PID do nó
Para instalações no GKE, os recursos de infraestrutura dos nós do Kubernetes são gerenciados internamente, e você não precisa configurá-los. Para conferir a capacidade atual e os recursos alocáveis, siga as instruções em Recursos alocáveis de nós na documentação do Google Kubernetes Engine.
Para plataformas que não são do GKE, consulte a documentação correspondente do Kubernetes. Se o cluster/nó for gerenciado pelo usuário (em vez de totalmente gerenciado), o limite de PID kube-reserved e o limite de PID system-reserved poderão ser configurados com o Kubelet. Consulte Limites de PID do nó na documentação do Kubernetes.
Ferramentas
Este procedimento usa o Kubelet para gerenciar o limite de ID do processo. O kubelet é o agente que é executado em pods e contêineres e garante que eles estejam em execução de acordo com o PodSpec. Se você precisar instalar o Kubelet, siga as instruções na documentação do Kubernetes: Instalar kubeadm, kubelet e kubectl (em inglês).
Procedimento
-
Crie um arquivo de configuração do Kubelet chamado
kubelet-config.yaml
.apiVersion: kubelet.config.k8s.io/v1beta1 kind: KubeletConfiguration kubeReserved: pid: PID_VALUE # Example: 1000
Confira mais informações sobre as configurações: Kube Reserved na documentação do Kubernetes.
-
Aplique a configuração do Kubelet:
kubelet --config PATH_TO_KUBELET_CONFIG_YAML
Gerenciar os limites de PID do pod
Escolher o limite
Se o limite de PID estiver muito baixo, isso pode impedir a inicialização de um pod. Se ele estiver muito alto, pode não detectar comportamentos inadequados de recursos. Ao selecionar o limite adequado, é importante considerar o comportamento anterior do nó e os requisitos específicos do serviço.
O GKE tem um intervalo obrigatório para o valor: [1024, 4194304]. Nas plataformas do GKE, é possível conferir o status das suas contas de serviço do Kubernetes no Google Cloud console Metrics Explorer. Selecione as métricas Nó do Kubernetes: uso de PID e aplique filtros. Essa métrica mostra o uso recente de IDs de processos e pode ser consultada ao escolher um limite de PID.
Em plataformas que não são do GKE, outras opções de monitoramento podem estar disponíveis. Consulte a documentação do Kubernetes da plataforma correspondente para verificar as métricas.
Requisitos de ID do processo para pods do Apigee
A Apigee híbrida usa dois pools de nós, apigee-data e apigee-runtime. Como alguns dos componentes da Apigee são implantados nos dois pools de nós, o limite de PID do pod precisa ser o mesmo para os dois pools. O limite de PID do pod também precisa ser maior que o número máximo de PIDs necessários em todos os pods do Apigee. O limite de PID do pod do Apigee necessário é 1.000, que está abaixo do número mínimo exigido para plataformas do GKE.
Limite recomendado de PIDs de pods
Algumas plataformas exigem um valor mínimo para o número de PIDs do pod. Nesse caso, o requisito de valor mínimo é selecionado.
Plataforma | Limite mínimo de PID do pod |
---|---|
GKE no Google Cloud | 1024 |
GKE na AWS | 1024 |
GKE no Azure | 1024 |
Google Distributed Cloud (somente software) no VMware | 1024 |
Google Distributed Cloud (somente software) em bare metal | 1024 |
EKS | 1000 |
AKS | 1000 |
OpenShift | 1000 |
Rancher Kubernetes Engine (RKE)(7) | 1000 |
Procedimento
Os procedimentos para gerenciar os limites de PID do pod são diferentes para plataformas do GKE e que não são do GKE.
Plataforma do GKE
A plataforma do GKE que oferece suporte à atualização do limite de PID inclui:
- GKE no Google Cloud: consulte gcloud container node-pools.
- GKE na AWS: consulte gcloud container aws node-pools.
- GKE no Azure: consulte gcloud container azure node-pools.
- Google Distributed Cloud (somente software) no VMware: consulte gcloud container vmware node-pools
- Google Distributed Cloud (somente software) em bare metal: consulte gcloud container bare-metal node-pools
O limite de PID do pod é controlado pelas configurações do sistema de nós. O GKE tem um intervalo obrigatório para o valor: [1024, 4194304]. Para mais informações, consulte NodeKubeletConfig.
-
Crie uma configuração do sistema de nós chamada
node-config.yaml
com o limite de PID de pod designado com o seguinte conteúdo:kubeletConfig: podPidsLimit: POD_PID_VALUE # Example: 1024
-
Aplique a configuração aos pools de nós
apigee-data
eapigee-runtime
do Apigee. Quando você aplica a configuração, o nó inicia o lançamento com uma das estratégias de upgrade de nó sem tempo de inatividade.gcloud container OPTIONAL_HOST_PLATFORM node-pools update NODE_POOL_NAME \ --cluster CLUSTER_NAME \ --region CLUSTER_LOCATION \ --system-config-from-file=node-config.yaml \ --project PROJECT_ID
Plataformas que não são do GKE
Em plataformas que não são do GKE, o limite de PID do pod é controlado pelo Kubelet. O limite é definido pelo campo podPidsLimit
no arquivo de configuração do kubelet.
-
Crie um arquivo de configuração do Kubelet chamado
kubelet-config.yaml
com o seguinte conteúdo:apiVersion: kubelet.config.k8s.io/v1beta1 kind: KubeletConfiguration podPidsLimit: POD_PID_VALUE # Example: 1024
-
Aplique a configuração. Para definir o podPidsLimit, é necessário reiniciar o nó afetado, o que pode causar inatividade:
kubelet --config PATH_TO_KUBELET_CONFIG_YAML
- Verifique a configuração. Consulte Verificar limites de PID atuais para instruções.
Os comandos de configuração e as recomendações de ferramentas para limites de PID de pods variam em diferentes plataformas. Consulte a documentação das respectivas plataformas para ver comandos detalhados. Confira abaixo alguns links de documentação de plataformas que não são do GKE para referência. Elas estão sujeitas a mudanças:
Plataforma | Documentação |
---|---|
EKS | Personalizar nós gerenciados com modelos de inicialização |
AKS | Personalizar a configuração de nós para pools de nós do Azure Kubernetes Service (AKS) |
OpenShift | Riscos de definir limites mais altos de ID de processo para pods do Red Hat OpenShift Service na AWS |
Rancher Kubernetes Engine (RKE)(7) | Acessar um cluster com kubectl e kubeconfig |
Solução de problemas com limites de ID de processo
Pod travado no status Pending
com um erro FailedScheduling
Quando o limite de PIDs do nó ou do pod remove ou impede a inicialização de um pod, ele fica preso no status Pending
e falha com o erro FailedScheduling
.
-
Acesse a coluna "Node":
kubectl get pods -n ${APIGEE_NAMESPACE} ${POD_NAME} -o wide
-
Verifique se há uma condição
PIDPressure
:kubectl describe node -n apigee ${NODE_NAME} | grep PIDPressure
-
Ou verifique
ApigeeDeployment
do pod correspondente. Extraia oApigeeDeployment
do resultado que tem o mesmo prefixo do pod com erro.kubectl get ApigeeDeployment -n ${APIGEE_NAMESPACE}
-
Verifique se o
Events
recente tem mensagens de erro relacionadas ao PID:kubectl describe ApigeeDeployment -n ${APIGEE_NAMESPACE} ${APIGEE_DEPLOYMENT_NAME}
- Se a causa for confirmada como limite de PID, siga as etapas em Gerenciar os limites de PID do nó para atualizar o limite de PID para um valor maior.
podPidsLimit
inválido
Ao definir o limite para o GKE, se o podPidsLimit
estiver além do limite, o erro vai aparecer:
ERROR: (gcloud.container.node-pools.update) ResponseError: code=400, message=Invalid podPidsLimit: value must be 1024 <= podPidsLimit <= 4194304.
Atualize o valor de podPidsLimit para o intervalo necessário.