There are many others so instead of mentioning them all I tend to pick two most commonly used (adopted) and those are istio and linkerd. Consul is certainly there, as many others, but i feel that it's adoption is not as big as of the other two, at least when kubernetes is concerned.
Thank you Viktor for this great video. Just wondering, why are you so sure that the futur of service mesh is eBPF ? I mean, today, Linkerd is rather promoting the lightweight sidecar model. Istio released its new architecture called Ambiant wich relies on node agent. In my opinion, eBPF looks great for L4 network operation, which is the case with Cilium. But for example, implementing retry fonction or circuit breaking at the kernel level seems way to complicated or even impossible. What do you think of that ?
We will see whether that's possible or not. If it is and we can get rid of sidecar containers, i will be slightly happier than i am today. The fact that istio is moving towards eBPF tells us that the direction is a good one but, as you said, we are yet to see how far it can get us.
I'm curious about your statement (most serious Con), that Cilium might not be installable in an existing K8s cluster. Would you mind to elaborate on - why this would be the case - and maybe - which are the conditions, when it CAN be installed ?
It all depends on provider-specific instructions. Often, worker nodes need to be created in a specific way and, if they are not, you might need to recreate them. You might not need to touch the control plane nodes but worked nodes do need to be created again. Double check the Cilium installation instructions for your provider.
The examples of CiliumNetworkPolicies you showed I think can (mostly?) be done with k8s builtin NetworkPolicies (via any compatible CNI). What would an example of what only Cilium can do?
Those that I used in the demo can be done in, more or less, the same way with k8s Network Policies. Cilium provides a more extensive library of what can be done (and I should have picked a better example). Nevertheless, what makes Cilium "special" is not around specific features (there are many other ways to accomplish the same), but that it uses eBPF which provides better integration with the system, the ability to gather more (fine grained) data, and better performance. If eBPF is not something that matters to you, there is no strong reason to adopt Cilium.
Nice one. Can you make a video for deploying a Kubernetes application with all the best practices like network policy, ingress, apigateway, container signing like that in your own way to deploy production cluster. It would be great for us.
I almost forgot... You Choose ruclips.net/p/PLyicRj904Z9-FzCPvGpVHgRQVYJpVmx3Z is going through everything required to run applications. Only a few episodes were released so it's not yet complete though.
Hi Victor, you're lucky you'r in Florida 🙂, in the UK there isn't the same weather 🤣😂 If I'd like to install Clium have I to spin up a cluster from scratch? 😠that's would be a great deal-breaker I hope they will remove this big constraint otherwise it will limiti the popularity
Unfortunately, a cluster often needs to be created in a specific way to support Cilium. For example, GKE nodes need to have a specific taint to support Cilium. In some cases, you might be able to install Cilium in an existing cluster but performance might not be as good as it could. In any case, I suggest checking out the install instructions for your Kubernetes provider/flavor. You might end up having to just install Cilium. If that's not the case, you might use the opportunity of the next cluster upgrade to install Cilium. After all, upgrade results in eventual destruction of all nodes and creation of new ones (hopefully through rolling upgrades).
architecture wise "sidecar" is a terrible idea that got incorporated in lots of solutions unfortunately. just conceptually injection of additional workload in any pod you running... unbelievable how community adopted and accepted/tolerated it.
I would not say that it is a terrible idea. It is better than what we did before by bundling those features into code. However, by being better does not mean it's great. eBPF can make it great by still not being bundled into the app but being less obtrusive than sidecars.
What do you use for networking in Kubernetes? Kube Proxy? Cilium? Something else?
Fantastic seeing Viktor in warm weather walking outside and not stuck to the office :)
I like this new way you did the video! With walking and talking! You can do more of this type! 😀
It was an experiment in that and the next video. If people like it I'll do more in that style but only when it's warm.
Love your channel. I work on Consul and every time you said "Istio and Linkerd" I was like "... and Consul"?
There are many others so instead of mentioning them all I tend to pick two most commonly used (adopted) and those are istio and linkerd. Consul is certainly there, as many others, but i feel that it's adoption is not as big as of the other two, at least when kubernetes is concerned.
@@DevOpsToolkit oh of course! I’m just teasing. I’m also really interested in applications of eBPF. Thank you for making such great content!
Istio with eBPF would be great. Thanks!
Calico also seems to be going to eBPF now btw
Yeah. Calico is the main "competitor" to Cilium in that space (networking).
I still think Calico is more established at the moment for Network Policies but the landscape is changing
Actually, I think that Cilium is better established, at least when adoption is concerned, especially since it joined CNCF.
Thank you Viktor for this great video. Just wondering, why are you so sure that the futur of service mesh is eBPF ? I mean, today, Linkerd is rather promoting the lightweight sidecar model. Istio released its new architecture called Ambiant wich relies on node agent. In my opinion, eBPF looks great for L4 network operation, which is the case with Cilium. But for example, implementing retry fonction or circuit breaking at the kernel level seems way to complicated or even impossible. What do you think of that ?
We will see whether that's possible or not. If it is and we can get rid of sidecar containers, i will be slightly happier than i am today. The fact that istio is moving towards eBPF tells us that the direction is a good one but, as you said, we are yet to see how far it can get us.
Amazing video and weather, can you send some of that sunshine over to me?
It was temporary. I spent a week in Florida and now I'm back home and cold 😔
I'm curious about your statement (most serious Con), that Cilium might not be installable in an existing K8s cluster.
Would you mind to elaborate on
- why this would be the case - and maybe
- which are the conditions, when it CAN be installed ?
It all depends on provider-specific instructions. Often, worker nodes need to be created in a specific way and, if they are not, you might need to recreate them. You might not need to touch the control plane nodes but worked nodes do need to be created again. Double check the Cilium installation instructions for your provider.
Such a nice weather 😂
The examples of CiliumNetworkPolicies you showed I think can (mostly?) be done with k8s builtin NetworkPolicies (via any compatible CNI). What would an example of what only Cilium can do?
Those that I used in the demo can be done in, more or less, the same way with k8s Network Policies. Cilium provides a more extensive library of what can be done (and I should have picked a better example). Nevertheless, what makes Cilium "special" is not around specific features (there are many other ways to accomplish the same), but that it uses eBPF which provides better integration with the system, the ability to gather more (fine grained) data, and better performance. If eBPF is not something that matters to you, there is no strong reason to adopt Cilium.
Hi I like this format walking and tech talkie 👌☺️
how do you weigh eBPF vs Istio ambient ztunnel and waypoints?
It depends on what you need from istio. Ztunnel implements only a subset of features and if that's what you need it's the way to go.
Nice one. Can you make a video for deploying a Kubernetes application with all the best practices like network policy, ingress, apigateway, container signing like that in your own way to deploy production cluster. It would be great for us.
I should make something like that. Adding it to my to-do list...
I almost forgot... You Choose
ruclips.net/p/PLyicRj904Z9-FzCPvGpVHgRQVYJpVmx3Z is going through everything required to run applications. Only a few episodes were released so it's not yet complete though.
Welcome to our state of FL Viktor !
I love it. I had a great time and weather was fantastic. I'll do my best to find an excuse to come again.
Can Cillium provide Service Mesh function and able to replace Isitio ?
That depends on the features you're looking for. Cilium does support some but not all of those available in Istio.
What are you doing inFlorida? Did you relocate?
No. I was there for a week only. I came for Civo Navigate event.
Hi Victor, you're lucky you'r in Florida 🙂, in the UK there isn't the same weather 🤣😂
If I'd like to install Clium have I to spin up a cluster from scratch? 😠that's would be a great deal-breaker
I hope they will remove this big constraint otherwise it will limiti the popularity
Unfortunately, a cluster often needs to be created in a specific way to support Cilium. For example, GKE nodes need to have a specific taint to support Cilium. In some cases, you might be able to install Cilium in an existing cluster but performance might not be as good as it could.
In any case, I suggest checking out the install instructions for your Kubernetes provider/flavor. You might end up having to just install Cilium. If that's not the case, you might use the opportunity of the next cluster upgrade to install Cilium. After all, upgrade results in eventual destruction of all nodes and creation of new ones (hopefully through rolling upgrades).
@@DevOpsToolkit Thanks buddy!!!
Of course I'll keep an eye to the project, it's very promising and.... I hate ISTIO, it's too intrusive
Am waiting at 1:42 to see you pull a shell, and start typing, "this is what I did before,....instructions are in the gist below...."
I wanted to do it outside, but it was so bright that i could not see the screen 😔
Calico?
It's coming....
architecture wise "sidecar" is a terrible idea that got incorporated in lots of solutions unfortunately. just conceptually injection of additional workload in any pod you running... unbelievable how community adopted and accepted/tolerated it.
I would not say that it is a terrible idea. It is better than what we did before by bundling those features into code. However, by being better does not mean it's great. eBPF can make it great by still not being bundled into the app but being less obtrusive than sidecars.