Cloud Native Computing Foundation Online Programs, 23 Mar 2023

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Cilium 1.12 Release Webinar

Description

Join Thomas Graf, Co-Creator of Cilium, CTO and Co-Founder of Isovalent to learn more about the latest and greatest open source and enterprise features of Isovalent Cilium Enterprise.

00:00 Intro
03:18 Service Mesh and Ingress Controller
18:14 Cluster Mesh Improvements
21:50 External Workload Improvements
25:25 Security, including Tetragon
30:34 Networking improvements
38:10 User Experience
41:44 Isovalent Cilium Enterprise v1.12, including Hubble Timescape update
45:40 Q&A

Related materials:

Cilium 1.12 Release Blog: https://isovalent.com/blog/post/cilium-release-112
CNCF Announcement: Cilium 1.12: https://www.cncf.io/blog/2022/07/20/cilium-1-12-ga-cilium-service-mesh-and-other-major-new-features-for-enterprise-kubernetes/

- - - - - - - - - -

To learn more about Isovalent: https://isovalent.com/
To try our product: https://isovalent.com/resource-library/labs/
Follow us on Twitter: https://twitter.com/isovalent
We're hiring! https://isovalent.com/careers/

A

With that, let's get going and let's look at what's new in cilium 1.12, first of all, very high level overview of what is psyllium for those, maybe completely new to cilia, so psyllium originally created by surveillance. It's our company is ebpf-based networking security, observability and new in 1.12, also service mesh ingress. Obviously, we'll talk quite a bit about both service mesh and ingress. Sodium is a cncf project. It is at incubation level and we're currently completing all the requirements to graduate. Hopefully later this year.

A

Early next year, underlying or underneath of cilium are two core layers of technology. One's ebpf and we'll do a very super quick, deep dive on that, as well as envoy for layer, seven processing sulim is used across the world.

A

Lots of different users, many of them cncfn users, but obviously also many enterprises, uh on-prem clouds, telcos selem, is very. Very universal. Selem is also used heavily across managed kubernetes platforms such as google's antos gke, as well as eks, a uh when ga a little bit earlier, as well as for maybe slightly smaller cloud writers like digitalocean and so on. So you may in fact, already be using psyllium if you use one of those kubernetes distributions, so let's dive in ebpf in one minute. So what is ebpf?

A

It is what's driving slim underneath it's this powerful technology. You don't really need to understand it to use sodium at all, but it is very exciting because it's kind of the enabler for what cilium does and what so makes unique. Ebpf is essentially a programmable engine. At the operating system level, it was originally written for the linux kernel, since microsoft has also ported it to windows. So it's now also available on windows.

A

In a nutshell, ebpf is quite similar to what javascript is to a browser so similar to how javascript is making a linux is making a web browser. Programmable ebpf is making the linux kernel or the operating system programmable. So we can run programs when certain events happen, such as when we process network packets, when a system call is happening or being done when trace points are invoked or even when applications call certain functions.

A

This is how cilium is implemented. This is this is how many other edpf based product projects, leverage to provide infrastructure or solve user use cases. If you want to learn more about evpf, feel free to go to ebpf.io. It's a website where we host community-oriented content around ebpf, tutorials documentation, videos. You will also find the link to the ebpf summit with lots of recordings of former edpf summits. We actually have the ebpf summit coming up in just a couple of months.

A

So, if you are interested to dive deeper on evpf itself feel free to sign up to the ebpf summit, it's completely free and if you are really into vpf and want to still submit a talk, feel free to uh reach out to bill or liz rice on our slack. uh I think it's not too late yet to just to still put a talk in.

A

Let's start diving in psyllium 1.12. What is new um one of the most exciting features is that psyllium now is a fully capable ingress controller as well. So as you install cylin 1.12, you are gaining the ability to run psyllium or to enable the ingress controller. This means, if you define kubernetes, ingress resources, layer, 7, load, balancing you can now implement them directly with sodium and don't need to install another or an additional ingress controller. This allows you to do camera releases or canary rollouts path, based routing tls termination and so on.

A

Some of these features have been available before in psyllium, with manual configuration or with network policy configuration. We now all have a fully conformance, so we pass all the kubernetes ingress conformance tests uh fully conformant ingress controller uh for your for your kubernetes cluster. This applies to traffic into your cluster within the cluster, and you can even use ingress across or in the multi-cluster scenario as well.

A

This is an example on how it looks like when you probably many of you have been using ingress before no surprise here, you can define in this case an ingress service and do, for example, differ or hit different, load-balancing back-ends, based on the url or based on the path. In this case, when a user hits slash details, it would hit a different set of backends than if the user hits slash or the root of the url ingress is implemented using the existing onboard integration.

A

