Architettura EKS Raccomandazioni Monitora le metriche del piano di controllo Autenticazione del cluster Webhooks di ammissione Gestione degli aggiornamenti dei cluster Connettività degli endpoint del cluster Esecuzione di cluster di grandi dimensioni Risorse aggiuntive:

Piano di controllo EKS

Suggerimento

Esplora le best practice attraverso i workshop Amazon EKS.

Amazon Elastic Kubernetes Service (EKS) è un servizio Kubernetes gestito che semplifica l'esecuzione di Kubernetes su AWS senza dover installare, utilizzare e mantenere il piano di controllo o i nodi di lavoro di Kubernetes. Funziona a monte di Kubernetes ed è certificato conforme a Kubernetes. Questa conformità garantisce che EKS supporti le API Kubernetes, proprio come la versione open source della community che puoi installare su EC2 o on-premise. Le applicazioni esistenti in esecuzione su Kubernetes upstream sono compatibili con Amazon EKS.

EKS gestisce automaticamente la disponibilità e la scalabilità dei nodi del piano di controllo di Kubernetes e sostituisce automaticamente i nodi del piano di controllo non integri.

Architettura EKS

L'architettura EKS è progettata per eliminare ogni singolo punto di errore che potrebbe compromettere la disponibilità e la durata del piano di controllo di Kubernetes.

Il piano di controllo Kubernetes gestito da EKS viene eseguito all'interno di un VPC gestito da EKS. Il piano di controllo EKS è composto dai nodi del server API Kubernetes, dal cluster ecc. Nodi del server API Kubernetes che eseguono componenti come il server API, lo scheduler e vengono eseguiti in un gruppo con scalabilità automatica. kube-controller-manager EKS esegue un minimo di due nodi server API in zone di disponibilità (AZ) distinte all'interno di una regione AWS. Allo stesso modo, per garantire la durabilità, i nodi del server etcd funzionano anche in un gruppo con scalabilità automatica che si estende su tre AZ. EKS esegue un gateway NAT in ogni AZ e i server API e i server etcd vengono eseguiti in una sottorete privata. Questa architettura garantisce che un evento in una singola AZ non influenzi la disponibilità del cluster EKS.

Quando crei un nuovo cluster, Amazon EKS crea un endpoint ad alta disponibilità per il server API Kubernetes gestito che utilizzi per comunicare con il tuo cluster (utilizzando strumenti come). kubectl L'endpoint gestito utilizza NLB per bilanciare il carico dei server API Kubernetes. EKS fornisce inoltre due ENI in AZ diversi per facilitare la comunicazione con i nodi di lavoro.

Connettività di rete EKS Data plane

Puoi configurare se il server API del tuo cluster Kubernetes è raggiungibile da Internet pubblico (utilizzando l'endpoint pubblico) o tramite il tuo VPC (utilizzando l'ENI) o entrambi. EKS-managed

Indipendentemente dal fatto che gli utenti e i nodi di lavoro si connettano al server API utilizzando l'endpoint pubblico o l' EKS-managed ENI, esistono percorsi di connessione ridondanti.

Raccomandazioni

Consulta i seguenti consigli.

Monitora le metriche del piano di controllo

Il monitoraggio delle metriche delle API Kubernetes può fornirti informazioni sulle prestazioni del piano di controllo e identificare i problemi. Un piano di controllo non integro può compromettere la disponibilità dei carichi di lavoro in esecuzione all'interno del cluster. Ad esempio, controller scritti male possono sovraccaricare i server API, influendo sulla disponibilità dell'applicazione.

Kubernetes espone le metriche del piano di controllo all'endpoint. /metrics

Puoi visualizzare le metriche esposte utilizzando: kubectl


kubectl get --raw /metrics

Queste metriche sono rappresentate in un formato di testo Prometheus.

Puoi usare Prometheus per raccogliere e archiviare queste metriche. A maggio 2020, è CloudWatch stato aggiunto il supporto per il monitoraggio delle metriche di Prometheus in Container Insights. CloudWatch Quindi puoi anche usare Amazon CloudWatch per monitorare il piano di controllo EKS. Puoi utilizzare Tutorial for Adding a New Prometheus Scrape Target: Prometheus KPI Server Metrics per raccogliere metriche e creare dashboard per monitorare il piano di controllo del cluster. CloudWatch

