Controlplane confidence code#
The architecture of the solution overview is provided in the following diagram:īased on the previous diagram, the sequence of steps required to achieve the result are the following: But as stated above, this solution can be customized to selected events of interest, if needed. In this post, the container image from the public Amazon ECR gets deployed to the Kubernetes cluster. The resultant container image is pushed to a public repository (Amazon Elastic Container Registry ( Amazon ECR) in this case). The source code and dependencies are containerized using the Docker file. All the source code is provided for the users to try and modify based on their needs (such as changing the Python-based control plane events application, type of events, and so on). We achieve this by creating a Kubernetes deployment, which the underlying pod inside that deployment tracks activities from the Amazon EKS control plane and persists the events inside CloudWatch.
Controlplane confidence how to#
As explained in the previous section, this post provides various examples to show how to manage control plane events with Amazon EKS. Once the Amazon EKS cluster is up and running, it’s time to manage the control plane events. When the cluster is ready, proceed to the next steps. Let’s start by setting a few environment variables:Įksctl create cluster -name $EKS_CLUSTER_NAME -region $AWS_REGION -managedĬreating a cluster can take up to 10 minutes. Basic Kubernetes knowledge (Pods, events, namespaces, and deployments).You need the following to complete the walkthrough: We also cover an example use case for examining events stored in CloudWatch. In this post, we provide a solution to capture the events beyond 60 minutes, using Amazon CloudWatch as the example destination. After 60 minutes, etcd purges the events during the last hour. However, EKS does not allow configuration of this setting, as events filling up the etcd database may cause stability and performance issues. Some customers have shown interest in increasing this configuration to keep a longer history for debugging purposes.
Solution overviewĪs mentioned, the Amazon EKS event TTL limit is set to the upstream default 60 minutes. We also cover how to filter Kubernetes events (such as only pod events, node events, and so on) to be exported to Amazon CloudWatch because not every type of Kubernetes resource may be required for longer duration. Readers can take this example and modify it based on their requirements. There are certain use cases where it may be useful to have a history of Kubernetes events beyond the default 60-minute window. In the world of container orchestration and especially with Kubernetes, events are specific objects that show useful information about what is happening inside a pod, namespace, or container. This default setting is a good balance of storing enough history for immediate troubleshooting without filling up the etcd database and risk causing API server degraded performance.Įvents in any distributed management system bring lot of useful information. Amazon EKS keeps the Kubernetes upstream default event time to live (TTL) to 60 minutes, which can’t be changed. As a declarative and reconciling system, Kubernetes publishes various events to keep users informed of activities in the cluster, such as spinning up and tearing down pods, deployments, namespaces, and more. Amazon EKS manages the Kubernetes control plane so customers don’t need to worry about scaling and maintaining Kubernetes components, such as etcd and application programming interface (API) servers. Amazon Elastic Kubernetes Service ( Amazon EKS) helps customers move their container-based workloads to the AWS Cloud.
0 kommentar(er)