So it is using on void onward proxy underneath, and this has all the the functionality and the performance metrics of ingress or of the onboard proxy switching gears and talking about service mesh. So 1.12 is the first release where we have a new, exciting, sidecar free data path. So so far we have been offering option number two on this slide, which is the istio integration.

A

Some of you may have been using istio so far, and I've been combining that with psyllium and in this integration mode you essentially made uh psyllium aware of an existing independent sjo configuration or installation and cylinder will provide a couple of additional functionalities to functionality to istio such as removing the unencrypted traffic, as well as giving cilium the ability to enforce its own layer, 7 policies in the sidecar of sdl. So this is what we had so far, and you can of course continue using this. It continues to be fully supported with 112.

A

We have added an additional option that you can now run a so-called sidecar free data path, and I see the question. Sorry, I don't understand. Well the expression, sidecar free, we'll talk about this right now. um So in case you don't understand this. Yet we'll talk about what this means.

A

So what we're adding is essentially a side car free option. What is this side car so in in general? Service meshes so far have been implementing service mesh with a so-called side car proxy. This is the green box on the left side here. So it's essentially a proxy that would run one instance for every part, so for every blue part that you're running here on the right side, you need a sidecar proxy, whether this is linked or envoy or or or nginx or some other proxy.

A

You need another green box, this so-called cycar proxy, so you need like a lot of different cycle proxies. These sidecar proxies would be injected through the through a through a network iptables rule. So you see this first blue arrow, that's essentially across the network stack here and an ip table's rules would naturally will kind of transparently redirect all the traffic into a sidecar proxy. This is the so-called side color model. These are. This is how service meshes have been operating so far. This is how link d operates. This is how sd operates and so on.

A

When we now talk about side call free, we now have an option where you don't have to run one side card per pod, but you can actually run a sidecar free data path, and this operates in two modes. It will use evpf so no proxy at all whenever possible and we'll look into when that is the case, and then, if it, for some reason, is not possible to do the required functionality any dpf itself, it will use a per nodes onboard right now. This is a per node on y.

A

This uh proxy could also run at a different granularity, for example, per name space or per service account, um or even you could then go back and actually do still per pod. If you really wanted that so far, we essentially offer you to run it at the granularity of one per node, very similar to how the ingress controller does this as well.

A

This is gives essentially native network performance for a lot of the use cases and we'll look at those use cases where we don't need a proxy at all and it even improves the performance when a proxy is needed. We're also introducing this, unfortunately, didn't make the cop for 1.12, so it will be included in 1 113.

A

A new way of doing mtls that supports any network protocol, so mtls will no longer be limited to tcp, but you can essentially apply it to any network traffic and again without proxies, and this will be another massive gain, because we can keep native network performance without having to terminate connections with a proxy but still offer mtls based authentication and then we're also introducing we'll look at that in envoy crd.

A

This is a new c id that allows you to use raw envoy configuration for your service mesh needs in particular for advanced use cases and then a choice of additional control planes. What we have implemented so far is istio in the sidecar model, ingress and services in the per node model, envoy crd in the per node model, and we're now completing gateway api, so that will be coming as part of 113 and will probably actually be available independently before we even release full.

A

The full 1.13 um spiffy is also underway, unfortunately, didn't make the feature freeze for 112, but will be merged, hopefully in the next couple of months as well, allowing to essentially use spiffy identities as well as uh spiffy, spec or spiffy service ideas in our policies and bring the spiffy certificates to the mtls model for observability. You can leverage the existing integrations that we have so far what you're used to prometheus, fluentd, grafana, elasticsearch, open, telemetry and so on.

A

I said we'll look kind of a bit deeper into this sidecar free mode and what that what that brings? Obviously it brings a reduced footprint, so you you run fewer proxies. So, instead of having one per part, you will run one per node. This can massively reduce the both the memory and to compute resources you require because you don't need to bootstrap a new proxy every time.

A

You start a pod, for example, and you don't need to shut down the proxy when the part terminates as well, but it also has performance benefits and we'll get to that. But before we see kind of the promise impact, this shows what can be done completely in ebpf.

A

So no proxy, no sidecar, nothing and what still needs a proxy and when it needs a proxy, it could be the per no proxy or it could be the sidecar proxy, so things that we can do entirely in ebpf traffic management, obviously anything at layer, three layer, four, any low, highly low, any load, balancing at layer, three layer, four canary roll outs topology. Where routing.

A

I will have an example later on in this, as well as all of the multi-cluster capabilities, obviously, network policy, mtls and then very interesting, http or layer, 7 observability for the protocols, http tls, dns, tcp and utp. This data can be exported using either open, telemetry, traces and metrics or prometheus metrics or json tracing data as well.

A