Puoi trovare le metriche del server API Kubernetes qui. https://github.com/kubernetes/apiserver/blob/master/pkg/endpoints/metrics/metrics.go Ad esempio, apiserver_request_duration_seconds può indicare quanto tempo impiegano le richieste API per essere eseguite.

Prendi in considerazione il monitoraggio di queste metriche del piano di controllo:

Server API

Metrica	Description
`apiserver_request_total`	Contatore delle richieste apiserver suddivise per ogni verbo, valore di esecuzione a secco, gruppo, versione, risorsa, ambito, componente e codice di risposta HTTP.
`apiserver_request_duration_seconds*`	Istogramma della latenza di risposta in secondi per ogni verbo, valore dry run, gruppo, versione, risorsa, sottorisorsa, ambito e componente.
`apiserver_admission_controller_admission_duration_seconds*`	Istogramma di latenza del controller di ammissione in secondi, identificato per nome e suddiviso per ogni operazione, risorsa e tipo di API (convalida o ammessa).
`apiserver_admission_webhook_rejection_count`	Conteggio dei webhook di ammissione rifiutati. Identificato da nome, operazione, rejection_code, tipo (convalida o ammissione), error_type (calling_webhook_error, apiserver_internal_error, no_error)
`rest_client_request_duration_seconds*`	Richiedi l'istogramma di latenza in secondi. Suddiviso per verbo e URL.
`rest_client_requests_total`	Numero di richieste HTTP, suddivise per codice di stato, metodo e host.

Le metriche dell'istogramma includono i suffissi _bucket, _sum e _count.

eccetera

Metrica	Description
`etcd_request_duration_seconds*`	Istogramma di latenza della richiesta Etcd in secondi per ogni operazione e tipo di oggetto.
`apiserver_storage_db_total_size_in_bytes`oppure `apiserver_storage_size_bytes` (a partire da EKS v1.28)	Dimensioni del database Etcd.

Le metriche dell'istogramma includono i suffissi _bucket, _sum e _count.

Prendi in considerazione l'utilizzo del Kubernetes Monitoring Overview Dashboard per visualizzare e monitorare le richieste e la latenza del server API Kubernetes e le metriche di latenza ecc.

Importante

Quando il limite di dimensione del database viene superato, etcd emette un allarme di assenza di spazio e smette di accettare ulteriori richieste di scrittura. In altre parole, il cluster diventa di sola lettura e tutte le richieste di mutazione di oggetti, come la creazione di nuovi pod, il ridimensionamento delle distribuzioni, ecc., verranno rifiutate dal server API del cluster.

Autenticazione del cluster

EKS attualmente supporta due tipi di autenticazione: token di bearer/service account e autenticazione IAM che utilizza l'autenticazione con token webhook. Quando gli utenti chiamano l'API Kubernetes, un webhook passa un token di autenticazione incluso nella richiesta a IAM. Il token, un URL firmato in base 64, viene generato dall'interfaccia a riga di comando di AWS (AWS CLI).

L'utente o il ruolo IAM che crea il cluster EKS ottiene automaticamente l'accesso completo al cluster. È possibile gestire l'accesso al cluster EKS modificando aws-auth configmap.

Se configuri erroneamente la aws-auth configmap e perdi l'accesso al cluster, puoi comunque utilizzare l'utente o il ruolo del creatore del cluster per accedere al tuo cluster EKS.

Nell'improbabile eventualità che non sia possibile utilizzare il servizio IAM nella regione AWS, è possibile utilizzare anche il token portante dell'account del servizio Kubernetes per gestire il cluster.

Crea un super-admin account autorizzato a eseguire tutte le azioni nel cluster:


kubectl -n kube-system create serviceaccount super-admin

Crea un'associazione di ruoli che assegna il ruolo di super-admin cluster-admin:


kubectl create clusterrolebinding super-admin-rb --clusterrole=cluster-admin --serviceaccount=kube-system:super-admin

Ottieni il segreto dell'account di servizio:


SECRET_NAME=`kubectl -n kube-system get serviceaccount/super-admin -o jsonpath='{.secrets[0].name}'`

