Kubernetes was built to run distributed clusters. The nature of distributed systems makes networking a core and necessary part of Kubernetes. Understanding the Kubernetes networking model enables you to run, monitor, and troubleshoot applications correctly.

1. The core components of Kubernetes

1. Master component

1.1 for api server

Used to expose the kubernetes API, any resource request or call operation is performed through the interface provided by the kube-api server.
The interface service is provided by the HTTP Restful API. The addition, deletion, modification, query and monitoring operations of all object resources are handed over to the API Server for processing and then submitted to Etcd for storage.
It can be understood that API Server is the request entry service of K8S. API Server is responsible for receiving all K8S requests (from the UI interface or CLI command line tool), and then notifies other components to work according to the user's specific request. It can be said that the API Server is the brain of the K8S cluster architecture.

1.2 Kube-controller-manager

Operation management control is the background thread for processing routine tasks in the K8S cluster, and it is the automatic control center for all resource objects in the K8S cluster.
In a K8S cluster, a resource corresponds to a controller, and the Controller manager is responsible for managing these controllers. Consists of a series of controllers, monitors the status of the entire cluster through the API Server, and ensures that the cluster is in the expected working state. For example, when a Node goes down unexpectedly, the Controller Manager will find out in time and perform an automatic repair process to ensure that the cluster is always in expected working condition.

controller	illustrate
Node Controller	Responsible for discovering and responding when nodes fail
Replication Controller (replication controller)	Responsible for ensuring that the number of Pod copies associated with an RC (resource object Replication Controller) in the cluster always maintains the preset value. It can be understood as ensuring that there are only N Pod instances in the cluster, and N is the number of Pod copies defined in RC
Endpoints Controller	Populate the endpoint object (that is, connect Services and Pods), which is responsible for monitoring the changes of the Service and the corresponding Pod copy. It can be understood that an endpoint is an access point exposed by a service. If you need to access an access point exposed by a service, if you need to access a service, you must know its endpoint
Service Account & Token Controllers (service account and token controller)	Create default accounts and API access tokens for new namespaces
ResourceQuota Controller (Resource Quota Controller)	Ensure that the specified resource object does not over-occupy system physical resources at any time
Namespace Controller	Manage the life cycle of namespace
Service Controller	Belongs to an interface controller between the K8S cluster and the external cloud platform

1.3 kube-scheduler

It is the process responsible for resource scheduling, and selects a suitable Node node for the newly created Pod according to the scheduling algorithm. It can be understood as the scheduler of all Node nodes of K8S. When used to deploy a service, the Scheduler will select the most appropriate Node node to deploy the Pod according to the scheduling algorithm.

Budget strategy (predicate)
preference strategy (priorities)

1.4 Configure Storage Center—etcd

The K8S storage service is responsible for storing important information of the K8S cluster. etcd is a distributed key-value storage system that stores key configurations and user configurations of K8S. Only the API Server in K8S has read and write permissions, and other components must pass the interface of the API Server to read and write data

1.5 Masternode Workflow

API Server receives a request to create a batch of Pods, API Server will let Controller-manager create Pods according to the preset template, Controller-manager will go to Scheduler to select the most suitable Node node for the newly created Pods through API Server. For example, running this Pod requires 2C4G resources, and Schedule will select the optimal one among all Node nodes through the budget strategy. How many resources are left in the Node node is stored in etcd by reporting to the API Server, and the API Server will call a method to find the remaining resources of all Node nodes in etcd, and then compare the resources required by the Pod to find out which Node nodes are in all Node nodes The node meets the requirements. If they all match, the budget strategy will be handed over to the optimal strategy. The optimal strategy will then select the most suitable Node node based on factors such as the CPU load and the remaining amount of memory, and schedule the Pod to run on this Node node.

2. Node components

2.1 Kubelet

The monitor of the Node node and the communicator with the master node. Kubelet is the "eyeliner" placed by the master node on the node node. It will regularly report the service status running on its own Node node to the API server, and accept instructions from the master node to take adjustment measures.