So you can feed this into existing dashboards or existing existing tracing utilities or dashboards that you have when you configure things like traffic management, this means layer, seven load, balancing so path based routing header based routing sna, sniper, hostname based routing as well as ingress.

A

This is when we still use a proxy and it will inject envoy also for all the resilience features, retries layer, 7 rate limiting you can you can limit the bandwidth of a pod without a proxy using network bandwidth, but if you want to limit number of http requests per second, you need a proxy as well as tls termination and origination important here. This is not mtls. This is the case when you actually want to terminate tls on behalf of the app or you want to originate the tls connection on the app of the app.

A

This is where you also still need a proxy is mtls available for the zillion community edition. We have not decided this yet we'll get to that as we as we release it. So this is mtls. If you want to learn more about this new mtls model that essentially decouples the the payload or the data path from the actual authentication piece, there is a detailed blog that you can find linked here. So as we share the slides, you can click on this link and get the details.

A

The great benefit here will be that you can benefit from fuel full mtls from the authentication piece using integrated, spiffy or serve manager, potentially even something like istio or walt in the future, but support any network protocol and not having to terminate those connections, which means they will flow on the network like they have flown before same performance, same latency, no additional overhead.

A

You can still optionally, secure and encrypt them with ipsec or wireguard, but you can then gain or add the authentication piece decoupled from this for more details refer to the blog and reach out on slack. If you have more questions, so I promised a couple of benchmarks here that kind of show the impact. The left side is one case where we can do something in child in ebpf, in this case, http visibility or tracing so parsing http and emitting traces. uh This is the http request. This is the http response.

A

What is the http return code? What is the latency between request response and so on? Blue is no visibility, enabled so no parsing red is the latency. So just a tiny little of overhead when we have to do this with this parsing of http in edpf, this is for http, 1 and http. 2. and yellow is the sidecar. This latency addition is almost the same, regardless of the specific sidecar. Often they use the same http processing, library and often the override is actually injecting the proxy and not the proxy itself.

A

On the right side, we see the difference in performance that can be achieved if you need a proxy but you're not running side cars again, blue, no, no overhead, no http authorization red is with psyllium envoy and the cilium onway, filter and green here is the istio filter, which has a couple of additional capabilities compared to the psyllium's envoy filter, but is also more complex and in the green case, in the sdr case, we're running two side.

A

Car proxies in the red case we're running one perno proxy because to gain http authorization, we don't need to have two side cars again. We can do mtls without proxy, so we actually don't need two proxies just to gain hdp visibility but not least the psyllium envoy, conflict or envoy crd. This is a new crd that allows you to essentially bring envoy configuration could be listener, configuration could be, retries could be, termination could even be tunneling tcp and http or, like other, very complex or very advanced envoy functionality.

A

That is available and you can configure that directly in the crd and essentially redirect any connection you want into that envoy and apply that configuration. So if you, for example, have an existing envoy based service mesh- and maybe you have written your own control plane, you can actually port that over and potentially use our data path.

A

While you provide the envoy configuration or you have been using envoy kind of with manual configuration, then you can now automate that in the crd, so this is a way for advanced users to make use or full use of unvoiced capability in cilia, some of the higher level control planes integrations like ingress and gateway api, actually just map to this envoy crd. So this is the lower level construct and the higher level service mesh control plane integrations leverage this as an implementation.

A

Last but not least, here on the service mesh side, hubble integration with open telemetry, um we have massively extended this in 1.12, so you can use both the network, visibility and the service mesh visibility at layer, 7 and export metrics and traces in open, telemetry and feed that, for example, into a ui or a dashboard here that allows you to show spans.

A

I see one more question here: can you explain why istio needs two proxies, as you refer in your performance? Comparisons like yes, so in the istio case. um Essentially what istio does also? What link d does it? It starts one proxy for every single pod that you start and it will force all the tcp traffic off that pod in and out. You can limit that to certain ports, but by default you want to um redirect all the traffic both for any traffic, that's leaving that pod and for any traffic. That's entering this part.

A

So in a service mesh, you essentially go through uh two proxies unless you find a way to somehow disable that one of those two side cars as soon as you start running mtls in the sidecar model, you need two proxies, because the tls connection will be between the two sidecars. The apps themselves cannot or will not talk. Tls. You will need the orchard originating sidecar proxy to initiate the tls connection. You will need a receiving sidecar proxy to terminate tls perform mtls and then the actual app that receives the traffic.

A

um There is a psyllium service, mesh, sidecar, free blog post on isovalene.com.

A

We will also list that in the chat, I think um cornelia can take care of that unless that that goes into details of how this works and and um why, how a sidecar operates and uh how we can remove sidecars in certain in certain situations, switching gears a bit and talking about cluster mesh cluster mesh is the ability of solium. So it's not service mesh. It's not cycle related. This actually existed for several years now.

