On some Kubernetes versions, there is a problem that pods stuck in Terminating state on some circumstances. This tool connects to the kube-apiserver, discovers Terminating pods which are in Terminating status more than --terminatingStateMinutes minutes, which is defaults to 30 minutes.
This tool also discovers pods which are at Evicted state if --terminateEvicted passed(enabled by default)
Please note that kube-pod-terminator can work in Kubernetes cluster as Deployment, or outside of Kubernetes cluster as binary. Please refer to Installation section for more information.
Kube-pod-terminator can be customized with several command line arguments. You can pass arguments via sample deployment file or directly to the binary. Here is the list of arguments you can pass:
--inCluster bool Specify if kube-pod-terminator is running in cluster. Defaults to true
--kubeConfigPaths string Comma seperated list of kubeconfig files path to access clusters. Required while running out of Kubernetes cluster.
--namespace string Namespace to run on. Defaults to "default" namespace.
--terminatingStateMinutes int32 Terminate stucked pods in terminating state which are more than that value. Defaults to 30.
--channelCapacity int Channel capacity for concurrency. Defaults to 10.
--gracePeriodSeconds int64 Grace period to delete pods. Defaults to 30.
--terminateEvicted bool Terminate evicted pods in specified namespaces. Defaults to true.
--contextTimeoutSeconds int32 When to timeout request context while talking to apiserver. Defaults to 1.
kube-pod-terminator can terminate the pods of multiple clusters if multiple kubeconfig file path is provided to --kubeConfigPath flag.
If you run the kube-pod-terminator inside a Kubernetes cluster, it manages the terminating pods of that current cluster by default. But keep in mind that if you want to manage terminating pods on multiple clusters and run kube-pod-terminator inside a Kubernetes cluster, you should mount multiple kubeconfig files as configmap or secret into pod and pass below arguments in your Deployment config:
--inCluster=false
--kubeConfigPath=/tmp/kubeconfig1,/tmp/kubeconfig2,/tmp/kubeconfig3
You can check deployment/sample_external_clusters.yaml as example.
But before creating deployment file, you should create configmaps from your desired kubeconfigs like below:
$ kubectl create configmap cluster1-config --from-file=${YOUR_CLUSTER1_CONFIG_PATH}
$ kubectl create configmap cluster2-config --from-file=${YOUR_CLUSTER2_CONFIG_PATH}
$ kubectl create configmap cluster3-config --from-file=${YOUR_CLUSTER3_CONFIG_PATH}Kube-pod-terminator can be deployed as Kubernetes deployment or standalone installation
You can use sample deployment file to deploy your Kubernetes cluster. This file also creates required Role and RoleBindings to take actions on problematic pods.
$ kubectl create -f deployment/sample.yamlBinary can be downloaded from Releases page. You can use that method to run kube-pod-terminator outside of a Kubernetes cluster.
After then, you can simply run binary by providing required command line arguments:
$ ./kube-pod-terminator --inCluster false --kubeConfigPath ~/.kube/configCritical command line arguments while running kube-pod-terminator as standalone application are --inCluster, --kubeConfigPaths
This project requires below tools while developing:
- Golang 1.17
- pre-commit
- golangci-lint - required by pre-commit
Apache License 2.0
kube-pod-terminator uses client-go to interact
with kube-apiserver. client-go uses the service account token
mounted inside the Pod at the /var/run/secrets/kubernetes.io/serviceaccount path while initializing the client.
If you have RBAC enabled on your cluster, when you applied the sample deployment file deployment/sample.yaml, it will create required serviceaccount, role and rolebinding and then use that serviceaccount to be used by our kube-pod-terminator pods.
If RBAC is not enabled on your cluster, please follow that documentation to enable it.