Obtain the desired state of Pods on your own node from the Master node (such as what containers to run, the number of replicas to run, how to configure the network or storage, etc.), and directly interact with the container engine to implement container life cycle management. If the expected state is inconsistent, call the corresponding container platform interface (that is, the docker interface) to achieve this state. Manage the cleaning of images and containers to ensure that the images on the nodes do not take up disk space, and the exited containers do not take up too many resources.

2.2 By Proxy

① Implement the Pod network agent on each Node node, which is the carrier of Kubernetes Service resources and is responsible for maintaining network planning and four-layer load balancing. Responsible for writing rules to iptables and ipvs to implement service mapping access.
② Kube-Proxy itself does not directly provide the network to the Pod. The Pod network is provided by Kubelet. Kube-Proxy actually maintains a virtual Pod cluster network.
③ Kube-api server updates Kubernetes Service and maintains endpoints by monitoring Kube-Proxy.
④ Kube-Proxy is the load balancer inside the K8S cluster. It is a distributed proxy server that runs a Kube-proxy on each node of K8S.

2.3 docker or rocket

The container engine runs the container and is responsible for the creation and management of the local container.

Kubelet is responsible for the management of the entire process, and the container engine is used for work

2. The core concept of Kubernetes

① Kubernetes contains multiple types of resource objects: Pod, Label, Service, Replication Controller, etc.
② All resource objects can be added, deleted, modified, checked, etc. through the kubectl tool provided by Kubernetes, and stored in etcd for persistent storage.
③ Kubernetes is actually a highly automated resource control system. By tracking and comparing the difference between the expected state of resources stored in etcd storage and the actual resource state in the current environment, advanced functions such as automatic control and automatic error correction are realized.

1、Pod

Pod is the smallest/simplest basic unit created or deployed by Kuberntes, and a Pod represents a running process on the cluster.
Pods can be understood as pea pods, and each container in the same Pod is a pea.
A Pod consists of one or more containers. The containers in the Pod share network, storage and computing resources and run on the same Docker host.
Multiple containers can run in a Pod, also known as the sidecar (SideCar) mode. In a production environment, a Pod is generally composed of a single container or multiple containers with strong associations and complementarities.
Containers in the same Pod can access each other through localhost, and can mount all data volumes in the Pod; however, containers between different Pods cannot use localhost to access, nor can they mount data volumes in other Pods.

2. Pod controller

Pod controller is a template for Pod startup, which is used to ensure that Pods started in K8S should always run according to user expectations (number of copies, life cycle, health status check, etc.). There are many Pod controllers provided in K8S, and the commonly used ones are as follows:

Deployment: Stateless application deployment . The role of Deployment is to manage and control Pod and ReplicaSet, and control them to run in the state expected by the user.
Replicaset: Ensuring the expected number of Pod replicas. The role of ReplicaSet is to manage and control Pods , and control them to work well. But ReplicaSet is controlled by Deployment. It can be understood that the Deployment is the general contractor, mainly responsible for supervising the work of the worker Pods under it, and ensuring that the number of Pods required by the user is working at all times. If it is found that a worker Pod is not working, quickly pull a new Pod to replace it. And ReplicaSet is the small contractor under the general contractor. From the perspective of K8S users, the user will directly operate the Deployment deployment service, and when the Deployment is deployed, K8S will automatically generate the required ReplicaSet and Pod. Users only need to care about Deployment and not ReplicaSet. The resource object Replication Controller is the predecessor of ReplicaSet. It is officially recommended to use Deployment instead of Replication Controller to deploy services.
Daemonset: Ensure that all nodes run the same type of Pod, and ensure that there is one such Pod running on each node. It is usually used to implement system-level background tasks.
Statefulset: Stateful application deployment.
**Job: One-time task. **According to the user's settings, the Pod managed by the Job will automatically exit after the task is successfully completed.
Cronjob: periodic scheduled tasks.
Ingress: manage the network mode of L7 layer (http/https traffic)
ingress includes: nginx, Haproxy, traffic, istio, kong
PV/PVC: dynamic storage. When NFS is connected to k8s, it cannot be directly mounted, but should be managed by pv/pvc. Shared storage is also a resource, which is managed by pv/pvc. For example, 10G is not enough, and the capacity expansion is dynamically expanded by pv/pvc.