A

It's the ability to connect multiple clusters, multiple kubernetes clusters together purely on the network level, and it essentially enables you to connect them. Enforce network policies across clusters, gain visibility across clusters and also do service discovery or global load. Balancing across multiple kubernetes clusters as well. Exciting new feature in 1.12 is cluster mesh service affinity. So you can now take your existing kubernetes service. uh Keep the existing annotation. This is the iocillium global service.

A

So this is the annotation that marks this kubernetes service as global, which means it should be load balancing across multiple clusters, and you can now add a service affinity, and you can say please prefer a local backend, and what this now does is that if there are backends available both in the local or in the remote cluster, it will always prefer the local backend or the local instance until no local instance is available, and then it will go to the remote instance. You can obviously also turn this around and say: please prefer remote.

A

So to illustrate this. This is kind of how it looked before what you can have, what you have been able to do before. So you can define, let's say, a back-end service which is backed by both um parts in both clusters and the front-end talking to this back-end service. It would balance equally here. In this case you could not define a particular affinity.

A

What you can now do is, you can say, set it to local and then it will always stay local to that cluster whenever possible, but as soon as the the backends in that local cluster die, they become zombies. So for some reason, then it would fail over and actually go into, uh two back ends in the remote cluster. So this is a great way to do h, a um or to make services highly available with a backup cluster, which means you can stay local. You can benefit from the local latency.

A

You can avoid cross region cross across ac traffic, which is expensive but have to fail over opportunity into another cluster that may be running in a different region same here. If we set it to remote, it would go always prefer remote first and only use the local instance when required. This can be useful if you, for example, want to do if you want to log to a centralized logging service, but you have a backup available in the local cluster, so in for some reason the remote cluster is not available.

A

Then you want to fail over and actually log to a local logging instance. For example, another exciting feature around cluster mesh is the ability of running essentially minimalized or miniature to miniature clusters and connect them together. So you no longer need to bring the full cluster mesh control plane in every cluster. You can have essentially small edge clusters. This is, in particular, useful for external workloads or edge use cases, or you maybe only want to run a couple of parts and these edge clusters or remote clusters.

A

They can leverage the control plane of a centralized cluster or several centralized clusters, so this allows you to run cluster mesh, in particular for edge use cases, minimize the footprint at the edge or for the remote clusters and centralize. If you want more of the control plane infrastructure for more details on this, the the release blog has plenty of details on this external workloads. We had massive improvements around the integration of external workloads. External workloads are non-kubernetes workloads. You can integrate them into your cellium cluster or silly mesh.

A

So you don't need to containerize or integrate everything directly or run everything as part of kubernetes. You can run psyllium on a virtual machine or on a metal machine and integrates workloads on that machine directly with a kubernetes cluster. What we have improved in 1.12 here is, first of all, the egress gateway was promoted to stable. So this is the egress gateway.

A

Is the ability to bind parts which have constantly changing ip addresses per kubernetes ipam and bind them to stable ips or to fixed or static ips, which means you can use those static, ips and allow them in traditional firewalls.

A

This allows you to to add essentially network policies in your existing traditional firewall, which does not understand kubernetes, but only allow certain paws instead of the entire ip range of a cluster, because you can now, for example, for parts of a certain label or for an entire namespace map, those map, all of that traffic to either a specific ip or a set of ips.

A

We have added net 46 support to the load, balancer very exciting. You can now translate between ipv4 and ipv6 at the service level, so you can have an ipv6 only pod or even an entire cluster running only in ipv6 and then expose that pod with an ipv4 service ip and then at the service ip level. At the local answer, level cylin will automatically translate from ipv4 to ipv6, so you can essentially have- and this is what this feature was developed for.

A

You can have a cluster with hundreds of thousands of pods, where ipv6 is incredibly useful because you will have an unlimited amount of ip addresses or virtually unlimited, but then still expose those parts with an ipv4 address, and you don't need to give the pods themselves an ipv4 address. You can essentially do that at the service level, where you need much fewer or a lot fewer ip addresses so very exciting. This uh is supported for the stand-alone local answer.

A

Bgp enhancements vgp has been supported for a couple of releases in psyllium in 1.12. We have added full ipv6 support and we have also changed the online mechanics of the bg implementation to support additional bgp control plans.

A

This means that we no longer only depend on the metal lb implementation, but we can actually go from metal lb to go bgp which has additional functionality, including ipv6. With this move we have also become more more plugable or more modern modular, so we can actually support additional vgp implementations if required.

A