Ottieni il token associato al segreto:


TOKEN=`kubectl -n kube-system get secret $SECRET_NAME -o jsonpath='{.data.token}'| base64 --decode`

Aggiungi account di servizio e token akubeconfig:


kubectl config set-credentials super-admin --token=$TOKEN

Imposta il contesto corrente in modo da utilizzare l'account kubeconfig super-admin:


kubectl config set-context --current --user=super-admin

La finale dovrebbe kubeconfig assomigliare a questa:


apiVersion: v1
clusters:
- cluster:
    certificate-authority-data:<REDACTED>
    server: https://<CLUSTER>.gr7.us-west-2.eks.amazonaws.com
  name: arn:aws:eks:us-west-2:<account number>:cluster/<cluster name>
contexts:
- context:
    cluster: arn:aws:eks:us-west-2:<account number>:cluster/<cluster name>
    user: super-admin
  name: arn:aws:eks:us-west-2:<account number>:cluster/<cluster name>
current-context: arn:aws:eks:us-west-2:<account number>:cluster/<cluster name>
kind: Config
preferences: {}
users:
#- name: arn:aws:eks:us-west-2:<account number>:cluster/<cluster name>
#  user:
#    exec:
#      apiVersion: client.authentication.k8s.io/v1beta1
#      args:
#      - --region
#      - us-west-2
#      - eks
#      - get-token
#      - --cluster-name
#      - <<cluster name>>
#      command: aws
#      env: null
- name: super-admin
  user:
    token: <<super-admin sa's secret>>

Webhooks di ammissione

Kubernetes dispone di due tipi di webhook di ammissione: webhook di ammissione con convalida e webhook di ammissione mutanti. Questi consentono a un utente di estendere l'API Kubernetes e convalidare o modificare gli oggetti prima che vengano accettati dall'API. Le configurazioni errate di questi webhook possono destabilizzare il piano di controllo EKS bloccando le operazioni critiche del cluster.

Per evitare di influire sulle operazioni critiche del cluster, evita di impostare webhook «generici» come i seguenti:


- name: "pod-policy.example.com"
  rules:
  - apiGroups:   ["*"]
    apiVersions: ["*"]
    operations:  ["*"]
    resources:   ["*"]
    scope: "*"

Oppure assicurati che il webhook abbia una policy di fail-open con un timeout inferiore a 30 secondi per assicurarti che, se non è disponibile, non comprometta i carichi di lavoro critici del cluster.

Blocca i pod con sysctls non sicuro

Sysctlè un'utilità Linux che consente agli utenti di modificare i parametri del kernel durante il runtime. Questi parametri del kernel controllano vari aspetti del comportamento del sistema operativo, come rete, file system, memoria virtuale e gestione dei processi.

Kubernetes consente di assegnare profili per i Podssysctl. Kubernetes è classificato come sicuro e non sicuro. systcls sysctlsI Safe sono suddivisi in namespace nel contenitore o nel Pod e la loro impostazione non ha alcun impatto sugli altri Pod sul nodo o sul nodo stesso. Al contrario, i sysctls non sicuri sono disabilitati per impostazione predefinita poiché possono potenzialmente disturbare altri Pod o rendere instabile il nodo.

Poiché gli unsafe sysctls sono disabilitati per impostazione predefinita, il kubelet non creerà un Pod con un profilo non sicuro. sysctl Se crei un Pod di questo tipo, lo scheduler assegnerà ripetutamente tali Pod ai nodi, mentre il nodo non riesce ad avviarlo. Questo ciclo infinito alla fine mette a dura prova il piano di controllo del cluster, rendendolo instabile.

Prendi in considerazione l'utilizzo di OPA Gatekeeper o Kyverno per rifiutare i Pod con unsafe. sysctls

Gestione degli aggiornamenti dei cluster

Da aprile 2021, il ciclo di rilascio di Kubernetes è stato modificato da quattro versioni all'anno (una volta al trimestre) a tre versioni all'anno. Una nuova versione minore (ad esempio 1. 21 o 1. 22) viene rilasciato all'incirca ogni quindici settimane. A partire da Kubernetes 1.19, ogni versione secondaria è supportata per circa dodici mesi dopo il primo rilascio. Con l'avvento di Kubernetes v1.28, il divario di compatibilità tra il piano di controllo e i nodi di lavoro si è esteso da n-2 a n-3 versioni secondarie. Per saperne di più, consulta Best Practices for Cluster Upgrade. Procedure consigliate per gli aggiornamenti dei cluster

