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

This article mainly explains "how to understand Kubernetes-based service mechanism". Interested friends may wish to have a look. The method introduced in this paper is simple, fast and practical. Let's let Xiaobian take you to learn "how to understand Kubernetes-based service mechanism"!

service registration

As a basic infrastructure in RPC/Web services, registration provides the function of storing and being watched metadata of service processes (IP, Port, Interface, Group,Method, etc.). Each service process needs to connect to the same persistent K/V media cluster (such as zookeeper, etcdv3, etc.). Each process needs to store its own metadata in the registry, and be able to Watch for metadata changes (including creation, update, etc.) of other service processes.

Kubernetes

Kubernetes as a container cluster management solution The dimensions of resource management can be subjectively divided into service process management and service interface management. Service process management, mainly embodied in the Pod design mode plus controller mode, the controller ensures that the number of pods with specific labels (Kubernetes-Label) remains constant (more deleted, less supplemented). Service interface management, mainly Kubernetes-Service, which provides VIP (Kubernetes-ClusterIP) for Pods with specific label by default. All requests to request this group of Pods will be forwarded to the Pods that actually provide services according to round-robin load policy. And CoreDNS provides the Kubernetes-Service with a unique domain name within the cluster.

Conflict points between Service and RPC/Web services

The Kubernetes-Service standard resource object has a Service Description field that does not provide the complete service process metadata field. Therefore, Kubernetes-Service cannot be used directly for service registration and discovery.

RPC/Web service registration is on a per-process basis, with each service process requiring a separate registration.

Kubernetes-Service creates VIPs for services by default, and load policies that provide round-robin also conflict with RPC/Web services own load policies.

Discard Service object, select Pod object for registration

Kubernetes-Service conflicts with RPC/Web Services 'existing architecture, resulting in RPC/Web Services having to choose to discard the resource object when choosing service registration and discovery.

RPC/Web Services Since each RPC/Web Services process has been chosen to register independently, RPC/Web Services chooses to write metadata unique to that process to the RPC/Web Services process's Pod in the description of the Pod Resource object in Kubernetes.

Each Pod running RPC/Web Services processes writes metadata about that process to the Kubernetes-Pod Annotations field. In order to avoid conflicts with other fields of Operator or other types of controller (Istio) that use the Annotations field, use base64 encoding after json encoding of the array whose Key is app.io/annotation value is the specific stored K/V pair.

apiVersion: v1kind: Podmetadata: annotations: app.io/annotation: 5LiN55So55yL5LqG5bCx5piv5LiA5Liq5paH5pys5Y2P6K6u

Since each RPC/Web service Pod is only responsible for registering metadata for its own process, the Annotations field does not increase as the number of pods running RPC/Web service processes increases.

service discovery

Having solved the service registration problem, the next thing to solve is the service discovery problem. Kubernetes Api-Server provides Watch functionality to observe changes in various resources within a specific namespace or even the entire cluster. RPC/Web Services To avoid RPC/Web Services processes watching changes to Pods that are unrelated to RPC/Web Services processes, RPC/Web Services limits watch conditions to the namespace in which the current Pod resides and to Pods that watch has app.io/label Value app.io-value. Update the local Cache in real time after watching for changes to the corresponding Pod, and notify the service cluster management built on top of the registry through Subscribe provided by Registry, or other functions.

Work flow

Start RPC/Web service Deployment or other type controller Use Kubernetes Downward-Api to annotate RPC/Web service process with the namespace where this Pod is located as an environment variable.

After the RPC/Web service process Pod is started, the current namespace and the name of the Pod are obtained through environment variables, and the Pod is transferred.

Kubernetes-Akiserver PATCH adds a label with Key app.io/label Value app.io-value to this Pod.

RPC/Web service process calls Kubernetes-Aposerver to write metadata of this process to the Annotations field of the current Pod via PATCH.

RPC/Web service process LIST Other pods with the same label under the current namespace, and decode the corresponding Annotations field to obtain information about other pods.

RPC/Web service process WATCH Annotations field changes for other pods with the same label under the current namespace.

At this point, I believe everyone has a deeper understanding of "how to understand Kubernetes-based service mechanism," so let's actually operate it! Here is the website, more related content can enter the relevant channels for inquiry, pay attention to us, continue to learn!

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.