Tìm hiểu Amazon EKS now supports Kubernetes version 1.25

Amazon EKS now supports Kubernetes version 1.25

Amazon Elastic Kubernetes Service (Amazon EKS) và Amazon EKS Distro đã hỗ trợ Kubernetes phiên bản 1.25. Phiên bản này tập trung vào tính hợp tác trong mã nguồn mở và ảnh hưởng của nó đối với Kubernetes.

Trong phiên bản này, Pod Security Policies (PSPs) đã bị loại bỏ và được thay thế bằng Pod Security Admission (PSA) controller. PSA đã được phát hành ổn định và được bật mặc định trên Amazon EKS.

Phiên bản này cũng bao gồm nhiều cải tiến về bảo mật, trong đó có Network Policy port ranges, RuntimeDefault được sử dụng làm cấu hình mặc định và loại bỏ các truy vấn với ký tự đại diện trong plugin CoreDNS. Ephemeral containers cũng đã trở thành tính năng ổn định.

Cần lưu ý rằng phiên bản này đã loại bỏ một số plugin lưu trữ và chuyển đổi sang Container Storage Interface (CSI) migration. Người dùng cần nâng cấp AWS Load Balancer Controller lên phiên bản 2.4.7 trước khi nâng cấp lên Kubernetes 1.25.

Ephemeral containers reach stable state

Ephemeral containers were first introduced in Kubernetes 1.16 as special purpose containers designed to enhance the process of debugging running pods. Ephemeral containers are deployed in the same namespace as the running pod that you intend to debug and has access to its containers’ file systems and process namespace. These type of containers are useful for troubleshooting exercises but aren’t meant to be used for normal application deployments. As such, they can’t be configured as you typically would other containers with fields like ports, readinessProbes, and livenessProbes. This feature is now generally available, allowing you to debug and run inspections on your workloads in Amazon EKS 1.25.

Network Policy port ranges are stable

In previous versions of Kubernetes, when applying port restrictions with a Network Policy, you have to specify each target port that the rules should apply to. With the graduation of endPort to stable, customers can now declare a port range which simplifies the restriction process. Without a Network Policy, all pods on a Kubernetes cluster can communicate with each other by default. This design simplifies the initial adoption and remains a default configuration. However, it’s highly encouraged to adopt a Network Policy for production workloads to secure east-to-west network connections between pods. Network Policies implement allow-based firewall rules. Amazon EKS installs Amazon VPC CNI for pod networking and is the default Container Network Interface (CNI). As of today, Amazon EKS is compatible with policy engines Calico, Cilium, and Weave, among others. You can read more about implementing Network Policies in Amazon EKS in the EKS Best Practices guide on networking.

SeccompDefault Profiles is now beta

Seccomp is a security feature in the Linux Kernel that can be used to restrict the behavior of containers on your nodes. The use of seccomp profiles has become increasingly important given the number of security risks that go hand in hand with running container workloads. In Amazon EKS 1.25, this feature is disabled by default. As such, customers that wish apply these strict security profiles on their nodes have to enable this feature and apply the –seccomp-default flag when configuring kubelet. The nodes will use the RuntimeDefault seccomp profile rather than the Unconfined (i.e., seccomp disabled) mode. In some scenarios, not all your containers require the same level of syscall restrictions, and as such you can set a custom seccomp profile for some workloads. Alternatively, you can apply taints to dedicated nodes with the RuntimeDefault seccomp profile, and deploy select workloads that require higher restriction levels with the appropriate tolerations. Customers can also use the Kubernetes Security Profile to create and propagate the seccomp profiles to enforce security on their nodes.

Cgroups v2 is stable

Control groups (Cgroups) are a Linux kernel feature that allow you to manage resources for running processes. With Cgroups, you can allocate and limit the usage of CPU, memory, network, disk I/O, etc. This particular enhancement is related to Kubernetes compatibility with Cgroups API version 2 which is now stable in 1.25. When working with Cgroups v2 in Amazon EKS 1.25, customers should review the new configuration values to see some of the changes to ranges of values for resources (i.e., cpu.weight changes from [2-262144] to [1-10000]). At present, EKS does not offer an optimized AMI that supports cgroups v2. Its availability is currently being tracked in this issue.

DaemonSet maxSurge is stable

With this feature, customers can control the maximum number of pods that can be created in place of old ones during a rolling update. To make use of this, you can add the desired value for the number of pods to the spec.strategy.rollingUpdate.maxSurge optional field. This value can also be expressed as a percentage of the existing desired pods. This feature has graduated to stable and is enabled by default in Amazon EKS 1.25.

Local ephemeral storage capacity isolation is stable

Kubernetes supports both persistent and ephemeral storage. Ephemeral storage is useful for things like caching, sharing transient data between multi-container pods, and logging. This feature, first introduced in Kubernetes 1.7, provides a way for you to isolate and limit the local ephemeral storage consumed by a pod. Similar to CPU and memory resource management, you can set limits as well as reserve ephemeral storage with resource requests. A pod’s local ephemeral storage shares its lifecycle and doesn’t extend beyond that. Through the use of hard limits, pods can be evicted in the case that they exceed their individual configured capacity. In Kubernetes 1.25, this feature is now generally available (GA).

Core CSI migration is stable

Container Storage Interface (CSI) migration was introduced to solve the complexity surrounding in-tree storage plugins that were encoded into Kubernetes. The goal was to replace these in-tree plugins with corresponding out-of-tree CSI drivers (like Amazon EBS CSI). This approach decouples the storage provider plugin from the Kubernetes source code, improving the maintenance of both Kubernetes and the storage provider plugins. The CSI Migration is now generally available (GA), enabling the use of drivers that interact with workloads on your cluster through the CSI. In Amazon EKS 1.25, Amazon EBS CSI migration is enabled by default. However, to use Amazon EBS volumes for resources like StorageClass, PersistentVolume, and PersistentVolumeClaim, then you need to install the corresponding Amazon EBS CSI driver as an Amazon EKS add-on. This particular development, however, doesn’t apply to Amazon EKS-A, which doesn’t have any in-tree CSI drivers.