At the end of the first day of re:Invent 2020, I had a look at the AWS service update feed, and there’s already a long list of 48 new service announcements since the start of the event. Some more interesting than the others, obviously. I have made an attempt to understand what’s going on in the EKS world, and not surprisingly, there are a few interesting updates including the ones below.
Amazon EKS Console Now Includes Kubernetes Resources to Simplify Cluster Management
Until now, the only native way of seeing the Kubernetes API resources and applications running in an EKS cluster was through the CLI (kubectl/eksctl). As this was not ideal, users had to resort to 3rd party tools such as kubernetic to visualise the contents of a cluster. But these had various downsides ranging from licencing costs to security and performance.
With this update to the EKS Console, it now shows the nodes and workloads such as deployments, daemonsets, and jobs.
This enables users to visualise how an application is deployed on the cluster and its status, and most importantly the ability to link back to the underlying AWS Cloud resource (i.e., EC2 instance). This brings the AWS EKS Console ever so close to becoming a single pane of glass for the cluster management.
Amazon EKS simplifies installation and management for Kubernetes cluster add-ons
Creating an EKS cluster has always been quite simple. But getting it to a state where it can support a production workload was not so much. This gap was mainly around the number of add-ons you’d have to deploy to support observability, scaling, networking, and security. Things got even trickier when you had to upgrade the cluster, as you would have to upgrade the add-ons to compatible versions as well.
This update is enabling users to install, manage, and update common operational software (add-ons) through the EKS console, CLI, and API. As these add-ons are validated by AWS and can be deployed and updated any time, it simplifies the cluster creation and also the upgrade process.
However, it is worth noting that only the Amazon VPC CNI networking plugin is available via EKS add-ons at this point in time, with the promise of more add-ons coming soon.
Amazon EKS adds built-in logging support for AWS Fargate
Single biggest overhead of running a pod on AWS Fargate was the extra orchestration needed to get the container logs forwarded somewhere (i.e., CloudWatch, Elasticsearch or Kinesis). Often the users had to install and maintain a sidecar container to achieve this.
Amazon EKS on Fargate now includes a built-in log-router (which is a version of Fluent Bit managed by AWS), and users can define the log destination by using a ConfigMap.
AWS has taken the lifecycle management of Fluent Bit off users’ hands, by including it in the platform. This will massively simplify the whole log-routing setup for pods running on Fargate, and also the usage of ConfigMaps means the users will get a consistent interface to configure logging, irrespective of the underlying compute type (EC2 or AWS Fargate)
Honourable mentions and conclusion
In addition to the above there were two more EKS related announcements
- EC2 Spot Instances in managed node groups
- Introduction of Amazon EKS Distro - the open-source Kubernetes distribution used by Amazon EKS
With all these and the announcement in Andy Jassy’s keynote about EKS Anywhere, AWS has shown its continued commitment for Kubernetes, and has put forward a compelling case for EKS. But as with any technology Kubernetes will not be suitable for every workload, but if it is, then there is no reason to shy away from moving to EKS, now more than ever.