Vtep integration, a great contribution where we can now integrate psyllium with an existing vxlan tunnel, endpoint, that's potentially running in a traditional data center. So if you have existing vxlan tunnel endpoints, whether these are routers or advanced switches or other network appliances, you can now essentially terminate or create a vxlan connection from a pod directly to a vtep security.

A

Obviously I think most of you probably have not missed this. We have released tetragon, so tetragon is essentially our entry or psyllium's entry into runtime security, from both a observability and from an enforcement perspective. So we're bringing our knowledge of ebpf uh to the runtime security world. We have released tetragon. Initially. This was part of our enterprise distribution. We have open sourced large parts or vast parts of tetragon into into open source and have contributed it to the cncf.

A

We'll now look a little bit at tetragon, but at a high level you have very similar to celine. You have an user space agent called the tetragon agent that runs as a demon set, and you have a kernel portion that extracts the visibility and does the enforcement on the observability side.

A

We can look into a vast thing, vast level of different things like very deep observability from system very deep, like network packets, network protocols, file systems, files accessed namespace boundaries, privilege escalations, uh tcp stack system calls that are being executed, process, execution, forks news, news, sub processes being um being introduced or being forked and so on, as well as even function call tracing in the user's base side.

A

All of this is collected based on so-called tracing policies, which are crds and they are then exported either as prometheus, metrics or open, telemetry, metrics or via json or fluenty into, for example, an siem. So you can have logs traces and metrics for all of these security, relevant observability data. So it's obviously very deep visibility. It's completely transparent because it's using ebpf, so no app changes are needed. The applications don't even notice or understand when they are being observed.

A

It's low overhead thanks to ebpf and it brings all of the existing integrations. We had so far on the observability side. So if you're already running grafana and prometheus metrics for your selim deployment, you can neatly integrate tetragonal observability as well. Tetragon also offers enforcement uh here. The big difference to existing solutions like falco, is that the enforcement happens in the kernel itself, so the rule engine what should be allowed? What should be not allowed uh when certain things are being observed?

A

How to react on that is all in the kernel for other systems like falco. They export the visibility user space and have this filter engine in user space, which means they need to react. Asynchronously in user space tetragon essentially enforces and reacts almost in real time in the kernel and can thus prevent a lot more attacks instead of reacting to them integrations right now there is a kubernetes, cre and obviously json imports. So tetragon is not kubernetes specific. uh It is aware of kubernetes, but you can run tetragona outside of kubernetes as well.

A

If you want and we're working on an open policy agent integration, as well as a tooling that will allow to convert existing falco and part security policies into tattagon or just enforce plot security policies with tetragon on the left is what is available in tetragonal, assess so visibility enforcement and on the on the right side, are the extensions that are available in the enterprise distribution of isovalent cilia.

A

We have also improved psyllium as a security model in 112. Actually massive improvements. We've worked with several uh external contributors, we're very interested in improving the security posture of psyllium itself. This means that we actually removed a lot of privileges that were previously required by cilium. The most notable one is that now psyllium can be run unprivileged, so you no longer need to run it with just privileges. It still needs capnet admin capabilities, but it is obviously a lot less a lot, a lot smaller service than a full privileged container.

A

um Also, if available cap bpf, we have also massively reduced the um the number of kubernetes privileges that we need in terms of objects that we need to have that we need to modify or even have read access for a variety of the objects.

A

We have been able to move modifications to either completely remove them or to move them from the ceiling agent, which runs per node to the cilium operator, where you have um essentially just a few deployments, it's a kubernetes deployment, so you will run one two or three uh two one, two or three replicas with leader election, so you can actually run them, particularly on particular nodes uh where you may have no untrusted users on it for, um for example, so you can lock down psyllium further.

A

From that um perspective, we will continue to prove on this side, based on what we learn and kind of what we hear back and uh as psyllium progresses from uh from a number of deployments perspective. We obviously have more and more people looking into this as well, now, switching over to the networking side, so bbr for pots. Bbr is a very exciting, relatively new congestion algorithm for tcp.

A

It has been primarily developed by google and it's essentially allowing to improve latency massively in a lossy network like the internet. So if you are exposing services kubernetes services publicly on the internet- which I assume many of you are, you can now use bbr and actually improve the latency of those services. Massively one of our engineers has done an extensive talk about dbr at the last qcon, including a very impressive demo, where we had a a video being streamed over the wi-fi at kubecon, and it was lossy of course, right. It was a wi-fi.

A

We then enabled bbr and the video performance the video kind of the quality of the video improved significantly, because we were able to reduce packet loss and improve latency for the video streaming.

A

I saw that I missed one question on tetragonal: let's do this. Does tetragon have an impact on applications performance? Yes, it does. It will differ greatly on the level of policy that you um that you implement. So if we go back to here and if we say um if you want to log every single system call that is being invoked, every single write system call every single open system call and so on.

