Local clusters enable you to run the entire EKS cluster locally on Outposts, so you can mitigate the risk of application downtime that caused by temporary network disconnects to the cloud.
Local clusters run the same Kubernetes as EKS in the cloud, and automatically deploy the latest security patches to make it easier for you to maintain an up-to-date, secure cluster.
When nodes are disconnected from the control plane for awhile Kubernetes may consider them unhealthy and schedule them for replacement when the connection is reestablished. This may lead to application downtime when connectivity is restored.
Local clusters give you the ability to host your entire EKS cluster on Outposts. In this configuration, both the Kubernetes control plane and your worker nodes run on premises on your Outposts rack.
With local clusters, the cluster’s API endpoint can only be accessed privately, i.e. from machines that are deployed in the same VPC as the cluster or over the local network via the Outposts local gateway with Direct VPC Routing.
The rest of the blog walks through how to create a local cluster on Outposts
A deep dive into Kubernetes’ vCPU limits and their impact on application performance.
When using limits, it’s a good idea to monitor container_cpu_cfs_throttled_periods_total. This metric gives you how many periods were throttled versus the total periods available container_cpu_cfs_periods_total. The cAdvisor metric called container_cpu_cfs_throttled_seconds_total gives you an idea how far over the quota the process is.
The Cloud Native Computing Foundation (CNCF) Security Technical Advisory Group (TAG) has published a whitepaper on Software Supply Chain Security Best Practices
, designed to provide the cloud native and open source communities with a holistic approach to architect a secure supply chain regardless of whether they are a software producer or consumer. This includes signing artifacts, e.g. container images, with a cryptographic key whose provenance can be verified.
This post demonstrates how to use Cosign with AWS KMS to generate a signed and verified public/private key pair. The solution uses a Kyverno ImageVerify policy to check the signature of container images and only allows containers that have been signed the KMS public key to run on the cluster.
You can use Amazon EMR on EKS to run Apache Spark workloads on EKS. This service uses the Amazon EMR runtime for Apache Spark, which increases the performance of your Spark jobs so that they run faster and cost less.
While you can use EBS storage with EMR on EKS, some users are looking for an HDFS-like shared file system to handle specific workloads like time-sensitive applications or streaming analytics
FSx for Lustre is a fully managed shared storage service built on the world’s most popular high-performance file system. It offers highly scalable, cost-effective storage, which provides sub-millisecond latencies, millions of IOPS, and throughput of hundreds of gigabytes per second.
This post demonstrates how to use EMR on EKS to submit Spark jobs with FSx for Lustre for storing and retrieving data. It can be mounted on Spark driver and executor pods through static and dynamic PersistentVolumeClaims methods.
This post illustrates how to configure and run EMR on EKS in a multi-tenant EKS cluster that can used by your various teams. In doing so, it looks at: network, resource management, cost management, and security.
This blog post shows how to set up an Amazon Elastic Kubernetes Service (Amazon EKS) cluster such that the applications hosted on the cluster can have their outbound internet access restricted to a set of hostnames provided by the Server Name Indication (SNI) in the allow list in the AWS Network Firewall
rules.
This post also shows you how to use Network Firewall to collect hostnames of the specific sites that are being accessed by your application.
Kubecost now supports integration with Amazon Managed Prometheus. In this blog, the author walks through an example that shows how to configure Kubecost to use AMP.
The scope of Kubernetes and systemd overlap in several places. This was among the main motivations behind Aurae
. The author believes that distributed systems, i.e. Kubernetes, should have more ownership of what is running on a node.
One of the goals of Aurae is to simplify systems that run on a node.
This blog discusses how DoorDash leverages an open policy agent to build policy-based guardrails with codified rules that ensure velocity and reliability for cloud infrastructure automated deployments.