Cloud Native Computing Foundation KubeCon + CloudNativeCon North America 2020 - Virtual, 4 Dec 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Inside Kubernetes Ingress - Dominik Tornow, Cisco

Description

Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe 2021 Virtual from May 4–7, 2021. Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.

Inside Kubernetes Ingress - Dominik Tornow, Cisco

Kubernetes Ingress is a core abstraction of Kubernetes: K8s Ingress grants access to K8s HTTP Services from outside the K8s Cluster. In effect, K8s Ingress exposes your HTTP application to the outside world. However, even experienced K8s users struggle to reason about K8s Ingress end-to-end. Using a systems modeling approach, this presentation will explore K8s Ingress to connect the dots between K8s Nodes, K8s Services, K8s Endpoints, the Ingress Resource, and the Ingress Controller. You will leave with an accurate, concise, and holistic understanding of how Kubernetes Ingress - in concert with other core Kubernetes Resources - enables scalable and reliable applications hosted on Kubernetes. Walk away with a dependable mental model of every aspect of Kubernetes Ingress and comfortably contrast K8s Ingress with alternative abstractions like the Ambassador API Gateway.

https://sched.co/ekAL

A

Hello and welcome to inside kubernetes ingress a kubecon and cloud nativecon north america 2020 presentation.

A

I am dominic torno principal engineer at cisco. I focus on systems modeling, specifically conceptual and formal modeling, to support the development and the documentation of complex software systems. This presentation focuses on the concepts behind ingress for kubernetes. It does not focus on its possible implementations or on its possible set of features.

A

Kubernetes ingress is related to kubernetes services to deep dive into kubernetes services visit inside kubernetes services, a kubecon and cloud nativecon, north america 2019 presentation.

A

What problem does increase for kubernetes address ingress for kubernetes enables the external consumption of a set of kubernetes http services hosted on one cluster via one http endpoint.

A

How does ingress for kubernetes address this problem to enable the external consumption of a set of kubernetes http services hosted on one cluster via one http endpoint ingress for kubernetes addresses two different concerns: network ingress, as well as kubernetes ingress network ingress addresses the question of how to emit traffic into the cluster kubernetes ingress addresses a question of how to route traffic within the cluster.

A

A kubernetes cluster is typically defined as a set of kubernetes nodes, a set of physical or virtual machines. However, this presentation is not concerned with nodes, so we will reason about a cluster as a set of parts that run run or will run on the cluster's nodes.

A

The first topic of this presentation will discuss network ingress. The admission of traffic, however, as kubernetes does not specify how to implement network ingress, leaving the implementation up to the operator of a kubernetes cluster. We will discuss only the what not the how the second topic of this presentation will discuss: kubernetes ingress, the routing of traffic. We will discuss both the what and the how before we develop a definition of ingress for kubernetes. We will spend the next few minutes to develop an intuition of ingress for kubernetes.

A

In order to develop an intuition of ingress for kubernetes, we will develop an intuition of both network ingress and kubernetes ingress. First up network ingress the admission of traffic.

A

Let there be two communicating endpoints, a service consumer and a service provider. The service consumer is not hosted on the kubernetes cluster. It is external. The service provider is hosted on the kubernetes cluster. It is internal network, ingress, denotes the point or means of admission.

A

Furthermore, network ingress implies directionality crossing from external to internal next up, kubernetes ingress, the routing of traffic. Previously there were two communicating endpoints, a service consumer and a service provider.

A

The service consumer has to learn the address of the service provider to actually consume the provided service. However, a persistent trend complicates this picture. One monolithic service provider is broken up into many service providers. Microservices.

A

Now the service consumer has to learn the address of each service provider to consume the services.

A

Kubernetes ingress is a proxy, an api gateway that exposes multiple service providers as a single endpoint, therefore greatly simplifying consuming the services.

A

Putting both together ingress for kubernetes is the composition of network ingress and kubernetes ingress, where network ingress is the admission of traffic into the kubernetes cluster and kubernetes ingress is the routing of traffic within the kubernetes cluster. In effect, kubernetes ingress is an api gateway with an intuition of ingress for kubernetes.