A

Then writing all of the all of those logs even to a local json file, will consume cpu cycles and in fact writing to file and doing the json encoding and so on. That will actually be the the biggest portion of the overall overhead, so the first kind of factor will be amount of observability data. You want so number of log lines per second and then metrics are more efficient than logs.

A

If we can accumulate metrics in edpf, that's a lot more efficient than if we have to emit a log line, 10 000 times per second, so it will really depend on the level of observability. You want uh as well as kind of the granularity and essentially how many log lines how many events per seconds this results in the great news is that um tetragonal allows to essentially export a lot of high level signals such as I want to log every time.

A

A part changes privileges where pecan, for example, becomes privileged becomes privileged or when a pod gains capabilities, for example, uh if somebody invokes sudo or if a process changes, namespace boundaries, for example, when a pros process enters or leaves a container namespace, and these events are high level, so you won't have many of them, but they're very relevant. So you can monitor that monitor this, and at this level the overhead is absolutely minimal, but as soon as you start exporting a lot of data, that's when the overhead comes in.

A

I hope that was a good answer to kind of show you um kind of the amount of impact it can be anywhere from one percent to 20, really, depending on what type of observability you want to get out of.

A

So going back to the networking piece, we talked about vbr um the the slide deck here, we'll link to the to the video that actually has a full-blown uh demo of this feature, as well as the q. Con recording, we've also promoted the bandwidth manager to stable the bandwidth manager is able to control the network resources of a part. So you can limit the traffic of a pod, for example, to 5 megabytes per second or to certain number of packets per second, so you can actually do resource control very similar.

A

How you can do this with cpu and memory as well. This supports the standard annotations that are available in kubernetes deployments and pods, and you can also automatically configure the the tcp congestion algorithm and optimize it. So cylin will automatically enable a variety of kernel level, tcp optimizations, that will improve the performance of the network for your particular parts by understanding what the parts require dynamic allocation of podsider. So this is exciting. We can now, instead of doing partside or ipams or one big block per node.

A

We can now do multiple blocks, which means we can, for example, assign slash, 26 or slash 20, 28 or slash 30, and then notes, as they run out of ips will go grab a new block, so this is kind of the middle ground between doing let's say a slash, 24 pod cider per node, where you will quickly run out of your total ip space or doing slash 32 individual ips, which is very expensive, because the control plane needs to do a lot of work, so dynamic allocation of plot side or is the middle ground.

A

This is, in particular, great for pgp integration, because you need to announce a lot fewer number of prefixes on the pgp network, quarantining service backends. You can now in kubernetes with kubernetes services, actually quarantine, a particular backend, which means this back end will stop receiving connections. This means you can gracefully shut down parts. What most people do today is actually just scale down the deployment and it will just cut off connections to this part.

A

So if this is a public publicly exposed uh service, whatever customers or clients are exhausting the back end that is being scaled down, they will just have their connection cut off, because the pod is uh turning off with current timing, you essentially stop uh redirecting new connections to a back end, and as soon as no existing connections exist, you can safely shut down or scale down the pod improved multi-homing for low balancer. So we are adding the ability to um essentially have multi for the standalone load balancer to support multi-homing.

A

This was not really optimized so far um for for multi-home nodes. We've now added the capabilities for this. This means that if you have nodes which are in a multi-home architecture, so they're part of multiple networks, they have multiple network interfaces. You can now define exactly how the local answer should behave in this environment, for example, should the client connect should they be coming in from one interface and then should it pick back ends on another interface and so on?

A

This is very useful, in particular, if you're on premise or if you have more traditional network, use cases aws c9 prefix delegation, so we can now finally really scale with our aws unite integration, and we now support the um the new prefix delegation mode of aws enai mode.

A

This means that you can essentially run um a lot more parts per node and have a more efficient ipam mechanism if you're running on aws, with the aws in eye ipam mode enabled also, we have a new ec ec2 instance tag filter for f4 for ipam, with additional capabilities details here on the slide or in the release block nice. This feature was contributed by an end user from new york times. We love when we see new features getting added by end users.

A

And I see another question from jerry: how to accomplish zero downtime upgrade from 111 to 112., I drive with psyllium cli and helmet chart. Not all of the sodium agent parts or slim operator will come up properly. That sounds like a bog approaches on on slack, we're also happy to hook you up with one of our um our solution: architects. This is psyllium, supports, rolling upgrades or rolling pot upgrades. You should have near zero or zero impact upgrades.

A

There are a few components that will have will be impacted, such as proxies or in the open source version, the dns proxy, um but in general you should not have drops and all the ceiling parts should of course come up when you upgrade so reach out to us, and I see we also have a bug report, one of the getting started docs does not exist.