2.1 Deployment—stateless application deployment

For this type of service of Nginx, when only the reverse proxy function is enabled, assuming that nginx is down, run a new one and replace it, which can be used directly. No differentiation is called stateless .

Stateless service: LVS (after joining the cluster, there is no special requirement—requirement)

The service does not depend on its own state, and the state data of the instance can be maintained in memory
Any request can be handled by any instance
No state data is stored, the instance can be expanded horizontally, and requests are distributed to each node through load balancing
In a closed system, there is only one data loop
Typically found in monolithic clusters

2.2 Statefulset—stateful application deployment

Mysql is running in it, mysql is down, and the configuration is the same, so it cannot be used directly. The data is different. After joining the cluster, it meets specific rules and rules for storing data before it can be used. Differentiation is called stateful .

Stateful services: such as databases
with special state requirements, such as persistence and specific data support

The service itself relies on or has local state data, which needs to be persisted by itself or can be restored by other nodes.
A request can only be processed by a certain node (or a node in an equivalent state).
Storing state data, instance expansion requires the entire system to participate in state migration.
In a closed system, there are multiple data closed loops, and the data consistency issues of these closed loops need to be considered.
Typically present in distributed architectures.

2.3 Summary

Stateless service : It is a service without a special state. Each request is processed uniformly and indiscriminately for the server. The request itself carries all the parameters required by the server (the server itself does not store any data related to the request, excluding the database. store information).
Stateful services : In contrast, stateful services retain previously requested information on the server side to process current requests, such as sessions.

simplify

有状态：需要持久化，多次请求之间需要共享一些信息
无状态：一次性，不需要持久化的特殊状态，每次请求都是一条新的数据

For docker, it is more suitable to apply stateless services, and kubernetes provides a solution ----"multiple storage types-
"for example

configmap (configuration management center), mainly stores configuration files
PS: configmap is an independent resource, similar to docker run -itd -v /nginx conf:/usr/nginx/conf nginx:1.21 /bin/bash

Write nginx.conf----> into a nginx-confimap.yaml file
and associate nginx---->pod nginx.yaml with the same label: label=nginx

Secret: user password, file to be encrypted
mysql-secrets.yml encrypted configuration file (account password) and mysql.yaml are associated together through labels
volume: basic data (webpage file), docker run -itd -v /nginx_html: /usr/local/nginx/html/nginx:1.21 /bin/bash

PV/PVC: dynamic creation process

3. Label label

Tags are a characteristic management method of K8S , which facilitates the classification and management of resource objects. Label can be attached to various resource objects, such as Node, Pod, Service, RC, etc., for associating objects, querying and filtering.
A Label is a key-value pair, where the key and value are specified by the user.
A resource object can define any number of Labels, and the same Label can also be added to any number of resource objects, and can also be dynamically added or deleted after the object is created.
The multi-dimensional resource group management function can be realized by binding one or more different Labels to the specified resource object.
Similar to Label, there is also Annotation (note). The difference is that a valid tag value must be 63 characters or less and must be empty or start and end with alphanumeric characters ([a-z0-9A-Z]) and can contain dashes (-), underscores ( _), dot (.), and letters or numbers. There is no character length limit for comment values.

4. Label selector

Defining a Label for a resource object is equivalent to labeling it
Then you can query and filter resource objects with certain Labels through the Label selector.

There are currently two types of label selectors:

Based on equivalence relationships (equal to, not equal to)
Based on set relationships (belongs to, does not belong to, exists)

5、Service

In the K8S cluster, although each Pod will be assigned a separate IP address, since Pods have a life cycle (they can be created and will not be restarted after being destroyed), they may change at any time due to business changes. As a result, this IP address will also disappear with the destruction of the Pod. Service is the core concept used to solve this problem.

Service in K8S does not mean "service" as we often say, but more like a gateway layer, which can be regarded as a group of external access interfaces and traffic balancers for Pods that provide the same service.