A

We will spend the rest of the presentation to develop a set of related definitions of ingress for kubernetes.

A

In order to develop definitions for ingress for kubernetes, we will once again develop definitions for both network ingress and kubernetes ingress. So, first up network ingress the admission of traffic in software engineering. A distributed system is an unbounded set of components from here on out called endpoints endpoints, communicate by exchanging messages via a network.

A

The behavior of a distributed system is attributed to the behavior of its endpoints and the communication between them. The complexity of a distributed system is attributed to the autonomy of its endpoints and the intricacy of the communication between them without loss of generality. Let's focus this discussion on two endpoints e1 and e2.

A

An endpoint is connected to the network via a channel.

A

The network maintains an association between endpoints and addresses from here on out. We will graphically represent this association as if the address is a property of the channel.

A

We keep track of the sequence of send events and receive events in an endpoint's history. If an endpoint wants to send a message, it will place that message in its channel an endpoint placing a message in its channel is represented by a send event.

A

The network picks up the message from the sending endpoints channel and determines the receiving endpoints channel and places the message in that channel. The network, placing a message in an endpoints channel is represented by a receive event.

A

In this network model, send events are tagged with a target address. The network places a message in the channel of the endpoint whose address matches the message target address.

A

This can also be represented graphically as a time space diagram. Each timeline represents an endpoint's history. Empty circles represent, send events, filled, circles represent, receive events, a pair or tuple of corresponding, send and receive events is called a flow. So far, we have applied a global point of view.

A

In this model. We are able to take the viewpoint of the all-knowing observer. We can observe both the channels of e1 and e2. At the same time, conversely, e1 or e2 cannot.

A

E1 can only observe its own channel and in our model, its own address, it simply cannot reach beyond. The same is true for e2. E2 can only observe its own channel and its own address.

A

So in order for e1 to send a message to e2, 1 first has to learn the address of e2. The same is true for e2. In order for e2 to send a message to e1. E2 first has to learn the address of e1 a process called endpoint discovery.

A

Moving towards the kubernetes network model in kubernetes network addressable endpoints are parts. The kubernetes network model specifies that any part can communicate with all parts without network address translation.

A

The kubernetes network model does not specify whether external endpoints can or cannot communicate with parts. As a consequence, depending on your cluster network, ingress may be trivial or complex to implement.

A

As we discussed earlier, we separate the set of endpoints into external endpoints and internal endpoints who communicate across that line of separation.

A

Here we consider endpoints 1 through 4 as being external endpoints and 5 through 8 as being internal endpoints. In effect parts.

A

Given the separation of endpoints into external and internal endpoints, we can classify the communication between endpoints according to the membership of the source and target of the communication.

A

There are four possible combinations in the first combination source is a member of the set of external endpoints and target is a member of the set of external endpoints.

A

This particular type of flow does not have a name in the second combination source is a member of the set of external endpoints and target is a member of the set of internal endpoints.

A

This particular type of flow is called north south traffic. In addition, given the directionality, this combination constitutes network ingress in the third combination source is a member of the set of internal endpoints and target is a member of the set of external endpoints.

A

This particular type of flow is again called north south traffic. In addition, given the directionality, this combination constitutes network egress in the fourth and love combination. Source is a member of the set of internal endpoints and target is a member of the set of internal endpoints.

A

This particular type of flow is called west east traffic.

A

So, in conclusion, network ingress can be defined as the set of all flows that originate outside the cluster and terminate inside the cluster.

A

Next up, kubernetes ingress, the routing of traffic kubernetes, defines a kubernetes ingress object. In effect, the kubernetes ingress object defines a collection of http request level, routing rules that determine the target of that request.

A

Ingress matches an http requests path and host header against its routing rules to determine the target kubernetes service to proxy the request tool.

A

This example illustrates a kubernetes ingress object. In effect, this ingress object defines a collection of four request level routing rules. In my personal opinion, these are best represented as a decision table.

A

For example, the first rule matches an http request with a host header of food.org and a path of slash a to proxy to a part that matches a service named foo a on port 8080, again represented as a row in the decision table.

