Shulou(Shulou.com)06/02 Report--

This article mainly explains "how to achieve Kubernetes application deployment". The content of the article is simple and clear, and it is easy to learn and understand. Please follow the editor's train of thought to study and learn "how to achieve Kubernetes application deployment".

Overview

When you want to deploy an application in Kubernetes, you typically define three components:

Deployment (Deployment): this is the way to create a copy of a Pod application

Service (Service): scheduling traffic to Pods's internal load balancer

Ingress: describes how traffic flows from outside the cluster to the service.

Visual illustration

First of all, in Kubernetes, the application should be exposed through two layers of load balancer: internal load balancer and external load balancer.

Secondly, the internal load balancer is called the service, while the external load balancer is called the ingress.

Finally: Pods is not deployed directly. Instead, Deployment creates a Pods and an observer on it.

Apply YAML example

As an example of a simple Hello World application, the YAML of the application is as follows:

ApiVersion: apps/v1

Kind: Deployment

Metadata:

Name: my-deployment

Labels:

Track: canary

Spec:

Selector:

MatchLabels:

Any-name: my-app

Template:

Metadata:

Labels:

Any-name: my-app

Spec:

Containers:

-name: cont1

Image: learnk8s/app:1.0.0

Ports:

-containerPort: 8080

-

ApiVersion: v1

Kind: Service

Metadata:

Name: my-service

Spec:

Ports:

-port: 80

TargetPort: 8080

Selector:

Name: app

-

ApiVersion: networking.k8s.io/v1beta1

Kind: Ingress

Metadata:

Name: my-ingress

Spec:

Rules:

-http:

Paths:

-backend:

ServiceName: app

ServicePort: 80

Path: /

The definition is so long that it is difficult to discover the interconnections between components.

Compare these questions as follows:

When should I use port 80 and when should I use port 8080?

To avoid conflicts, should a new port be created for each service?

Is the label name important? Should the naming be the same everywhere?

To answer these questions, read on:

Connect deployments and services

In fact, there is no direct connection between the service and the deployment, and the service skips deployment and points directly to Pod. Therefore, what you should pay attention to is actually the interrelationship between Pod and services.

Key points

In their relationship, they should pay attention to:

The service selector should match at least one tag of Pod

The target port (targetPort) of the service should match the container port (containerPort) of the container in the Pod

The service port can be any number. Multiple services can also use the same port because they are assigned different IP addresses.

Visual illustration

1. Consider the ports exposed by Pod under service

two。 When you create a Pod, you should define a port containerPort for each container in the Pod.

3. When you create a service, you can define the port and the target port. But only the destination port can be used to connect the container

4. The destination port and the container port should match.

5. If the container exposes port 3000, the targetPort should match that number.

If you look at the YAML, the label and ports/targetPor should match:

common problem

So what is the purpose of deploying the top track: canary tag?

Should it be a match?

The deployed track: canary tag is part of the deployment and is not used by the service selector for traffic scheduling. So this tag can be deleted or assigned a different value.

What about the matchLabels selector?

It must match the Pod tag that the deployment uses to track Pod.

Pod configuration modification, how to test?

We can use the following command to check that the label of Pod is correct:

Kubectl get pods-show-labels

For Pod belonging to multiple applications, use:

Kubectl get pods-selector any-name=my-app-show-labels

Where any-name = my-app represents the label any-name:my-app.

Or you can connect directly to the Pod: you can use the kubectl port-forward command to connect to the service and test the connection.

Kubectl port-forward service/3000:80

Where service/ is the name of the service, such as "my-service" in the example, 3000 is the port you want to open on the computer, and 80 is the port that the Service exposes in the Port field.

If you can connect, the settings are correct. If not, it is likely that the label is configured or the ports do not match.

Service and ingress connection

The final step in the application release is to configure the Ingress portal.

Key points

The portal must know how to retrieve services, and then retrieve the Pod and schedule traffic to them. The portal retrieves the service by name and exposed port.

There are two things that should match between the entry and the service:

The servicePort of Ingress should match the port of Service

The serviceName of Ingress should match the name of Service

Visual illustration

First, a port has been published for the service.

Second, there is a field in the entry called service port (servicePort).

At this time, the service port and ingress service port should always match.

Finally, if port 80 is assigned to the service, its servicePort should also be changed to 80.

First, the fields to be noted in the example configuration:

common problem

How to test the function of the portal?

You can use the same policy as before for kubectl port-forward, but you should connect to the Ingress controller, not to the service.

First, retrieve the Pod name of the Ingress controller using the following command:

Kubectl get pods-all-namespaces

Execute the following command on the confirmed Ingress Pod (possibly in a different namespace):

Kubectl describe pod nginx-ingress-controller-6fc5bcc-- namespace kube-system | grep Ports

Connect to the Pod using the get port:

Kubectl port-forward nginx-ingress-controller-6fc5bcc 3000 80-- namespace kube-system

When you access port 3000 on the computer, the request is forwarded to port 80 on the Ingress controller Pod. If you visit localhost:3000, you can see the released application.

Thank you for reading, the above is the content of "how to achieve Kubernetes application deployment", after the study of this article, I believe you have a deeper understanding of how to achieve Kubernetes application deployment, and the specific use needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.