A

We will get that fixed. You may need to change the url from latest to stable. uh That may actually just be a stale url that we need to fix. So, whoever wrote that question, if you, uh if you change that link or if you just go to the doc, to docs to student.io and click through service mesh, you should find the right post.

A

Can a cve be a trigger for a quarantine of a pot? Yes, you can use whatever whatever trigger you want. The typical use case is scaling down, but of course you can. Essentially, if you believe that a pod has been compromised, you can quarantine it. So it doesn't receive any new connection. You can keep the existing connection, including the connection of the potential attacker alive and maybe start investigating what is going on.

A

All right user experience, one asks we have received a lot is that the psyllium cli is great at automatically deriving the ideal configuration of psyllium for a particular environment, so it will automatically detect your cluster is running in aws or it's an aks cluster or it's gke or it's rancher or like, and it will automatically can generate the right or the best potential configuration on how to run psyllium with the latest 112 release. This feature is now available where it essentially emits helm flags.

A

So, instead of requiring to use this feature to now then install the psyllium install or with the cli install, you can essentially generate the ideal helm values for a new cluster. So instead of auto detecting the values and simply installing right away, you can essentially audit the vector values and emit helm flags and then uh install psyllium using your own helm, helm pipeline or your existing helm.

A

Workflow ashore bring your own cni, so sure cloud added, a new feature called bring your own c9, which essentially allows to install aks on azure um without any cni installed. This massively simplifies the installation of psyllium. We have a screenshot here before and after so before, you had to do a lot of different steps to install aks, including creating node groups and tainting nodes, to make sure that psyllium is installed first on the node before any other part gets scheduled very complicated with bringing your own cni. This essentially becomes very trivial.

A

You install a new aks cluster and bring your own cni mode, and you can simply install celium using the default installation path. No special workarounds required anymore, unfortunately bring your own cni is only available for new aks clusters. At this point I know several of you have already asked microsoft to support this on existing clusters as well. Hopefully, we'll have news on that later this year, all right a couple of things on these psyllium, I surveillance enterprise site for 112.

A

We have released an extension or a new version of hubble timescape timescape is the time series database that we offer where you can store all the observability data of hubble, of service mesh on the networking side, on the tetragon runtime site and so on and feed that into a time series database. So you can store that data persistently over time and then query it hubble or hubble times. Game is based on click house. So it's a modern time series database and you can use the existing hubble cli or the hubble ui or the click house.

A

Query api directly to essentially quality data, to generate metrics, to query and look for particular events or logs or even just to, for example, store your network metrics or your network logs or your runtime logs, or your security events, for let's say the last three months with the ability to go back in time and recalculate metrics or find particular events so great for security use cases, and also great for network troubleshooting and network operation, use cases.

A

Openshift, certification updates, of course, with 1.12. We have renewed all the certifications for both enterprise and oss. So we of course remain completely certified on openshift we're a certified operator as well as a certified cni. We have added offline installation support in 1.12. So that's a new addition with the latest release network visibility. This is a new functionality that comes by attention on enterprise. It's essentially the ability to look into a lot of uh very low level network metrics and network data completely passively and passively means that we're not actually parsing the network traffic directly.

A

So we're not really in the data path, so we're adding no additional latency but we're essentially parsing or understanding what the tcp or the linux networking stack does uh itself and can extract, for example, round-trip times of connections, or we can understand tls handshakes or we can instead understand number of like amount of traffic by looking at the sockets or the socket counters, instead of trying to parse and count network number of network bytes. So this can give you essentially the ability to monitor your network even in a super low latency environment.

A

This particular feature has been implemented for environments such as financial financial transactions with very low, fixed latency guarantees that need to be met. So it's essentially a feature that allows you to over to monitor your networks and to gain visibility into your network at extremely low overhead without introducing additional latency in the uh in the actual workload traffic fqdn, aha proxy.

A

So this is now fully stable and has been released as part of the enterprise version. This means that dns policies, so the ability of defining network policies based on dns names with wild cards, for example, podx, can talk to star.twitter.com and cylin will automatically allow only uh connections that have been have been where uh dns resolution has happened for this allowed pattern and then only for the ips returned by the dns.

A

So this feature is now available in a highly available fashion, which means, if you upgrade psyllium, if you restart psyllium, if sodium is down for some reason, the fqdn or the dns proxy is separate and is highly available, which means the pod can continue to resolve. Dns even as psyllium is restarted and connections are not impacted.

A

This was uh the overview of 1.12. We now have more questions for q a and I will go through the list again. If you have more questions, feel feel free to start listing them in the q. A uh in the meantime. If you want to learn more, we have a couple of options available.

A

