Links Mentioned in This Episode

• BigBinary on Twitter


• Kelsey on Twitter


• Rahul on Twitter


• Kubernetes


• Containerd


• CRI-O


• Spinnaker


• Jenkins


• Prometheus


• Grafana

Transcript

[0:00:00 ] RAHUL: Hello and welcome to the new episode of “All Things Devops” podcast. Today we have Kelsey Hightower from Google. I think I don’t need to introduce him. He was a keynote speaker last week in Kubecon and a keynote almost everywhere where there is a container conference or any other conferences like Gophercon is happening, you’ll find him. I welcome him on behalf of Big Binary and All Things Devops podcast. Hi Kelsey, how are you doing?

[0:00:29 ] KELSEY: Hey, how you doing?

[0:00:31 ] RAHUL: How was Kubecon and what else apart from the great debate about Kubectl, Kub-C-T-L or Kubcontroller. How was it?

[0:00:43 ] KELSEY: Oh yeah, I don’t care how people pronounce it. I say Kub-C-T-L but I never corrected it when they say it different.

[0:00:50 ] RAHUL: And how was the crowd and what were the, that was happening. How was the crowd doing about Kubernetes. I saw the tweets and videos like a lot of people, like from all over the globe. So how was the experience of Kubecon, which happened in Austin last week?

[0:01:08 ] KELSEY: Yeah, we had a 4200 people, so lots of people, coming to talk about not just Kubernetes but also things like Networking, SDL, Service Meshes, Security, lots of Machine Learning on top of Kubernetes, so a lot of people were coming to look at Kubernetes as a platform and different people need different things from Kubernetes
[0:01:30 ] RAHUL: I saw your demo that you demoing, you were just talking with Google Assistant and it was doing things for you, and it looked really great, so thanks a lot for that awesome demo. I was just curious to know if you’re working on something else or, is there any side project that in future we might see? Like if you want to deploy our app, we can just use a Google Assistant or something similar like that. Would we expect that something is coming up in the mainstream process of deployment workflow with Kubernetes?

[0:02:04 ] KELSEY: No, I don’t think there’s a really compelling reason to deploy with Google Assistant. I mean, you can, because the APIs are there, but I think people are better off just checking in their code to you know, to search repository, like GitHub, and then using a CI/CD pipeline to deploy their apps, I think that is a little bit more realistic and a little bit more repeatable, so I think people should probably focus more on, you know, end-to-end pipelines versus just deploying directly to a cluster.

[0:02:37 ] RAHUL: Yeah, end-to-end pipeline is the thing. So, one thing, what we notice in the past six months are, in couple of conferences like maybe Kubecon or AOOC and Hadoop. We see a lot of people are looking for Kubernetes as a service platform, so we have Google Container Engine already from Google. There’s ECS and now EKS has been launched. So, but still, if we check on most of the people are hosting their self-hosted Kubernetes cluster or container orchestration platform tool. So, with this all kind of, services as most of the cloud providers offer Kubernetes services, should we just assume now, going forward, will we almost having Kubernetes as a service platform, and we should be only worried about our deployment pipeline and all the automation that we need to just get them, or application deployment, and we should not be worrying about most of our cluster provisioning things, including bare metal, so there might be possibly the cloud providers will come up with bare metal cluster as well.

[0:03:49 ] KELSEY: Yeah, I think that’s the goal. I mean, if you’re a big company and you’re on-prem and you have to manage bare metal, there will probably be a small collection of people who have to install Kubernetes, make sure that it’s running, but the rest of the organization, ideally, should not have to think about Kubernetes or cluster, right? They should just think about deployment application. On the cloud, the cloud provider wants to also offer that experience, like of course, you can go and get a bunch of VMs, install Kubernetes on those VMs and tweak and tune it, but if you have a small team, you’ve got to ask yourself, do you want to manage the infrastructure, or do you want to build applications for your customers? And that’s why I think service providers will always try to provide an option where you can just focus on using the cluster and not managing the cluster.