Which Pods a Service applies to is defined by label selectors.
In a K8S cluster, a Service can be regarded as an external access interface for a group of Pods that provide the same service . The service that the client needs to access is the Service object. Each Service has a fixed virtual IP (this IP is also called Cluster IP), which is automatically and dynamically bound to the back-end Pod. All network requests directly access the virtual IP of the Service, and the Service will automatically forward it to the back-end .

In addition to providing a stable external access method, Service can also function as a load balance (Load Balance) , automatically dividing request traffic from all backend services, and Service can transparently expand horizontally to customers ( scale). The key to realize the function of service is kube-proxy. kube-proxy runs on each node,

To monitor the changes of service objects in the API Server, network forwarding can be realized through the following three traffic scheduling modes: userspace (abandoned), iptables (on the verge of being abandoned), and ipvs (recommended, with the best performance).

**Service is the core of K8S services. It shields service details and uniformly exposes service interfaces to the outside world, truly achieving "microservices".

Creating a service requires ServiceController, EndpointControllre, kube-proxy, and three modules to cooperate at the same time.

ServiceController is the rule that controls the service to create the corresponding Pod association
EndpointController is the specific location to define the backend pod, that is, endpoint (upstream + automatic discovery and update of consul)
kube-proxy is used to define specific back-end forwarding and shunting rules.
The above constitutes the necessary functions of a service.

5.1 ServiceController

When the status of a service object changes, the informer will notify the ServiceController to create the corresponding service.

5.2 EndpointController

EndpointController will subscribe to both service and pod addition and deletion events.
EndpointController is regarded as the discovery and update in upstream + consyul of nginx

Its function is as follows

The controller responsible for generating and maintaining all endpoint objects
Responsible for monitoring service and corresponding pod changes
When the service is detected to be deleted, delete the endpoint object with the same name as the service
After listening to the creation of a new service, obtain the relevant pod list according to the newly created service information (YAML), and then create the corresponding endpoint object
After monitoring that the service is updated, obtain the relevant pod list according to the updated service information, and then update the corresponding endpoint object
When a pod event is detected, the corresponding service and endpoint objects are updated, and the podIP is recorded in the endpoint

5.3 to proxy

kube-proxy is responsible for service implementation, realizing the access of k8s internal service and external node port to service.
kube-proxy uses iptables to configure load balancing . The main responsibilities of iptables-based kube-proxy include two parts: one is to listen to service update events and update service-related iptables rules, and the other is to listen to endpoint update events and update endpoints. Relevant iptables rules (such as the rules in the kube-svc chain), and then transfer the packet request to the pod corresponding to the endpoint.

6、Ingress

Service is mainly responsible for the network topology inside the K8S cluster , so how can the outside of the cluster access the inside of the cluster? Ingress is needed at this time. Ingress is the access layer of the entire K8S cluster and is responsible for communication inside and outside the cluster.

Ingress is the application layer of layer 7 in the K8S cluster working under the OSI network reference model. It is an exposed interface. The typical access method is http/https.
Service can only perform traffic scheduling on the fourth layer , and the form of expression is ip+port. Ingress can schedule business traffic of different business domains and different URL access paths.
For example: client requests http://www.test.com:port --> Ingress --> Service --> Pod

7、Name

Since K8S uses "resources" to define each logical concept (function), each "resource" should have its own "name".
"Resources" include api version (apiversion), category (kind), metadata (metadata), definition list (spec), status (status) and other configuration information.
"Name" is usually defined in the "metadata" information of "resource". Must be unique within the same namespace .

8、Namespace

With the increase of projects, personnel, and cluster scale, a method that can logically isolate various "resources" in K8S is needed, which is Namespace.
Namespace was born to divide a K8S cluster into several virtual cluster groups whose resources cannot be shared.
The names of "resources" in different Namespaces can be the same, and the "names" of various "resources" in the same Namespace cannot be the same.
Reasonable use of K8S Namespace can enable cluster administrators to better classify, manage and browse services delivered to K8S.
The default namespaces in K8S are: ==default, kube-system, kube-public ==, etc.
To query specific "resources" in K8S, you need to bring the corresponding Namespace.

kubernetes core components

foreword