1. Networking, Load Balancing, and Security
Let us dive deeper into networking, load balancing, and security in Kubernetes.
2. More on Labels and Selectors
Let us look at Kubernetes labels and selectors in more detail.
Labels key-value pairs that can be attachted to objects like Pods, Persistent Volumes, or even Nodes. We use labels to organize subsets of our objects, and we can modify our labels at any time. For example, we could attach the label/value pair "environment is prod" to some of our pods, or we could attach a label "has_GPU" with the value "true" to the nodes in the cluster that have a GPU.
We use selectors to identify objects using these labels.
For example, we could use the "has_GPU" label to schedule a Pod that needs the compute power of a GPU.
3. Networking and Services
Let's recap Services now.
As we have learned previously, we use Services in Kubernetes for networking. The reason is that each Pod has its unique IP address, which changes any time our Pod gets redeployed.
Services are not ephemeral; they offer stable connectivity.
4. Service Manifests
Services can be created using Manifests.
On the right, we have a snippet of a Service Manifest, which would deploy the service named "kubernetes_service_2" as shown on the left.
Besides metadata which we declare as usual, our selector selects all Pods that have a label named "app" with a value of "app2".
Now, if our purple Pods on the right have this label attached, these Pods would
be assigned to our service, and we can start communicating with other
services.
5. Load Balancing
Load balancing is another feature that is correlated with networking and easy to
implement in Kubernetes. A load balancer simply distributes network requests evenly over Pods.
This avoids uneven load, which leads to more efficiency and
lower response times. In the example on the left, the Kubernetes Service 2 is a
load balancer and has three Pods attached. Requests for this service will be
spread out to the three pods.
6. Load Balancing in Kubernetes
Load balancers are just a special type of service, which we can declare in the
"spec" section of the Manifest.
When we deploy the service, our Kubernetes Provider will create a load
balancer for us. We do not need to declare additional manifests to deploy actual
load balancer software.
7. Ingress
Let's finish networking with a few words on Ingress.
Ingress allows us to route HTTP and HTTPS traffic to services.
This is done by rules that define which service is used by which requests.
In our example, the ingress rules route requests for endpoint /for_service_1 to Kubernetes Service 1, and requests for endpoint /for_service_2 to Kubernetes Service 2. The respective Pods finally serve these requests.
8. Kubernetes Security
Finally, let's talk about security in Kubernetes.
Security is an essential field, and modern IT architecture has to implement many security standards and best practices. But it is also a very complex field, and we cannot cover all the details here.
However, keep in mind that Kubernetes comes with all the
necessary components to run our applications securely.
For example, we have the "Secret" API that allows to store confidential objects like passwords, tokens, keys, and others.
Furthermore, there is tooling to enable encrypted network
communication.
Plus, there are methods to authenticate users, allowing modern role-based and attribute-based access control for our users.
9. Let's practice!
Let's practice networking in Kubernetes.