Kubernetes Containerd Integration Goes GA | Hacker News Reader

Kubernetes Containerd Integration Goes GA

kubernetes.io

189 pointsel_duderino57 comments

For the few that are not familiar with the acronym GA, that means General Availability.

Typically this means the removal of a "beta" tag, and a general expectation of a service that is supposed to be available for most of the time, and not have significant security issues or bugs.

In some cases a GA release is accompanied by an SLA (Service Level Agreement), e.g. uptime of 99.9% measured monthly.

I know, it sounds obvious. You might be tempted to downvote me :)

And yet, when I was a tech evangelist and later a CTO, I realized the importance of being as clear as possible when explaining things (including titles). You would be surprised at how many people got lost with even the most basic acronym.

Modern GA literally means generally available, as in:

> that service seems to be down!

> huh, its generally available...

In Kubernetes terms (and the context of this feature), GA means stability (rather than SLA). When a Kubernetes feature is in alpha/beta, it may go through breaking changes between releases. For this feature, it means it is no longer considered an experiment and is recommended for production use.

For Kubernetes API, alpha/beta process and the deprecation policy is documented here: https://kubernetes.io/docs/reference/using-api/deprecation-p...

How about something for the few that are not familiar with 'containerd' ?

My understanding is that it replaces docker for running the containers.

I asked myself the same question a little while back, and landed here:

https://blog.docker.com/2017/08/what-is-containerd-runtime/

Although I ended up coming out of it with more acronyms in hand, and perhaps only slightly less confusion than when I went into it.

Thanks! Although I have seen GA before (including the words General Availability) on the MySQL download page, I now only thought of Google Analytics, and then Google Apps (more related to the topic).

I'm familiar with K8 and docker, but not with Containerd. does this means that now K8 supports containers that are not created with docker but rather with Containerd ? is that correcet? if so, what's the benefit? i miss some background here.

Docker daemon is running on top of containerd, so it was an additional layer which could be avoided and that's exactly what was done. The benefit is less latency and resource consumption.

so, do I've to create the container in a diffrent fashion or will be k8s doing all the stripping?

Creating the container or the image? All existing images continue to work and tools like docker build will continue to be used to build containers.

This replaces `docker run`.

Do you mean K8s as an abbreviation for Kubernetes, or am I again out of the loop with some new tech in this fast moving field?

Indeed, K8s is a numeronym[0] for K(ubernete)s.

[0] Compare i18n, g11n, and i10n https://en.wikipedia.org/wiki/Numeronym

Yes, but the GP uses K8, not K8s.

yes, my bad

This is great. Anyone know what Google's plans are when it comes to rolling this out on GKE?

> Containerd 1.1 works with Kubernetes 1.10 and above

Kubernetes 1.10 just came out on GKE, so I assume it should work today!

https://cloudplatform.googleblog.com/2018/05/Google-Kubernet...

(Note: I haven't personally tried this out. I also work for GCP)

I don't see it mentioned in the GKE release notes, so I assume there's no option to enable it yet.

The fact that A is tested to work with B doesn't necessarily mean that a packaged service will provide both A and B, though.

Disclaimer: I work in Google, wrote the blog post.

We are working on rolling out containerd 1.1 to GKE alpha cluster. If everything goes as expected, it will be available in GKE alpha cluster soon.

AWS ECS was GA in 2015. With load balancing, autoscaling, health and update management. Just saying :)

Hmm ... Does Google has its own troll factory? Whenever I say something against it, downvotes come, always without replies.

It's because your comment belies your understanding of the article and the nature of the announcement. It makes no sense to compare AWS ECS in it's entirety to the rollout of containerd. The correct comparison in your case would be with Kubernetes Engine against ECS.

This looks to be the beginning of the "extinguish" step from Google. They've executed the embrace, extend, extinguish playbook to a T with Docker.

The top contributors to containerd are all from Docker.

Google is just one of many organizations involved in Kubernetes. If this has anything to do with embrace, extend, extinguish, it's to prevent Docker as a company from attempting to do anything like that to Kubernetes.

Edit: I take that last part back. This seems to ensure that neither party can easily fuck each other over, and that's a good thing.

To be fair, Kubernetes was a big competitor to Docker Swarm and Docker’s own Cloud, which kind of lost the battle. One has to wonder what would have happened if Google did not build Kubernetes, which heavily embraced Docker.

Sometimes it’s not all that black and white, Google seems to mainly be afraid of one competitor becoming too powerful and losing control. Android vs iPhone being another example.

Google’s competitor here is AWS. AWS’ comparable product is ECS.

ECS also lost. Roll on EKS.

You missed the point.

