chaostoolkit/chaostoolkit-kubernetesEstensione del driver Kubernetes delle API di probes e actions del Chaos Toolkit
Questo progetto contiene attività, come probe e azioni, che puoi richiamare dal tuo esperimento tramite Chaos Toolkit per eseguire Chaos Engineering contro l'API di Kubernetes: terminare un pod, rimuovere uno statefulset o un nodo...
Per essere utilizzato nei tuoi esperimenti, questo pacchetto deve essere installato nell'ambiente Python in cui è già presente chaostoolkit.
$ pip install chaostoolkit-kubernetes
Per utilizzare le probe e le azioni di questo pacchetto, aggiungi quanto segue al tuo file di esperimento:
{
"title": "Do we remain available in face of pod going down?",
"description": "We expect Kubernetes to handle the situation gracefully when a pod goes down",
"tags": ["kubernetes"],
"steady-state-hypothesis": {
"title": "Verifying service remains healthy",
"probes": [
{
"name": "all-our-microservices-should-be-healthy",
"type": "probe",
"tolerance": true,
"provider": {
"type": "python",
"module": "chaosk8s.probes",
"func": "microservice_available_and_healthy",
"arguments": {
"name": "myapp"
}
}
}
]
},
"method": [
{
"type": "action",
"name": "terminate-db-pod",
"provider": {
"type": "python",
"module": "chaosk8s.pod.actions",
"func": "terminate_pods",
"arguments": {
"label_selector": "app=my-app",
"name_pattern": "my-app-[0-9]$",
"rand": true
}
},
"pauses": {
"after": 5
}
}
]
}
Tutto qui! Nota come l'azione ti consenta di terminare un pod in modo casuale.
Esplora la documentazione per vedere le probe e le azioni disponibili.
Nota: per gli stressor di rete, CPU e memoria ci affidiamo al fantastico progetto Chaos Mesh che fornisce un'ottima interfaccia per iniettare questi guasti.
Dovrai installare Chaos Mesh nel tuo cluster prima di poterli utilizzare.
Se hai una voce valida nel tuo file ~/.kube/config per il cluster a cui vuoi fare riferimento, non devi fare nulla.
Puoi specificare KUBECONFIG per indicare una posizione diversa.
$ export KUBECONFIG=/tmp/my-config
Spesso la tua configurazione Kubernetes contiene più voci e devi definire quella da usare come contesto predefinito quando non viene fornito esplicitamente.
Ovviamente puoi cambiare il tuo predefinito usando kubectl config use-context KUBERNETES_CONTEXT, ma puoi anche essere esplicito nel tuo esperimento come segue:
{
"title": "Do we remain available in face of pod going down?",
"description": "We expect Kubernetes to handle the situation gracefully when a pod goes down",
"tags": ["kubernetes"],
"secrets": {
"k8s": {
"KUBERNETES_CONTEXT": "..."
}
},
"steady-state-hypothesis": {
"title": "Verifying service remains healthy",
"probes": [
{
"name": "all-our-microservices-should-be-healthy",
"type": "probe",
"tolerance": true,
"secrets": ["k8s"],
"provider": {
"type": "python",
"module": "chaosk8s.probes",
"func": "microservice_available_and_healthy",
"arguments": {
"name": "myapp"
}
}
}
]
},
"method": [
{
"type": "action",
"name": "terminate-db-pod",
"secrets": ["k8s"],
"provider": {
"type": "python",
"module": "chaosk8s.pod.actions",
"func": "terminate_pods",
"arguments": {
"label_selector": "app=my-app",
"name_pattern": "my-app-[0-9]$",
"rand": true
}
},
"pauses": {
"after": 5
}
}
]
}
Devi specificare la chiave segreta KUBERNETES_CONTEXT con il nome del contesto che vuoi che l'esperimento utilizzi. Assicurati anche di comunicare alle azioni e alle probe le voci segrete da passare loro, "secrets": ["k8s"].
Quando si esegue da un pod (non dalla tua macchina locale o da una CI, ad esempio), il file ./.kube/config non esiste. Le credenziali si trovano invece in /var/run/secrets/kubernetes.io/serviceaccount/token.
Per comunicare questo all'estensione, imposta semplicemente CHAOSTOOLKIT_IN_POD tramite la variabile d'ambiente della specifica del pod:
env:
- name: CHAOSTOOLKIT_IN_POD
value: "true"
Quando si utilizza questa variabile d'ambiente, si presume che l'esperimento abbia come target lo stesso cluster da cui viene eseguito. Se il tuo esperimento ha come target un cluster diverso, non dovresti impostare questa variabile. In alternativa, puoi montare un volume con una configurazione Kubernetes per il cluster di destinazione e impostare KUBECONFIG in modo che punti a essa.
Infine, puoi passare esplicitamente tutte le informazioni sulle credenziali richieste all'esperimento come segue:
{
"secrets": {
"kubernetes": {
"KUBERNETES_HOST": "http://somehost",
"KUBERNETES_API_KEY": {
"type": "env",
"key": "SOME_ENV_VAR"
}
}
}
}
{
"secrets": {
"kubernetes": {
"KUBERNETES_HOST": "http://somehost",
"KUBERNETES_USERNAME": {
"type": "env",
"key": "SOME_ENV_VAR"
},
"KUBERNETES_PASSWORD": {
"type": "env",
"key": "SOME_ENV_VAR"
}
}
}
}
{
"secrets": {
"kubernetes": {
"KUBERNETES_HOST": "http://somehost",
"KUBERNETES_CERT_FILE": {
"type": "env",
"key": "SOME_ENV_VAR"
},
"KUBERNETES_KEY_FILE": {
"type": "env",
"key": "SOME_ENV_VAR"
}
}
}
}
Su alcuni cluster Kubernetes gestiti, è necessario autenticarsi anche sulla piattaforma stessa perché l'autenticazione Kubernetes è delegata a essa.
Oltre alle tue credenziali Kubernetes (tramite il file ~/.kube/config), devi autenticarti sulla Google Cloud Platform stessa. Di solito questo avviene tramite:
$ gcloud auth login
Ma può essere ottenuto anche definendo la variabile d'ambiente GOOGLE_APPLICATION_CREDENTIALS.
Se desideri contribuire con più funzioni a questo pacchetto, sei più che benvenuto. Per favore, fai un fork di questo progetto, scrivi test unitari per coprire le modifiche proposte, implementa le modifiche, assicurati che rispettino gli standard di formattazione e poi apri una PR al repository per la revisione.
Fai riferimento alla sezione formattazione per maggiori informazioni sugli standard di formattazione.
I progetti Chaos Toolkit richiedono che tutti i contributori firmino un Developer Certificate of Origin su ogni commit che desiderano unire nel ramo master del repository. Assicurati di poter rispettare le regole del DCO prima di inviare una PR.
Se desideri sviluppare su questo progetto, assicurati di installare le dipendenze di sviluppo. Ma prima, installa PDM e poi installa le dipendenze.
$ pdm install
Ora puoi modificare i file e verranno automaticamente rilevati dal tuo ambiente, anche quando esegui il comando chaos localmente.
Per eseguire i test del progetto, esegui quanto segue:
$ pdm run tests
Usiamo ruff sia per il lint che per la formattazione del codice di questo repository.
Prima di aprire una Pull Request, ti consigliamo di eseguire la formattazione del tuo codice con:
$ pdm run format
Questo formatterà automaticamente qualsiasi codice che non rispetta gli standard di formattazione.
Poiché alcune cose non vengono rilevate dalla formattazione, ti consigliamo anche di eseguire:
$ pdm run lint
Per assicurarti che vengano rilevati anche eventuali import non utilizzati, stringhe troppo lunghe, eccetera.