Cilium and eBPF super-powers
Saying Cilium is a service mesh would be all true, but maybe not enough. That’s because of the technology worth mentioning, that makes Cilium known for its efficient and specific solutions. Cilium operates on top of eBPF, which is the successor of BPF, or Classic BPF which makes Linux Kernel programmable.
In my opinion, Cilium really can help us bring our cluster networking, observability, and security to another level!
GitOps and Flux
GitOps methodology is continuously proving its benefits with the help of different tools out there, including Flux. In KubeCon Europe Virtual 2021 Flux introduced to us the Flux V2 which will support multi-tenancy. Combined with Helm or Kustomize, Flux V2 will give you a very powerful automated state management solution, in other words, a software agent will be ensuring that the desired state of your Kubernetes Cluster which should be available on a VCS is up to date, checking for source code changes in custom intervals, along with different alerts and features for its end-users.
With all the automation it comes, unfortunately for the users that are aiming to migrate from Flux V1 it comes with a little bit of pain of manual configurations, because of the Flux V2 incompatibility with .flux.yaml files as they will not be supported anymore.
WebAssembly was another hot topic during the event. As we know WebAssembly was build with the browsers to be their main runtime, but lately it is taking place outside the browsers to, because of its security and flexibility. WebAssembly applications are isolated. Can run anywhere, with different operating systems and CPU system architectures. Sounds familiar? Yeah, containers... As Solomon Hykes, founder of Docker said on a tweet: “If WASI (WebAssembly System Interface) existed in 2008 we wouldn’t have needed to create Docker.”
No container technology is perfect, but they are very good at what they are designed to do and we should choose based on our needs. Comparing WebAssembly to Docker wouldn’t be fair, as they weren’t developed for the same purpose. But WebAssembly seems to have a future in the server-side combined with Kubernetes because of its high security, efficiency, and lightweight features.
Kubernetes network resources like Ingress and Services, that were part of it from the early days, solved us a lot of problems, but it was quite difficult and some times impossible, to use these resources for more advanced use cases. That resulted in using a lot of annotations and custom resources, which wasn’t a good experience. Gateway API will try to simplify this part of maintenance, saving us time and effort while scaling our applications.
The Gateway API project defines Kubernetes APIs to configure advanced concepts like traffic splitting, header matching, and load balancing configuration. It comes with new resource types: GatewayClasses, Gateways, and Routes like HTTP Route, TCP Route, UDP Route, and TLS Route. This model of dividing ingress traffic into more specific resources will allow the Gateway API to also expand its protocol support in the future. Do you want more? You can refer to the Gateway API official documentation!
So pretty cool yeah, all of these sweet tools at our fingertips. We are thankful to all presenters and organizers for this valuable event, for providing us with many different ideas and better thinking of future implementations. Indirectly providing value also at our partners and customers, giving them the best experience when we integrate these tools and methods in real-world solutions.
By the end, for those who couldn’t attend the event, it is available now on YouTube with all its sessions and keynotes.