It should have been the battle of Docker to take on incubate VM-based compute providers.

Apparently I also miss your point, because I cannot parse it.

Did you mean “incumbent”?

And the biggest reason ECS lost imo because of the poor load balancing and service discovery options. They just now released Route 53 service discovery via DNS but it might be too little too late.

I believe those are just symptoms of the underlying issue; AWS's closed off and slow roll development practices simply could not keep up. They tried to rectify the situation with Blox; I'm honestly not sure how that is going.

When you ask about attaching EFS or EBS to services in fargate and they ask what your use case for that is... In the words of Drake; "...we gonna see."

Yeah, no EFS in Fargate is a deal-breaker; we manage our own nodes in ECS right now, just because we want EFS support. It was kind of too-little-too-late, same thing with Route53 DNS-based service discovery—it's annoying when you feel nickel-and-dimed into adding an (relatively expensive, IMHO) ELB/ALB per service to be able to direct requests to the backend.

I'm hoping EKS will evolve a lot more quickly and stay up to date with the upstream; it would be awesome if AWS has full and stable support for all the major bits like persistent volumes (on EFS or EBS), LoadBalancers (ELBs/ALBs, hopefully more configurable someday), etc.

It sounds like the beta period is over and AWS is ramping up for EKS' GA soon.

Huh? Why would you want one of these to win?

I did not intend to state a wish that any of Google, ECS, AWS or EKS would “win”.

I do believe EKS is a good choice for many people. As is GKS, and many similar offerings.

BTW I work for a company selling Kubernetes tools and support.

Hmm, Did you forget that most of Kubernetes clusters are actually deployed in AWS?

Google probably got the best "managed" solution with GKE, (a close call with Azure IMO) but most people still use AWS and way more deployment happen in AWS

Close call? Seriously? GKE is a GA, production, supported platform, Azure is still far behind at the moment, in Preview with no declared planned GA date on the roadmap.

https://azure.microsoft.com/en-us/roadmap/?query=container+s...

I realize that Azure isn't as popular in the US startup crowd (and certainly not on HN), but you really cannot mention EKS without also mentioning AKS which is much more mature IMHO. And ACI (Azure Container Instances) is a serverless container offering that was launched before Fargate.

Beyond the Azure offering, Microsoft has also shown tremendous commitment to the Kubernetes ecosystem at large. Take a look at the many Kubernetes open source tools created by Microsoft that work with Kubernetes anywhere (!!!):

  [1] Helm (initially created by Deis, acquired by Microsoft) 
  [2] Virtual Kubelet
  [3] Draft
  [4] Brigade
  [5] VSCode: Kubernetes Tools

And more...

  [1]: helm.sh
  [2]: https://github.com/virtual-kubelet/virtual-kubelet
  [3]: https://github.com/azure/draft
  [4]: https://github.com/azure/brigade
  [5]: https://github.com/Azure/vscode-kubernetes-tools

Disclaimer: I'm a developer advocate for Kubernetes / Linux at Azure (but a member of the community first and foremost). I've never run a Windows Container, and I don't have a single Windows VM in Azure ;)

I encourage you to take a close look at the Azure offering. It's actually very awesome!

>without also mentioning AKS which is much more mature IMHO.

AKS is anything but mature.It's barely working. Last month I was at Microsoft event and everyone was suppose to launch an environment. By the fifth or six environment, provisioning died and no one could provision an environment. And I mean it died globally, regardless of the region you tried to run it at. Provision time is awful even when no one is "stress testing" the provisioning engine.

This is all good and acceptable, relatively, when the service state is labeled as preview, which is how it is labeled officially. Mature isn't a word to use in regards to AKS currently.

The hype Microsoft advocates try to build around AKS gives the impression a highly puffed CV of a junior dev, and IMHO it is unfortunate and a wrong way to build trust. It is fine that Azure haven't yet developed state of the art kubernetes cloud service, no one except Google have, just don't claim you did if you want us to believe you when it labeled GA that we can use it for real workloads.

You are correct. The provisioning sucked. I will be fully transparent about that. In fact, I had the same problems myself. You can see the list of issues here [1]. That provisioning madness is actually unrelated to AKS, but it's being addressed by the team. This is one of the reasons why the service isn't GA yet.

I'd say give it a try in the EastUS region, or some time after GA. Once you do have an AKS cluster up it all works well.

[1]: https://github.com/Azure/AKS/issues

I’m sure it is immensely irritating to Google that they aren’t even second to AWS, but I’m pretty sure it was not Microsoft they were aiming at with Kubernetes.

To me, it’s a re-run of the X Window System playbook, where Digital managed to break Sun and Apollo’s lock on workstation tools. Digital didn’t particularly win that one either.

