“This is the 23rd day of my participation in the Gwen Challenge in November. Check out the details: The Last Gwen Challenge in 2021”

The previous article continued to deploy applications to K8S

The previously simple cluster was simply deployed, with three working nodes running on Docker and Kubelet and one control node

ReplicationController, POD, and Service are related

How does ReplicationController, POD and service come together?

You can explain it by looking at this picture

When we created the pod, we did not create it directly. We created an replicationController by docker Run, and then created a pod instance based on RC

In order for pods to be externally accessible, we need to have K8S expose all pods managed by replicationController by one service, hence kubia-HTTP

  • The service has an exposed IP address. The request is made to the service
  • The service forwards the request to port 9999 on the POD, which then provides the service

What is the ReplicationController role like

From the above example, we should know that ReplicationController is actually used to copy pods, using ReplicationController to create multiple copies of pods

ReplicationController always ensures that there is a running POD instance

If the pod we created above disappears, ReplicationController will create a new pod to replace it

Why service is needed

Consider service, the kubia-HTTP service above

Why do you need a service when you have a POD?

When a POD disappears, ReplicationController creates a new one to replace it

We also know that each pod has its own independent hostname and IP

The POD will hang and disappear in the environment for any reason, and then be replaced by a new POD. At this time, the POD IP has changed. How can external users correctly access our service?

This is where the service is needed

  • Service can solve the ever-changing POD IP problem
  • A service can expose multiple PODS on a fixed IP address and port

When a service is created, it gets a static IP address that does not change during the service’s lifetime

The client only needs to connect to the service through the fixed IP address, and the service will forward the request to one of the internal PODS. The client does not need to care where the POD is, but only where the service is

Increasing the number of copies

The current system only has one replica, now we can increase it to three

To check the current number of copies, use kubectl get ReplicationControllers

Kubectl scale RC mykubia –replicas=3 can be used to reduce the number of replicas to 3

  • We execute the above instruction, only tell K8S the expected number of copies in the system, but do not tell K8S how to operate, how to achieve

  • K8S itself will check whether the current state is consistent with the expected state, if not, it will adjust, which is one of the basic principles of K8S

Kubectl get XXX: kubectl get XXX: kubectl get XXX

We could have just done kubectl GET to list all possible types of objects and display abbreviations

Latest system status

By executing the above instructions, the system adjusts one copy into three copies

This is why K8S can easily scale horizontally. When we want to scale replicas, we no longer need to manually install and run other replicas, just execute instructions and change the desired number

Of course, the services we put into POD also need to be stateless and scaleable so as to better use the capabilities of K8S

In this case, the latest system should look like this

When an external request is made to a Service, the service sends the request to any POD that provides the service

Today is here, learning, if there is a deviation, please correct

Welcome to like, follow and favorites

Friends, your support and encouragement, I insist on sharing, improve the quality of the power

All right, that’s it for this time

Technology is open, our mentality, should be more open. Embrace change, live in the sun, and strive to move forward.

I am Nezha, welcome to like, see you next time ~