Containers-roadmap: [EKS]: Support for Kubernetes 1.15

[tabern]

Tell us about your request
Support for Kubernetes 1.15 in Amazon EKS

• Upstream Release timing
• Changelog

---

Update 3/10/20 » EKS support for K8s 1.15 is now live!

[yacut]

@tabern Could you tell me please when I'm about to expect the kubernetes 1.15 on AWS?

[whereisaaron]

HI @yacut, AWS probably won't say exactly when, but they did publish a rough timetable, based on an EKS release ~6 months after the Kubernetes release.

https://aws.amazon.com/blogs/compute/updates-to-amazon-eks-version-lifecycle/

Kubernetes 1.14 was released March 25, but only released on EKS just over a month ago, on Sep 4. So that is the sort of lag we experience right now. AFAIK, that won't improve for 1.15.

Kubernetes 1.15 was released July 23, so we are expecting EKS 1.15 sometime in December.

[yacut]

@whereisaaron Thank you for your answer, it was helpful for me.

[tecnobrat]

Kubernetes 1.14 is officially EOL today. Kubernetes only supports 3 minor versions at a time and 1.17 launches today.

What's the timeline on 1.15?

[kskewes]

Keeping in mind that we are now eating into the time before 1.15 is EOL'd. Would be great to get an update from the team please.

[danielmittelman]

It's officially 2020. Can we skip the v1.15 release and just go straight to v1.16, as v1.15 is about to be deprecated?

[miguelaustro]

yes, v1.16 will come with "Pod Topology Spread Constraints", that helps with how pods are spread across AZs evenly.

[JustinPlute]

I love EKS and appreciate all the hard work by the Container Services teams, but the delayed EKS v1.15 release and the lack of communication to customers doesn't build confidence to invest in EKS as platform. GKE already supports v1.15 and via their rapid release channel: v1.16. That's two versions ahead of EKS and as mentioned above, we're now eating into the time before v1.15 is EOL'd.

@tabern, any status update would be great! This issue hasn't moved to "Coming Soon" yet, so we're all a little worried. Just an FYI: if the delay is due to a parallel release of the next version of the AWS VPC CNI plugin, most of us would be ecstatic. 🤞

Personally, I'd have preferred an EKS v1.15 announcement during re:Invent as opposed to EKS on Fargate. Anyway, thanks again and Happy New Year! 🚀

[khacminh]

@danielmittelman The recommended upgrade strategy for Kubernetes is upgrading every single minor version. Therefore, skip version 1.15 is not possible.

However, I have the same concern as @JustinPlute. It's over 3 months since version 1.14 released and this issue is not moved to Coming Soon yet.

[tabern]

@JustinPlute @danielmittelman @kskewes @tecnobrat

Thanks for your patience. Supporting 1.15 is a top priority for us, and we plan to make it GA with EKS in the first quarter this year. As we're now in 2020, I've moved this to _Coming Soon_.

Our GA for 1.15 is a bit later than we originally planned because the team made a conscious decision to adjust the rollout schedule in order to invest in simplifying, streamlining, and further automating our version qualification and release processes. This slowed down our timeline for releasing 1.15, but will allow us to ship new Kubernetes versions faster going forward. Like many of these sorts of decisions, it was not easy to make, but we think it is the right call.

@tecnobrat @kskewes you correctly point out that the community does not officially support these versions. I want to stress however that Kubernetes API versions available through EKS are officially supported by AWS until we remove the ability to create clusters using said version.

We are also discussing ways we can publish a more precise version lifecycle schedule for EKS in the future. Any input on such a schedule would be much appreciated!

[whereisaaron]

Thanks for the background @tabern. Any potential improvement to release lag is very exciting. (Only there is even ground to make up now! 😵)

Any input on such a schedule would be much appreciated!

My input would be that if the team makes the ‘conscious decision’ to change the previously published rollout schedule, tell customers too eh? 😀👍 👍 👍

[arminc]

@tabern We are now a month later since your comment... What is the status or ETA on 1.15?

[wpbeckwith]

While the 1.15 release not being available is a problem, the greater problem IMHO is the complete lack of communication. I would gather 11x9s (see what I did there) of us are techies and we understand Murphy's Law and that plans don't always work out on schedule. However, something as simple as just a note on the status would go a loooong way. Really it's ok to say we ran into unforeseen issues implementing feature X and that it will take us a couple more weeks to rewrite the fubar interface.

[bryanisgreat]

They did say it would be GA in Q1

[hendrikhalkow]