A

The third rule matches an http request with a host header of bar.org and a path of slash a to proxy to a pod that matches a service named bar a on port 9090.

A

and again represented as a row in the decision table.

A

Represented as a time space diagram when the kubernetes ingress proxy receives a request, it matches the request against the decision table and forwards the request so that a part that matches the target service receives the request.

A

Why do I say forwards a request so that a part that matches the target service receives the request and not simply forwards the request to the target service, because there are implementations that implement their own pod discovery in accordance with kubernetes services, but do not rely on the discovery implemented by kubernetes and kubernetes.

A

Services next up the kubernetes ingress controller, the control plane component, kubernetes centers around the notion of kubernetes controllers and kubernetes objects.

A

Kubernetes controllers continuously read and write kubernetes objects, core controllers interact exclusively with the api server to read and write a set of kubernetes objects, edge controller interact with the api server to read and write a set of kubernetes objects, but additionally communicate with other components in the data plane.

A

Let's examine a few familiar examples: the kubernetes replica set controller is a core controller. It interacts exclusively with the api server. The replica set controller reads: replica, set objects and writes port objects. The cubelet is an edge controller.

A

It interacts with the api server and, with the container run type, the cubelet reads: port objects and instructs the container runtime to execute containers. Accordingly,.

A

Similarly, the kubernetes endpoints controller is a call controller. It interacts exclusively with the api server, the endpoints controller reads, service objects and port objects and writes endpoints objects.

A

The queue proxy is an edge controller.

A

It interacts with the api server and with the linux net, filter module, the cube proxy reads: endpoint objects and instructs the net filter module to create network address translation rules so that a message sent to a service ip address will be forwarded to a port ip address with the part being a member of the endpoints.

A

Now on to the ingress controller, an ingress controller is an edge controller. It interacts with the api server and with an ingress proxy. The ingress controller reads: ingress objects and instructs the ingress proxy to create routing rules. According to the decision table specified in the ingress object.

A

Lastly, next up the kubernetes ingress proxy, the data plane component, as discussed earlier network ingress, may happen before or after kubernetes ingress. So there are two possibilities: the ingress proxy may be an external endpoint or the ingress proxy may be an internal endpoint, a part, but either way. The task of the ingress proxy is to accept the request match the request against the decision table specified by the ingress object and installed by the ingress controller and forward the request so that a part that matches the target service receives the request.

A

So in conclusion, kubernetes ingress can be defined as a set of all flow pairs so that the first flow terminates at the proxy.

A

The second flow terminates at a port and there exists a rule in the decision table so that the request of the first flow matches, the conditions of the rule and the part matches the target service of the rule truly not as straightforward as the first formula.

A

Let's conclude: ingress for kubernetes encompasses two aspects: network ingress, the admission of traffic into the cluster and kubernetes ingress; the routing of traffic within the cluster.

A

Kubernetes ingress is composed of three building blocks: the kubernetes ingress resource, the kubernetes ingress controller and the kubernetes ingress proxy.

A

However, kubernetes provides only the ingress object, ingress, controller and ingress proxy are third-party components.

A

In effect, the kubernetes ingress object defines a collection of http request level, routing rules that determine the target of that request.

A

The ingress controller reads: ingress objects and instructs the ingress proxy to create routing rules. According to the decision table specified in the english object, the ingress proxy accepts the request match the request against the decision table specified by the ingress object and installed by the english controller and forward the request so that a part that matches the target service receives the request.

A

And, finally, what is the difference between kubernetes ingress and an api gateway like the ambassador api gateway? That, of course, is a trick question. In effect, the concept of kubernetes ingress is the concept of an api gateway and, in effect, the kubernetes ingress object is a standardized configuration for api gateways.

A

Popular api gateways like the ambassador, api gateway, can be installed to read the ingress object and act as the ingress controller and the ingress proxy.

A

If you are watching this presentation during the conference, I will be happy to answer your questions online. If you are watching this presentation after the conference, I will be happy to answer your questions via email, but either way. Thank you for watching inside kubernetes ingress.