This is the 24th day of my participation in the More text Challenge. For more details, see more text Challenge.

How does K8s implement service registration and discovery

We have been talking about how K8s has the capability of service discovery and configuration management, how K8s implements service registration and discovery, and then how K8s achieves service forwarding and load balancing.

In fact, Service in K8s, also defines a resource: Service, Service, as the name implies a Service, what kind of Service? It is a logical collection of multiple Pods that define a service and a strategy for accessing the POD.

There are four types of service:

  • ExternalName: Create a DNS alias pointing to the service name. This can prevent the service name from changing, but it needs to be used with the DNS plug-in.
  • NodePort: Based on ClusterIp, NodePort is used to provide an access port for the Pod behind the Service.
  • LoadBalancer: This is based on NodePort.
  • ClusterIP: specifies the default IP address for Pod access in a cluster. The default IP address is automatically assigned. You can use the ClusterIP keyword to specify a fixed IP address.

From the Service above, we can see a scenario: All microservers are in a LOCAL area network (LAN), or in a K8s cluster, so they can be accessed by pods in the cluster through Service. This is the default type of Service ClusterIP. ClusterIP will automatically assign addresses by default.

So the problem is, since the above ClusterIp to achieve access to services within the cluster, then how to register services? K8s does not introduce any registry, but uses the K8s kube-DNS component. Then, K8s registers the name of the Service as a domain name in kube-DNS. Each Service has a DNS record in Kube-DNS. At the same time, if the IP address of the Service changes, kube-DNS automatically synchronates, and there is no need to change the Service. The name of the Service gives you access to the services it provides. Then again, if there are multiple POD pairs for a service, how do you implement LB? In fact, load balancing is finally achieved through kube-proxy. In other words, kube-DNS finds the specified clusterIP through servicename, and kube-proxy completes the process from clusterIP to PodIP.

There are two types of load balancing policies for a Service:

  • RoundRobin: Polling mode. The polling mode forwards requests to each POD in the back end. This mode is the default mode.
  • SessionAffinity: a session retention mode based on client IP addresses. It is similar to IP Hash to realize service load balancing.

Here’s a very simple example:

apiVersion: v1
kind: Service
metadata:
  name: cas-server-service
  namespace: default
spec:
  ports:
  - name: cas-server01
    port: 2000
    targetPort: cas-server01
  selector:
    app: cas-server
Copy the code

Kubectl apply -f service.yaml

root@ubuntu:~$kubectl get SVC NAME TYPE cluster-ip external-ip PORT(S) AGE admin-web-service ClusterIP 10.16.129.24 < None > 2001/TCP 84d cas-server-service ClusterIP 10.16.230.167 < None > 2000/TCP 67D cloud-admin-service-service ClusterIP 10.16.25.178 < none > 1001 / TCP 190 dCopy the code

In this way, we can see that the default type is ClusterIP, which can be used for Pod access in the cluster, first through the domain name to resolve the service address information, and then through the LB policy to select one of the service address as the request object.

How does K8s handle common configurations in microservices

Let’s look at how most configurations of scenarios in microservices can be managed in a unified manner using K8s. In fact, in K8s, a resource is defined: ConfigMap. Let’s take a look at this resource.

ConfigMap, the name makes sense: it is a key-value pair used to hold configuration information, either a single property or a configuration file. For non-sensitive information, such as application configuration information, you can use ConfigMap.

There are several ways to create a ConfigMap.

  1. Key-value Creates a string
kubectl create configmap test-config --from-literal=baseDir=/usr
Copy the code

The above command creates a key-value pair named test-config with key baseDir and value “/usr”.

  1. Created according to the YML description file
apiVersion: v1
kind: ConfigMap
metadata:
  name: test-config
data:
  baseDir: /usr
Copy the code

Alternatively, create a YML file that configures different information for different environments:

kind: ConfigMap
apiVersion: v1
metadata:
  name: cas-server
data:
  application.yaml: |-
    greeting:
      message: Say Hello to the World
    ---
    spring:
      profiles: dev
    greeting:
      message: Say Hello to the Dev
    spring:
      profiles: test
    greeting:
      message: Say Hello to the Test
    spring:
      profiles: prod
    greeting:
      message: Say Hello to the Prod
Copy the code

Note:

  • ConfigMap must be created before Pod can use it.
  • Pod can only use ConfigMap in the same namespace.

Of course, there are other more USES, specific can consult website (kubernetes. IO/useful/docs/con…

There are several ways to create ConfigMap, one of which is often used in Java: to manage the configuration by creating yML files. Such as:

kind: ConfigMap
apiVersion: v1
metadata:
  name: cas-server
data:
  application.yaml: |-
    greeting:
      message: Say Hello to the World
    ---
    spring:
      profiles: dev
    greeting:
      message: Say Hello to the Dev
    spring:
      profiles: test
    greeting:
      message: Say Hello to the Test
    spring:
      profiles: prod
    greeting:
      message: Say Hello to the Prod
Copy the code

This way, when we start the container, we can get the configuration in ConfigMap by specifying the active environment for the current container by –spring.profiles. Active =dev. Does it feel a bit similar to how Config configures multiple environments in Java? But we don’t have to be that complicated. We can leave it all to K8s. You just need to activate this command, isn’t it simple?