My experience at KubeCon 2020 North-America (Virtual)
For those who don’t know, KubeCon is a bi-annual conference around Kubernetes. In fact, it’s more about the whole ecosystem around Kubernetes which is backed by the Cloud Native Computing Foundation (CNCF).
It was the first time for me and I wanted to share my experience with this new conference.
DisclaimerEven though I worked for the last 8 months as an architect on a Kubernetes platform, I have to mention that I’m mainly a developer. Moreover, my background in the past years is almost exclusively around .NET and the Microsoft technologies. I think it could explain why I saw this event like this.
Watching a lot of talks, I think I can say that I saw some trends during this conference. I would like to share three of those.
Innovation is on top of Kubernetes
As its name KubeCon suggests, we could imagine that the whole conference would talk about Kubernetes and its new features, but it’s really not only that. In fact, it’s more the opposite. Sure you have a lot of talks about new things in Kubernetes, but all the hype is more about what’s being built on top of that customizable platform. I don’t remember listening to a talk only about the orchestrator.
I think we can conclude that the foundation is rock-solid and vivid. So, it confirms that Kubernetes is the only container orchestrator to think about.
One fun fact is that a lot of people seem to say that Kubernetes will become boring really soon. Actually, in an Ask Me Anything session with Brendan Burns, he mentioned that people have been saying that for the last 4 years, but it’s still not the case. Accordingly, one quote that I loved during this conference is the following :
First time I heard the term GitOps, I did searched a bit on that and I thought I understood the concept. I remember saying to myself: We have CI/CD pipelines, it’s the same thing! I was wrong.
GitOps is the idea that you control your operations from a Git repository.
In fact, it works really well in the Kubernetes world since you have containers. Developers are working as usual with a Git repo to make their codebase changes. Next, a CI/CD pipeline creates the resulting container and stores it in a container registry. The magic happens right after that. Instead of having a pipeline deploying your app in Kubernetes, an agent monitoring a git repo containing your deployment specifications will take care of the deployment.
A lot of GitOps tools were presented at KubeCon this year and we see that it’s a trend that will continue in the future. There were some talks about ArgoCD and Rancher Fleet. I also know that Microsoft is deploying FluxCD with its Azure Arc new product.
Having been on a project around Kubernetes lately, I have to say that managing those pipelines with infrastructure as code scripts like Terraform can be cumbersome. GitOps can help a lot in that space.
DevEx: it must be easier for developers to deploy
As I’m fundamentally a developer, my eyes were caught by a lot of talks around the idea of simplifying the developer experience. Kubernetes is great, but I don’t feel like it’s something that should be given as is to developers. I love what many vendors are doing with PaaS and FaaS and I think that those initiatives are more aligned with the ultimate developer goal : just run my app!
Deploying applications to Kubernetes is great and it gives you a lot of flexibility (rolling updates, canary deployment, a/b testing, …), but it’s still a lot of work to do in many cases. You have to manage a lot of YAML files and, you know… it’s YAML…
Projects that caught my attention
Argo CD is a sub-project of Argo. It’s mainly maintained by Intuit, which is great since they’re not a vendor. Argo CD is also based on GitOps Engine another sub-project of Argo. GitOps Engine is what GitLab has decided to use to power their GitOps’ offer. It seems really mature and I think everybody looking to GitOps should take a look at it.
Argo CD is implemented as a kubernetes controller which continuously monitors running applications and compares the current, live state against the desired target state (as specified in the Git repo). A deployed application whose live state deviates from the target state is considered
OutOfSync. Argo CD reports & visualizes the differences, while providing facilities to automatically or manually sync the live state back to the desired target state. Any modifications made to the desired target state in the Git repo can be automatically applied and reflected in the specified target environments.
For additional details, see architecture overview.from: https://argoproj.github.io/argo-cd/
I heard some discussions on Kustomize in the past, but I never had the time to look deeper at it. For those familiar with Helm, it’s not the same thing. Helm is a template-based package manager that will encapsulate your deployment in a tarball file.
Kustomize is different. For the .NET developers, you can see Kustomize as the equivalent to web.config transformations. You basically write your default YAML files with all the content for one environment. Parts that have to be different for specific environments will be overridden by some small YAML files in sub-directories.
It could be a lot simpler to manage your staging files like this instead of using Helm. Nevertheless, Helm adds a lot of features for managing the deployment. They don’t share the same goal. They are different approaches.
Open Policy Agent & Gatekeeper
Open Policy Agent (OPA) and Gatekeeper are very impressive. The first one is a generic rule engine that can help to codify policies of all sorts. You could use it to define authorization rules for your app or to enforce some rules in your terraform deployments. So, very flexible and powerful for policy management. REGO is the language used to code your policies.
In the Kubernetes world, for large enterprises or regulated ones, it’s important to enforce some governance rules across the organization. In a nutshell, Kubernetes supports what we call an Admission Controller that can be invoked by the API Server to validate some policies. Coding your policies at this level can be difficult and it’s why Gatekeeper was created. It’s basically an admission controller implemented with OPA.
Cool features that I have noted :
- Unit test enabled with Conftest and Konstraint
- Easy to integrate in CI/CD (basic cli)
Check it out : https://github.com/open-policy-agent/gatekeeper
One of the talks that surprised me a lot is the one about Tye. This Microsoft project is trying to shorten the inner-loop for developers developing with .NET containers. I was already aware of this experimental project because it was publicized at Build last spring, but they’ve made real good improvements since then.
You could see Tye as a simpler Docker-compose that will help you to setup your apps on your desktop. As developers, we just want to clone a repo and press F5. Isn’t it?
All you have to do is to open a terminal and type: tye run.
The cli will compile your projects and run them ensuring that you won’t have port conflicts. No need to create a dockerfile to containerize your application. If you have one, great! Tye will use it. If not, it will generate one if required.
Tye can also manage your dependencies. Let’s say you need a Redis cache container or something like this, Tye could also start it with your apps.
It’s difficult to explain in only few paragraphs all the power that Tye can give you. I strongly recommend to every .NET developer working with containers to have a look at it.
Talking with colleagues during the conf
I proposed to my LinkedIn network to join me to a discussion during the conference on Slack. In fact, I initially proposed a LinkedIn group, but it was not a good idea. Instead, we all meet together on the Kubernetes Canada slack workspace. (http://k8scanadaslack.herokuapp.com/ if you want to join the community.)
For me, it added a lot to the conference because we could share our thoughts with each other. I know there are a lot of other possibilities to do that, but creating a channel for French colleagues was a very nice experience.
Well, I don’t feel it’s open source…
I would like to talk a bit about a feeling that I had during the conference. I didn’t feel like it’s all open source. Why? Because a lot of project maintainers are working for tech companies that tend to have something to sell to you.
For sure, most of the code is open source. You can browse it, modify it and use it for free. But those projects are maintained be people that are paid by companies that want to sell you a product based on an open source project.
I think that the CNCF tries to keep things as open as possible, but you have to manage the vendors as an attendee. What about vendor lock-in in this case? I think that’s a fallacy.
One more thing that pushes me in this thinking scheme is the recent conflict between Google and the CNCF about Istio. Indeed, I was surprised to see a talk about Istio knowing that Google decided not to give the Istio project to the CNCF.
KubeCon 2020 NA is already behind us. But I still have sessions to look at in the next days. I can say that sessions were great and interesting (cannot say the same for Keynotes though…). I would recommend for anybody working with Kubernetes to attend this conference.
All the content will be published on their YouTube channel. You can already browse sessions from last KubeCon (Europe 2020):
Also, there will be a recap meetup organized by your local CNCF community. For folks in eastern Canada, you can find the link here :
I hope you enjoyed reading this long post 🙂