There were so many exciting announcements this week that I split it up into two notes. As I didn’t write one yet this week, that works out well. This one’s focus is on announcements in the open source Kubernetes ecosystem and compared with the AWS specific announcements that happened around the same time.
On Monday, Kubernetes version 1.14 was released. The main highlights of what has become GA1 are persistent local volumes, meaning, for example, you can use instance store disks in the cloud, and support for Windows containers. While I have no personal desire to run Windows containers, I am happy to see that the support is there.
EKS Supports Kubernetes 1.12
Interestingly enough, a couple of days later AWS released support for Kubernetes 1.12 in EKS as well as a public preview for supporting Windows containers in EKS. This means that AWS is now exactly two minor versions behind with EKS. From some looking around, this seems to be in part because there wasn’t a version of 1.12 that passed the tests set up by AWS. Interestingly Google introduced 1.12 for GKE last month but had to deprecate that version due to security issues shortly after2. Please note that 1.11 is still the default in EKS, so you have to mention version 1.12 specifically.
Of course, this wasn’t the only change to EKS. Earlier this week I already gave my opinion on the recent release of private endpoints, which is good except apart from the whole “use an EC2 bastion” thing. One thing I noted in there is that the private endpoint doesn’t have CloudFormation support yet, so I’m a bit puzzled that with the introduction of Kubernetes 1.12 support they did update CloudFormation to support a version number and the ability to do upgrades3, but neglected to add support for the private endpoints in there.
One thing that impressed me was the speed with which eksctl was updated. A couple of hours after the announcement of support for 1.12 a new version of
eksctl was available that supports it. This version doesn’t use the new version flag in the CloudFormation yet, but there is already an issue open for that.
Istio also had a new release with version 1.14. Istio 1.1 is the first feature-focused release since they came out with 1.05 and the focus was on performance and scalability. As Istio could introduce a lot of overhead in large environments,6 it’s good to see they’ve made improvements here and I’m looking forward to seeing real-world data on this.
AWS App Mesh Released
One other thing that AWS released is App Mesh. This was announced at re:Invent and, like Istio7, is a service mesh which means you can use it to gain insight into and control network traffic. Also like Istio, it uses Envoy proxy under the hood, but from there it is very different. For one, it natively supports all of the AWS container services as well as EC28. I haven’t had a chance to play around with it yet even though9 it’s even available in Sydney at launch.
In case you’re not familiar with how this works in Kubernetes, features move from Alpha to Beta to GA across various releases. Once in GA they are considered stable, but you can start using them long before then. It’s just not a great idea for production workloads. ↩︎
Only for the cluster, not the nodes which you will still need to roll out new instances for yourself. ↩︎
Obvious, I know. ↩︎
And some in smaller environments too. ↩︎
Technically, Istio can do more than that. ↩︎
While Istio isn’t limited to Kubernetes, it is the main use case that people are familiar with. ↩︎
Read more like this:
- Week 23, 2018 - Amazon Neptune; ALB Built-in Authentication; Helm in CNCF
- Managing Your EKS Traffic With App Mesh
- Week 43, 2019 - CloudWatch Anomaly Detection; Some AWS Container Updates
- Week 37, 2019 - Lambda Shared ENIs; EKS IAM Roles
- Week 26, 2019 - AWS App Mesh and Cloud Map; IAM Access Advisor; Azure Bastion
Or always get the latest by subscribing through RSS, Twitter, or email!