> ECS also lost

Hmm ... Could you back this up ?

Evidence: EKS.

Even if there was no Kubernetes, both Mesos and Nomad seem better than Docker Swarm depending on your use case. I don't know if Docker really would have been very successful even if Kubernetes didn't exist.

Docker Swarm was announced ~6 mos. after Kubernetes was announced. Similarly, Kubernetes 1.0 release was 6 mos. before Swarm's 1.0 release.

Personally, Docker's big mistake was killing off dotCloud so quickly instead of gradually migrating it to Docker.

I have no stake in this, and am in no position to make any judgement at all, but I'm still hesitant to conclude that K8s has "won" or something. There was a story here two weeks ago about the absurd complexity of it. All I know is that it's heavily promoted left and right, and like for most tech products this decade, big media has won the attention grab, and has been successful in creating the perception that k8s is the orchestration software most people are using or look forward to using. Not saying it isn't, but I've yet to see any figures supporting that statement.

What Google is up to here is pretty clear IMHO: they want to be perceived as the go-to provider for k8s based clouds. It's not like the iPhone-vs-Android situation at all where Google's goal is to maintain influence over advertising channels rather than push Android sales per se.

What google wants to do is to make their complement cheap.

ie, they want to make Kubernetes an open-source de-facto solution so that people can spend more money on cloud providers.

I have a very limited experience with kubernetes, and to me it is indeed very complex (as a user). I can only imagine how complicated it would be to offer a kubernetes solution as a cloud provider. So all of the complexity works in favor of google, but as long as users actually use it, it's a fair game.

If Google wants to be the go-to provider of clouds their open source Kubernetes strategy is pretty backwards. As it stands, though, they've got their competitors reselling their orchestration platform technology giving them platform control moreso than a selling point for their cloud.

> I'm still hesitant to conclude that K8s has "won" or something

Take a look at Azures container offerings (kubernetes itself or kubernetes compatible), along with the AWS equivalents. All three major cloud platforms have managed kubernetes solutions now. That doesn't mean competing orchestrators are dead, but they're hiding in their bunkers hoping that the worst is over...

> There was a story here two weeks ago about the absurd complexity of it.

Yeah it's absurdly complex, except when compared to the absurd rats-nest of almost-there not-quite-compatible technologies it has replaced ;)

There are lighter weight solutions for lighter weight problems, but map the DevOps cycle from A to Z and Kubernetes is head-and-shoulders simpler than competing solutions. Simpler, more comprehensive, standardized, and better documented. Add in cross-cloud portability and you've got something hard to compete with.

> ... absurd complexity of it

Nuff said

It's really not that bad. Set up a Kubernetes cluster manually, then go set up a Nomad/Consul cluster manually, and you'll see that while just Nomad and Consul is much simpler, you haven't really gotten where you need to be unless you plan on having each of your clients to make separate DNS SRV requests beforehand AND have client-side load balancing. If you want that to be handled transparently for you, you're going to need some kind of virtualized networking or service mesh. You get this out of the box with Kubernetes, and in practice you don't need to set up these clusters manually. That's only valuable to help you understand each of the components better.

tl;dr both fully managed (GKE, EKS) or semi-automated (kops) Kubernetes deployments are less operationally expensive than the "simpler" alternatives. If you think Docker in general isn't worth it relative to just VMs...than you may be right for your use case. But I and many others will tell you that they've migrated from VM based environments to Kubernetes and it's done a lot to reduce operational overhead and increase productivity.

> Docker in general isn't worth it relative to just VMs...

Thats not what I think. I have load balancing, autoscaling, health and update management with AWS ECS just fine, using just a couple of Cloudformation templates, each is a fixed text file. Two files with parameters is all I need :)

? Per the announcement, Docker Engine is also built on containerd.

Seems like more of the usual FUD that shows up on literally every post about Kubernetes regardless of the context.

But Docker created containerd to begin with...?

https://www.docker.com/docker-news-and-press/docker-extracts...

It sure looks like there was a plan to completely eliminate Docker and replace it with CRI-O and it looks like Docker Inc. responded to that plan by creating containerd so they could maintain some level of relevance. So yes, Docker can stay involved as long as they deliver what k8s wants, but k8s is clearly in the driver's seat now.

> This looks to be the beginning of the "extinguish" step from Google. They've executed the embrace, extend, extinguish playbook to a T with Docker.

True. Also:

- email. Keeping your own server unblocked by Gmail is a loosing battle.

- Web. Google AMP. Use it or get lost in search results.

- Android. Try make a phone with open source Android without Google apps and licensing.

Reply on news.ycombinator.com