First of all, if you want to see a demo of anything that we have just talked about, you can schedule a demo session uh with one of our eye surveillance experts here, one of our solution, architects, or even one of the feature owners and get a demo uh cornelia, just post the link in the chat.

A

You can simply click on that if you're interested and pick a time slot that works for you and we will schedule a demo session during that time with you, we also have labs or hands-on tutorials they're instruct based, which is amazing, because it gives you essentially within a couple of minutes of full psyllium environment where you can play around with new features, for example with the service mesh piece without having to install cylinder yourself.

A

So you can get hands on and actually walk through, some of the silly features and try them on without running mini, cube or kind on your on your own, on your own laptop or without bringing up a gke cluster, so a great way to to get hands-on very quickly within minutes.

A

And then, last but not least, we have a a webinar series around ebpf. So if you want to learn more about ebpf, if you're interested in what is going on around ebpf here this exciting technology, maybe you have seen let's rise talk about ebpf and you really want to learn more. What is under the hood of psyllium, we have essentially a ebpf, uh but in our series how the hive came to be uh where we will specifically deep dive on the ebpf side. um Cornelius just posted the link there as well.

A

So if you're interested in any of them feel free to click on the links and sign up, then I saw I missed one question from jim hello. Thanks for this awesome webinar for some of us who has used managed data services like gp, the selling capabilities we get while data playing v2 seem limited and unconfigurable in such a way that we can utilize all the capabilities we have seen on this webinar, and especially since gke, doesn't allow bring your own cli like a gear clusters, for example, yes mode like legacy mode host.

A

Writing I read somewhere in the docs. That only way you can run cylinder ebpf mode in google, is by bootstrapping your own cluster by cube admin which we can, which we may not want to do. How do we navigate this challenge? um So what we can offer you, as I surveillance I surveillance, does have a partnership with google. If you want to run a surveillance, salem enterprise on gk, then we can help you there.

A

Unfortunately, google does not allow running psyllium oss easily on gk itself right now. um Unfortunately, I cannot give you a better answer. If you want to run the full feature set of psyllium your best option. Right now is come talk to us and we can uh bring you into the um essentially the I surveillance psyllium version on gk. I know that's not the perfect answer, but that's the best answer that we can provide right now.

A

Let me double check if I um got all the questions.

A

I saw that regarding the service mesh. There was one question: can you explain the option two a little more, so let me talk a little bit about that. So that's the istio in the istio integration, so the is2 integration has existed for several years in this mode. You install psyllium, as you do normally no change required. Then you enable the is2 integration and then you install istio, as you would normally do. There's instructions in the docs.

A

What this will result to it will actually change the specific envoy version that is running uh as part of the sidecar, so it will bring the psyllium's envoy filter into istio as well. What this means that you can now run psyllium and sto side by side, and this tube will run a side card proxy in this mode whenever you define a psyllium or policy or when you define layer, 7, observability and the policy contains layer, 7 aspects, these aspects will be enforced or done via the side call vistio.

A

So silly will not start its own envoy proxy. It will use istio's, sidecar proxy. This mode will also optimize and we'll quickly go back to the slide, because it will make this a lot clearer. So if we go all the way back to the complicated injection strategy of istio or service meshes with the sad current channel, here we go there. We go so this initial kind of hook here this blue hook all the way down and into the service mesh or your service mesh psi card proxy with psyllium h2 integration.

A

We can essentially have this blue line connect at the socket level right away, so we can essentially short circuit the sockets directly together. This actually works for other node local traffic as well. It's not sidecar or service mesh specific uh with this feature enabled any connection that remains on the node. You can optimize this way.

A

It means that there is no network connection really or no network payload anymore, uh for the path from the app to the sidecar, which also means that nothing uh is left unencrypted, because if you run mtls in the sidecar mode, this initial blue hook is actually unencrypted, because the style car proxy will start tls, which means only the connection. That's leaving the sidecar will be tls encrypted and with the istio integration, because that blue hook gets shorter and there is no actual tcp involved.

A

It means that there is no network packets unencrypted on even a virtual wire for more information. There is an istio guide in the docs that you can follow to get started with this, otherwise reach out to us on slack and we're happy to help going back to the q a and we'll check one more time. If we have any more questions that came in all right, we're right there lots of slides. Here we go.

A

Downgrade we recovered cv, we covered yes, I think I think that was all the questions so again. Thank you very much for joining this webinar. I hope this was useful. Please give us feedback again if you want to learn more uh feel free to check out. One of the links here, of course, also feel free to join slack.

A

If you have not done so far, simply go to cilium.io click on the slack link and you can get in contact with the team of the devs with me and so on, reach out for follow-up questions, and with that I would like to thank everybody for participating and I'm looking forward to the next release. Webinar 113.

A

thanks a lot. Everybody.