Connettività degli endpoint del cluster

Quando lavori con Amazon EKS (Elastic Kubernetes Service), potresti riscontrare timeout o errori di connessione durante eventi come il ridimensionamento o l'applicazione di patch sul piano di controllo di Kubernetes. Questi eventi possono causare la sostituzione delle istanze kube-apiserver, con conseguente potenziale restituzione di indirizzi IP diversi durante la risoluzione dell'FQDN. Questo documento delinea le migliori pratiche per gli utenti delle API Kubernetes per mantenere una connettività affidabile.

Nota

L'implementazione di queste best practice può richiedere aggiornamenti alle configurazioni o agli script dei client per gestire in modo efficace le nuove strategie di ririsoluzione e riprova del DNS.

Il problema principale deriva dalla memorizzazione nella cache del DNS lato client e dalla possibilità di indirizzi IP obsoleti dell'endpoint EKS, un NLB pubblico per endpoint pubblico o per endpoint privato. X-ENI Quando le istanze kube-apiserver vengono sostituite, il Fully Qualified Domain Name (FQDN) può trasformarsi in nuovi indirizzi IP. Tuttavia, a causa delle impostazioni DNS Time to Live (TTL), che sono impostate su 60 secondi nella zona Route 53 gestita da AWS, i clienti possono continuare a utilizzare indirizzi IP obsoleti per un breve periodo di tempo.

Per mitigare questi problemi, gli utenti delle API Kubernetes (come kubectl, CI/CD pipelines e applicazioni personalizzate) dovrebbero implementare le seguenti best practice:

Implementa la ri-risoluzione DNS
Implementa i tentativi con Backoff e Jitter. Ad esempio, consulta questo articolo intitolato Failures Happen
Implementa i timeout dei client. Imposta i timeout appropriati per evitare che le richieste di lunga durata blocchino l'applicazione. Tieni presente che alcune librerie client Kubernetes, in particolare quelle generate dai generatori OpenAPI, potrebbero non consentire di impostare facilmente timeout personalizzati.
- Esempio 1 con kubectl:
```
  kubectl get pods --request-timeout 10s # default: no timeout
```
- Esempio 2 con Python: il client Kubernetes fornisce un parametro _request_timeout

Implementando queste best practice, puoi migliorare significativamente l'affidabilità e la resilienza delle tue applicazioni quando interagisci con l'API Kubernetes. Ricorda di testare attentamente queste implementazioni, specialmente in condizioni di errore simulate, per assicurarti che si comportino come previsto durante gli effettivi eventi di scalabilità o patching.

Esecuzione di cluster di grandi dimensioni

EKS monitora attivamente il carico sulle istanze del piano di controllo e le ridimensiona automaticamente per garantire prestazioni elevate. Tuttavia, è necessario tenere conto dei potenziali problemi e limiti di prestazioni all'interno di Kubernetes e delle quote nei servizi AWS quando si eseguono cluster di grandi dimensioni.

In base ai test eseguiti dal team, i cluster con più di 1000 servizi potrebbero presentare una latenza di rete durante l'utilizzo della iptables modalità kube-proxy in base ai test eseguiti dal team. ProjectCalico La soluzione è passare alla modalità running kube-proxy inipvs.
È inoltre possibile che si verifichi una limitazione delle richieste API EC2 se il CNI deve richiedere indirizzi IP per i Pods o se è necessario creare nuove istanze EC2 frequentemente. Puoi ridurre le chiamate all'API EC2 configurando il CNI per memorizzare nella cache gli indirizzi IP. È possibile utilizzare tipi di istanze EC2 più grandi per ridurre gli eventi di scalabilità EC2.

Risorse aggiuntive:

Avvertimento JavaScript è disabilitato o non è disponibile nel tuo browser.

Per usare la documentazione AWS, JavaScript deve essere abilitato. Consulta le pagine della guida del browser per le istruzioni.

Convenzioni dei documenti

Applicazioni

Piano dei dati