https://github.com/kubernetes/sig-release/tree/master/releases/release-1.15

When you play the game of Kubnernetes you release on time or you die two days later ... :D

[bhegazy]

@hendrikhalkow hopefully they release two days later.

Jokes asides I hope 1.15 also comes with new features (hopefully) for example managed worker nodes upgrades ( kops style rolling update) or else I’m not sure how we would upgrade the current managed worker nodes, hopefully not by creating new node groups.

[ppandiya]

Team,

As you know a lot of kubernetes vulnerabilities were fixed in 1.17 and above... We're still in 1.14.. Please share an update or a roadmap ... It will help us a lot in making decisions...

[Bessonov]

Azure's AKS puts 1.17.0 in preview some weeks ago.

[szymonpk]

@ppandiya AFAIK EKS team is back-porting security fixes.

[kskewes]

Back ports would be great but we still haven't seen 14.9 worker node ami's. Though masters updated.

[rubroboletus]

Please can you let us know, if the Q1 means year 2020? v1.18.0-alpha.3 was released week ago and we are still on 1.14 :-(

[stateisbad]

This is starting to cause headaches for my company, too. Any update would be super helpful in steering discussion and decision-making.

[Spareo]

I am not a fan of Azure but if there was ever a reason to switch over...the lack of k8s updates in EKS would be at the top of the list. This is embarrassing. We have been waiting for 1.15 to get released in EKS for over a year now. We have wasted so much time building things to work around the missing features in 1.14 that are available in 1.15.

[bryanisgreat]

k8s 1.15 was only GA 8 months ago

[mikestef9]

Wanted to provide everyone a quick update.

We still plan for GA availability of 1.15 for EKS in Q1, and this is a top priority for the team right now. We will launch as soon as we feel the release meets our high bar for security and stability. In addition to getting out 1.15, we are continuing to invest in automation that will allow us to launch versions faster as the year progresses.

[faizanbashir]

@mikestef9 I hope AWS is able to launch upcoming versions much more faster than the anticipated 1.15.

[dmegyesi]

Let me add some additional motivation why we desperately need 1.15: on our various EKS 1.14 clusters we have ran into this specific issue already multiple times and it is very unpleasant and quite a nasty surprise: https://github.com/kubernetes/kubernetes/issues/67662

It would be very nice if we had either the 1.15 available or this bugfix backported to EKS 1.14.

[MarcusNoble]

@dmegyesi I've been seeing this issues too (just this morning even). I thought it was a misconfiguration on my end, didn't realise it was actually a bug in Kubernetes.

I know AWS are committed to porting security fixes to previous versions that EKS still supports but it would be good to get some idea on if bug fixes like this are also going to be considered or not.

[llamahunter]

I have also been fighting https://github.com/kubernetes/kubernetes/issues/67662 for half a year. I saw it got fixed, finally, late last year in master, but the k8s maintainers only backported it to 1.17, 1.16, and 1.15 Version 1.14 is just too old for critical fixes.

[reubenavery]

TFW vendor-lock-in and gazing wistfully over the wall at GKE :’(

From: Richard Lee [e-mail]
Reply-To: aws/containers-roadmap [e-mail]
Date: Tuesday, February 18, 2020 at 3:16 AM
To: aws/containers-roadmap [e-mail]
Cc: "Avery, Reuben (NBCUniversal)" [e-mail], Manual [e-mail]
Subject: [EXTERNAL] Re: [aws/containers-roadmap] [EKS]: Support for Kubernetes 1.15 (#380)

I have also been fighting kubernetes/kubernetes#67662https://urldefense.com/v3/__https:/github.com/kubernetes/kubernetes/issues/67662__;!!PIZeeW5wscynRQ!9-njjtxTK4LzPk6iKWT3w7tI5sypqBhQqL9loHEO8UV8xLjFgFyTW5jAIUmYGT2eJA$ for almost a year. I saw it got fixed, finally, late last year in master, but the k8s maintainers only backported it to 1.17, 1.16, and 1.15 Version 1.14 is just too old for critical fixes.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHubhttps://urldefense.com/v3/__https:/github.com/aws/containers-roadmap/issues/380?email_source=notifications&email_token=AAAVOWZFSRD3B67TUANC66DRDOKMRA5CNFSM4HZGA5YKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEMBAIGA*issuecomment-587334680__;Iw!!PIZeeW5wscynRQ!9-njjtxTK4LzPk6iKWT3w7tI5sypqBhQqL9loHEO8UV8xLjFgFyTW5jAIUlRt2r40A$, or unsubscribehttps://urldefense.com/v3/__https:/github.com/notifications/unsubscribe-auth/AAAVOW6XEZKG6UX4GVP7NADRDOKMRANCNFSM4HZGA5YA__;!!PIZeeW5wscynRQ!9-njjtxTK4LzPk6iKWT3w7tI5sypqBhQqL9loHEO8UV8xLjFgFyTW5jAIUl4IVtaGg$.

[stateisbad]

Pretty sure at this point 1.15 and 1.16 need to be released simultaneously in order to catch up at all.

[walkafwalka]

Please stop adding comments that are not furthering the discussion.

https://github.com/aws/containers-roadmap/issues/380#issuecomment-586539092 has already stated that 1.15 is a top priority for Q1 and they are working on improving the speed in which they support new version.

If you just want to +1, there is already a built-in feature that does not notify a bunch of other users.

[danielmittelman]

v1.18 is now in beta

[AceHack]

Many open-source projects like Knative now only support K8s 1.15 or above in their latest release, this is blocking from upgrading other open-source projects that have critical bug fixes.

[marcomsousa]

Make no sense that EKS support 1.15. now is too late. You can you give up, and focus now on #487 and #697 please.

[stateisbad]

kops released 1.16 within the last day or so.

[rparsonsbb]

Make no sense that EKS support 1.15. now is too late. You can you give up, and focus now on #487 and #697 please.

@marcomsousa

That's not how kubernetes works, have to upgrade through 1.15 to get to the next release.

https://kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/#additional-information

[bryanisgreat]

Please stop adding comments that are not furthering the discussion.

#380 (comment) has already stated that 1.15 is a top priority for Q1 and they are working on improving the speed in which they support new version.

If you just want to +1, there is already a built-in feature that does not notify a bunch of other users.

We are still in Q1 which is the latest delivery window they gave for this Issue.
As pointed out there are many other options to EKS that are on newer k8s, use one of those options if it is important to your business case.

[dcherman]

Not to add more noise here, but I did notice that the first AMIs that would be used for EKS 1.15 were published on 2/29, so hopefully that means the release is relatively close.

[robwittman]

Please stop adding comments that are not furthering the discussion.
#380 (comment) has already stated that 1.15 is a top priority for Q1 and they are working on improving the speed in which they support new version.
If you just want to +1, there is already a built-in feature that does not notify a bunch of other users.

We are still in Q1 which is the latest delivery window they gave for this Issue.
As pointed out there are many other options to EKS that are on newer k8s, use one of those options if it is important to your business case.

Sure there are other options, but some businesses are highly integrated with the AWS environment, using other services in their ecosystem, a notable one being IAM. It feels like a slap in the face to be told to suck rope because they're behind releasing a version that's already EOL by upstream (acknowledging that AWS does provide support for EOL versions themselves)

At my day job, we've been using EKS since 1.11, so simply migrating to another service / cloud provider isn't a super easy decision to make in this regard. We've started using some EKS-specific features we really don't want to rebuild ourselves unless absolutely necessary (not to mention redoing all of our terraform modules that are built around EKS)

As others mentioned earlier in this issue, I personally don't think its so much an issue with the release cycle, as it is with the lack of communication. We understand things sometimes don't meet a deadline. Plenty of users made a calculated decision to use AWS as their service provider for Kubernetes, and having a release not only come later than expected, but have very little communication about when we can expect it (we're only a couple weeks from end of Q1), generates a little bit of discomfort. A lot of us answer to stakeholders, and when we can't respond with anything more than "🤷‍♂guess we have to redo everything" , it sucks.

Is there any estimates to when 1.15 will be in developer preview, let alone GA? I can only speak for myself, but we are starting to consider other options due to the uncertainty. You guys do a great job, and we love the ease (or lack thereof) of real maintenance on our end, but don't know if we can sacrifice the agility for it.

[prestonvanloon]

AWS is one of the few providers that charges an hourly rate for their
kubernetes master node and is so far behind the others that it makes almost
no sense to use EKS.

Here are some other options:

Digitial ocean is on 1.16.x.
https://www.digitalocean.com/docs/kubernetes/changelog/
GKE is on 1.15 with 1.16 soon to reach the stable channel
https://cloud.google.com/kubernetes-engine/docs/release-notes
Azure is on 1.15. I assume 1.16 is just around the corner.
https://github.com/Azure/AKS/blob/master/CHANGELOG.md

All of the above options are free for the master node while AWS is the
farthest behind while charging 0.10 per hour for master nodes.

Given the knowledge above and the complete lack of communication from AWS,
I recommend staying away from AWS for your kubernetes provider.
Personally, if there is no update from AWS by the end of Q1 with finite
plans for upgrading EKS then I will be planning to move away from AWS.

On Fri, Mar 6, 2020 at 12:49 PM Robert Wittman [e-mail]
wrote:

Please stop adding comments that are not furthering the discussion.

380 (comment)

https://github.com/aws/containers-roadmap/issues/380#issuecomment-586539092
has already stated that 1.15 is a top priority for Q1 and they are working
on improving the speed in which they support new version.
If you just want to +1, there is already a built-in feature that does not
notify a bunch of other users.

We are still in Q1 which is the latest delivery window they gave for this
Issue.
As pointed out there are many other options to EKS that are on newer k8s,
use one of those options if it is important to your business case.

Sure there are other options, but some businesses are highly integrated
with the AWS environment, using other services in their ecosystem, a
notable one being IAM. It feels like a slap in the face to be told to suck
rope because they're behind releasing a version that's already EOL by
upstream (acknowledging that AWS does provide support for EOL versions
themselves)

At my day job, we've been using EKS since 1.11, so simply migrating to
another service / cloud provider isn't a super easy decision to make in
this regard. We've started using some EKS-specific features we really don't
want to rebuild ourselves unless absolutely necessary

As others mentioned earlier in this issue, I personally don't think its so
much an issue with the release cycle, as it is with the lack of
communication. We understand things sometimes don't meet a deadline. Plenty
of users made a calculated decision to use AWS as their service provider
for Kubernetes, and having a release not only come later than expected, but
have very little communication about when we can expect it (we're only a
couple weeks from end of Q1), generates a little bit of discomfort. A lot
of us answer to stakeholders, and when we can't respond with anything more
than "🤷‍♂guess we have to redo everything" , it sucks.

Is there any estimates to when 1.15 will be in developer preview, let
alone GA? I can only speak for myself, but we are starting to consider
other options due to the uncertainty. You guys do a great job, and we love
the ease (or lack thereof) of real maintenance on our end, but don't know
if we can sacrifice the agility for it.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/aws/containers-roadmap/issues/380?email_source=notifications&email_token=ABXJHYUXO6V6TRSXZZFBRITRGFOW5A5CNFSM4HZGA5YKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEOCZ4SQ#issuecomment-595959370,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABXJHYRPZENEGMDHNETJYTDRGFOW5ANCNFSM4HZGA5YA
.

[MiniJerome]

AWS is one of the few providers that charges an hourly rate for their kubernetes master node and is so far behind the others that it makes almost no sense to use EKS. Here are some other options: Digitial ocean is on 1.16.x. https://www.digitalocean.com/docs/kubernetes/changelog/ GKE is on 1.15 with 1.16 soon to reach the stable channel https://cloud.google.com/kubernetes-engine/docs/release-notes Azure is on 1.15. I assume 1.16 is just around the corner. https://github.com/Azure/AKS/blob/master/CHANGELOG.md All of the above options are free for the master node while AWS is the farthest behind while charging 0.10 per hour for master nodes.

I want to first apologize for everyone that _again_ will receive a useless comment on this issue.

@prestonvanloon

Note: Starting June 6, 2020, GKE clusters will accrue a management fee of $0.10 per cluster per hour, irrespective of cluster size or topology. One zonal cluster per billing account is free. GKE cluster management fees do not apply to Anthos GKE clusters.

https://cloud.google.com/kubernetes-engine/pricing

[prestonvanloon]

My comment was still accurate at the time of writing and there are still
many other options that support kubernetes releases in a timely manner
without charging 0.10 per hour.

Thanks

>

[antoniobeyah]

Make no sense that EKS support 1.15. now is too late. You can you give up, and focus now on #487 and #697 please.

@marcomsousa

That's not how kubernetes works, have to upgrade through 1.15 to get to the next release.

https://kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/#additional-information

I just want to say here that not all k8s admins upgrade k8s this way- there are new environments that get spun up with ideally the latest available and existing environments can migrate workloads to new clusters vs upgrading in place. I'm just calling this out because at my company we are in the camp of migrating workloads to the new cluster (with the new version) vs upgrade in-place. We may be a minority in that regard but but it is something I hope the EKS team recognizes.

I am looking at the 1.15 ticket here because we are still on 1.13 (we haven't had a reason to go to 1.14) and want to do an upgrade primarily for the knative support and most recently for the OPA gatekeeper support. We have an option of upgrading to 1.14 if we need to (for gatekeeper) but would prefer to just upgrade when 1.15 (or later) is released. We will skip 1.14 entirely assuming the new(er) versions get released in a timely manner.

[klozipet]

There are 47 tasks to do. Is the promissed Q1 (end of March 2020) realistic still?

[rubroboletus]

There are 47 tasks to do. Is the promissed Q1 (end of March 2020) realistic still?

have you seen in this thread anything about 2020? Just about Q1. Even 2021 will have Q1, same 2022 ...

[crosen188]

There are options available...https://twitter.com/ChrisRosen188/status/1226892267157442561

[QuinnyPig]

Excuse me, @crosen188--you work for IBM. You're supposed to do crappy enterprise billboard advertising, not crappy startup astroturfing in GitHub issue advertising.

[crosen188]

Excuse me, @crosen188--you work for IBM. You're supposed to do crappy enterprise billboard advertising, not crappy startup astroturfing in GitHub issue advertising.

Well I hear when users are struggling and I know we can provide a better solution so however you would like to label that 'advertising' is fine with me.

[marcomsousa]

IBM spam here? We know are thousands others ways and tools, but we are here for managed Amazon kubernetes.. Please stop spamming

[rahuldivgan]

Well looks like the 1.15 is out 🎉but not yet default though!

[garyd203]

Well I hear when users are struggling and I know we can provide a better solution so however you would like to label that 'advertising' is fine with me.

@crosen188 we get that you are passionate about your project, but please consider the context - this is not a chat room, this is a place to discuss a specific concrete feature request for this specific project.

[mikestef9]

Amazon Elastic Kubernetes Service (EKS) now supports Kubernetes version 1.15.10 for all clusters.

For more information, see the 1.15 release notes and highlights in the EKS documentation.

Learn more about the Kubernetes versions available for production workloads on Amazon EKS and how to update your cluster to version 1.15 in the EKS documentation.

What's New post

Additional Notes:

• We have moved EKS support for K8s version 1.16 to in progress, as work has already started and this is a high priority for the EKS team.
• eksctl support for K8s 1.15 is coming soon and we will close this issue when that is complete. eksctl support for K8s 1.15 https://github.com/weaveworks/eksctl/releases/tag/0.15.0
• Kubernetes version 1.12 is now deprecated, and will no longer be supported on May 11th, 2020. This is being tracked in #786

[bigwheel]

Announcing Bottlerocket, a new open source Linux-based operating system purpose-built to run containers

Did AWS postpone kubernetes 1.15 support for this ?
Thanks for commercialism ! :unamused:

[tabern]

@bigwheel I can definitively say NO, we did not postpone the v1.15 launch to align with Bottlerocket. We know how critical this version is for our customers. Delaying the launch for this reason would not customer obsessed and would be completely against our principals as a team and as a company.

We're super excited to be able to launch v1.15 today and work on v1.16 is underway! You can track that here: https://github.com/aws/containers-roadmap/issues/487

[dutoitns]

Well done AWS team!!! Busy with a few other things, but will give v1.15 a try soon

👍 👍 👍

[danielmittelman]

I should be happy v1.15 is out, but I'm not. The lack of transparency and communication on releasing this (soon-to-be-deprecated) version has been disappointing and pretty much uncharacteristic of AWS.

I hope that the EKS teams at AWS take this as an opportunity to review their release cycle and transparency policies and try to improve towards v1.16

[tabern]

@danielmittelman appreciate this feedback. We understand how critical a regular and predictable version cadence is for you and all of our customers. This is not a point lost on the team or our leadership.

[dano0b]

Any idea when worker node ami version "1.15.10-20200228" will be available(in singapore)? Found it in https://docs.aws.amazon.com/eks/latest/userguide/eks-ug.pdf but the version is not accepted and we have to use "1.14.8-20191213".

[dogzzdogzz]

@dano0b
already available in sg
ami-0628219ac9549add7

[dano0b]

I saw that the AMI exists but it is not available:
Requested Nodegroup release version 1.15.10-20200228 is invalid. Allowed release version is 1.14.8-20191213
I think something is missing, hard to check. See: https://github.com/aws/containers-roadmap/issues/771

[tabern]

@dano0b check out the AMI SSM parameter instructions in the EKS documentation.

All EKS AMI Ids are now dynamically served via SSM parameters.

you can run $ aws ssm get-parameter --name /aws/service/eks/optimized-ami/1.15/amazon-linux-2/recommended/image_id --region ap-southeast-1 --query "Parameter.Value" --output text

Output:
ami-08805da128ddc2ee1

[dano0b]

Sure, the ami is there but managed worker nodes do not accept as release version "1.15.10-20200228" for now, at least 12h ago it didn't.

[galb-see]

Just upgraded self-managed nodes (using these instructions ), and noticed that 1.14 is being used by the cloudformation template (an error?).
Tried just changing to 1.15, and the upgrade went fine on our development clusters.

Maybe there's a similar issue with the managed workers.

NodeImageIdSSMParam:
Type: "AWS::SSM::Parameter::Value<AWS::EC2::Image::Id>"
Default: /aws/service/eks/optimized-ami/1.14/amazon-linux-2/recommended/image_id
Description: AWS Systems Manager Parameter Store parameter of the AMI ID for the worker node instances.

[tabern]

@dano0b MNG actually does not accept any release version - there is a field in the CloudFormation template but that is solely there to trigger the update to the latest MNG version.

Did you update your cluster to v1.15 before attempting the MNG update?

[gregwhorley]

Can someone confirm whether this fix made it into the current EKS 1.15 offering? We really need this bug fix because our EKS node security group's rule count has almost reached the AWS limit and we have already requested two limit increases :sweat:

[dano0b]

@dano0b MNG actually does not accept any release version - there is a field in the CFN template but that is solely there to trigger the update to the latest MNG version.

Did you update your cluster to v1.15 before attempting the MNG update?

No idea what CFN is. I'm using Terraform and the resource for the managed worker nodes have an argument for release: https://www.terraform.io/docs/providers/aws/r/eks_node_group.html
The limitation is not with Terraform but with the API: https://github.com/aws/containers-roadmap/issues/771
Of course tried updating after the control panel upgrade.

[dano0b]

All good, this morning 1.15 releaseVersion is available.

[bhegazy]

Just tested the upgrade from 1.14 to 1.15 with managed node using terraform, which works successfully

I changed the following for MNG resource aws_eks_node_group

resource "aws_eks_node_group" "example" {
  ...
  ...
  version   = "1.15"
  release_version = "1.15.10-20200228"
}

[cshivashankar]

I am planning to upgrade to 1.15 , Couple of changes related to kubelet which is noticeable is
--cloud-provider aws (used in EKS optimized AMI) and --allow-privileged flags removal. In the upgrade process of upgrading worker nodes after upgrading the control plane, do I have to follow any special steps if I am already using the above 2 flags?
Did anyone face issues with cadvisor without --allow-privileged flag for kubelet ?

[khacminh]

After upgrade my cluster to EKS v1.15, the fargate pods are stuck at pending. I tried to delete the pending pod and that doesn't help. Does any one meet the same problem?

---

What make me believe this is a bug?

• I check the scheduler log on cloud watch and there is no fargate pod information is logged. I saw that there is no fargate node joins the cluster also.
• I get my fargate pod manifest and see that:
  
  
  
  • a new label was added by EKS: eks.amazonaws.com/fargate-profile=my-fargate-profile
  
  
  • the scheduler is: schedulerName: fargate-scheduler
  
  
• My Pod execution role is shared with another cluster (running EKS 1.14) and there is no problem with fargate on that cluster.

[nauxliu]

@khacminh Have you followed AWS' upgrading guide: https://docs.aws.amazon.com/eks/latest/userguide/update-cluster.html

[khacminh]

@nauxliu

Before I upgraded my EKS master, both master and worker nodes versions are 1.14. All of the versions of CNI plug-in, CoreDNS, and KubeProxy are up to date. The problem occurs after my EKS master upgraded to v1.15

[dwyart]

Can someone confirm whether this fix made it into the current EKS 1.15 offering? We really need this bug fix because our EKS node security group's rule count has almost reached the AWS limit and we have already requested two limit increases sweat

This fix is part of Kubernetes 1.15.11, so I do not think it is deployed on EKS 1.15.

[jsenon]

We have just updated our EKS cluster to 1.15 and server version is 1.15.11:

Server Version: version.Info{Major:"1", Minor:"15+", GitVersion:"v1.15.11-eks-af3caf", GitCommit:"af3caf6136cd355f467083651cc1010a499f59b1", GitTreeState:"clean", BuildDate:"2020-03-27T21:51:36Z", GoVersion:"go1.12.17", Compiler:"gc", Platform:"linux/amd64"}

[inductor]

Why not just lock this issue????