[0:04:39 ] RAHUL: I’ve been managing some of the Kubernetes cluster and I would say, like, it’s really not as straightforward for anyone to maintain a Kubernetes cluster. Instead, it makes sense to just focus on the application deployment pipeline. So, I’m a big fan of your course “Kubernetes the hard way”and this is how I started learning Kubernetes and using it since then. So uh, in the latest post you just added Kubernetes 1.8.0 as a Kubernetes version to be used and you are using Containerd as in runtime instead of docker, though it is in alpha instead of Docker. So we know that CRIO is gaining a lot of attention and we are having a lot of other container runtime environments, there’s Rocket, there’s Containerd, so can we assume that now instead of using Docker, we have other, better alternatives, or else what was it like, you thought, your focus for version 1.8 will use Containerd instead of Rocket or something else?

[0:05:44 ] KELSEY: Yeah, I think going forward, most people probably won’t use Docker underneath Kubernetes unless you are using Docker to deploy Kubernetes. Most people I think, you’re better off with just the CRIO, which is the Container Runtime Interface if you’re using Redhat, they’ll probably ship CRIOs, CRIO, which is this purpose built, just for Kubernetes, some other people may decide that you should use Containerd, but I think going forward, Kubernetes does most of the heavy lifting, you only need a very little bit of support from the Container Runtime. So this is why you’re starting to see much smaller container runtimes, so people that are currently using Docker may want to transition to Containerd as the support starts to mature there, but going forward, I think Docker itself will evolve into, or it already has, to become its own platform so not just a container runtime, but something much bigger and, in that world, you’re probably better off just with Containerd or Rocket or CRIO.

[0:06:50 ] RAHUL: Ok, got it. And how about the recent announcement from Docker, like Docker is also providing the development platform with Kubernetes. So, going forward, if someone comes from the background, like he has developed his application with Docker, using Kubernetes as a development platform, and if the production Kubernetes cluster is running, container runtime as the Containerd or Rocket or CRIO, so I assume that would work straight away, because he’s shipping his application, developed with the Docker, which is backed by Kubernetes and it isn’t CRIO, as in Docker.

[0:07:30 ] KELSEY: It should work, if it doesn’t work, we’re going to have problems, right? If, if you run Kubernetes with Docker and the you run Kubernetes with CRIO and things don’t work the same, I mean, there’s a high chance that there might be a few things different, because there’s different runtimes underneath, but we hope that doesn’t happen, because that would lead to a bit of fragmentation and would hurt the portability story, right? If you’re running your app on one Kubernetes platform, and it’s not easy to switch to another, that would cause friction, so we need to make sure that doesn’t happen.

[0:08:04 ] RAHUL: Yeah, so I particularly haven’t explored such kind of things but uh, yeah, just, it came up while we were discussing so, so, uh, apart from this Containers and CRIO, so I have been coming across people who are trying to move their application with the traditional deployment where either they are on servers, bare metals or VMs and trying to containerize their app. So first they’ll Dockerize it, then they will move towards Kubernetes, actually people are facing the problem with some of the common things, one is regarding stateful applications and as you know, that has been solved, but different plugins, volume techniques or some techniques like using files system from Ceph, ClusterFS or something, I assume now, but that’s a solvable problem. Then, another major question is whether we should be using database services on Kubernetes clusters. If we are using, we’ll be needing more system data, storage techniques than which persistent storage to confirm and if we are running self-hosted Kubernetes then it is better to run database service from cloud provider if you are using GCP, use GCP database service, if you are on AWS use RDS and if you are running Kubernetes as a service from a cloud provider, then how to adapt this database service, or other services, or in general, how to migrate legacy applications in easiest way to Kubernetes or Containerized platform.

[0:09:36 ] KELSEY: Yeah, I, regardless of the technology, most people don’t have experience managing data services, right? It’s not about “Can I do it on Kubernetes, can I do it on Docker?” it’s that most people install the database on one big machine, they never touch it