Practice k8s+flink+hdfs+dlink (4: k8s (2) architecture)

One: Node.

1.1 Why use nodes.

Kubertnetes executes your workload by storing containers in Pods on nodes.
So we need to register the node in advance.

1.2 Definition.

A group of worker machines, called nodes, run containerized applications. Each cluster has at least one worker node.

1.3 How to use node nodes

1.3.1 Add nodes.

  1. The kubelet on the node registers itself with the control panel.
    –register-node is true
    Optional parameters

     --kubeconfig - Path to the credentials used to authenticate to the API server.
     --cloud-provider - A way to communicate with a cloud driver to read metadata about itself.
     --register-node - Automatically register with the API server.
     --register-with-taints - Register nodes with the given list of taints (comma separated <key>=<value>:<effect>). Invalid when register-node is false.
     --node-ip - An optional comma-separated list of node IP addresses. You can specify only one address per address family. For example, in a single-stack IPv4 cluster, this value needs to be set to the node IPv4 address that the kubelet should use. See Configuring IPv4/IPv6 Dual Stack for details on running a dual-stack cluster. If you do not provide this parameter, kubelet will use the node's default IPv4 address (if any); if the node does not have an IPv4 address, kubelet will use the node's default IPv6 address.
     --node-labels - Labels to add when registering a node in the cluster. (See tag restrictions implemented by the NodeRestriction admission control plugin).
     --node-status-update-frequency - Specifies how often the kubelet sends its node status to the API server.
    
  2. Register manually and add a node object.
    –register-node is false
    Optional commands

kubectl cordon $NODENAME
Marking a Node as unschedulable will prevent new Pods from being scheduled to the Node, but will not affect any Pods already on it. This is a useful preparatory step before restarting a node or performing other maintenance operations.

1.3.2 Delete nodes.

  1. Decent closing.
    Trigger the locking mechanism.
    During a graceful node shutdown, kubelet terminates Pods in two stages:

     1. Terminate regular Pods running on the node.
     2. Terminate critical Pods running on the node.
    

The feature of node graceful shutdown corresponds to two KubeletConfiguration options:

shutdownGracePeriod:
Specifies the total duration for which the node should delay shutdown. This time is the sum of the times for Pods to terminate gracefully, without distinguishing between regular Pods and critical Pods.
shutdownGracePeriodCriticalPods:
Specifies the duration for terminating critical Pods during node shutdown. This value should be less than shutdownGracePeriod.
  1. Unseemly closure.
    1. The locking mechanism will not be triggered. If you do not set the above two parameters, the default value of 0 will not be maintained, which is an unseemly relationship.
    2. There is a problem with being unseemly. When some nodes are shut down and the kubelet system does not detect this event, the pods in statefulset on the shut down nodes will remain in the terminated state. Therefore, the pod cannot be deleted, nor can a new pod with the same name be created.
      In order to solve the above problem. Users can manually add the node.kubernetes.io/out-of-service taint with the NoExecute or NoSchedule effect to a node to mark it as unable to provide services. If the NodeOutOfServiceVolumeDetach feature gate is enabled on kube-controller-manager, and the node is marked as unable to provide services through taint, and if the corresponding tolerance is not set on the node Pod, then such Pod will be forcibly deleted, and the node will Pods that are terminated will immediately undergo volume detachment. This allows pods on nodes that are unable to provide services to be quickly restored on other nodes.

During an ungraceful shutdown, a Pod is terminated in two phases:

1. Forcefully delete Pods that do not have matching out-of-service tolerance.
2. Immediately perform the detach volume operation on such Pods.

1.3.3 Modify nodes.

  1. Re-register the node.
  2. Swap memory management.
    1. turn on
memorySwap:
  swapBehavior: UnlimitedSwap
 2.Close
memorySwap:
  swapBehavior: LimitedSwap
  nodeTotalMemory: The total amount of physical memory available on the node.
  totalPodsSwapAvailable: The total amount of swap memory available to Pods on the node (some swap memory may be reserved for system use).
  containerMemoryRequest: container memory request.

1.3.4 View nodes.

  1. state

    1. kubectl describe node
      The status of a node contains the following information:
      Addresses
      Condition
      Capacity and allocability (Capacity)
      Information
  2. heartbeat
    The heartbeats sent by Kubernetes nodes help your cluster determine the availability of each node and take action when a failure is detected. For nodes, there are two forms of heartbeats:

    1. Update the node’s .status
    2. Lease objects in the kube-node-lease namespace. Each node has an associated Lease object.

Two: Communication between nodes and control plane.

  1. node to the control plane.
    When a Pod is instantiated, Kubernetes automatically injects the public root certificate and a valid bearer token into the Pod. The kubernetes service (located in the default namespace) is configured with a virtual IP address that is used to forward requests (via kube-proxy) to the HTTPS endpoint of the API server.
  2. Control plane to kubelet, node, pod.
    1. Control plane access kubelet.
      1. Reason for visit.
        1. Get pod logs.
        2. Mount a running pod (via kubelet)
        3. Forwarding function through kubelet’s interface.
      2. interview method.
        The –kubelet-certificate-authority flag provides the API server with a root certificate bundle for the kubelet’s service certificate.
    2. Control plane access node, pod.
      Using http, although the connection is encrypted, does not provide any integrity guarantee.

Three: Controller.

  1. What is a controller.
    The object status changes to spec status and needs to be adjusted.
    There are many kinds of controllers.
    1. job controller.
      When the Job controller gets a new task, it ensures that the kubelet on a set of Node nodes can run the correct number of Pods to complete the work. The Job controller will not run any Pods or containers on its own. The Job controller notifies the API server to create or remove Pods. Other components in the control plane react to new messages (scheduling and running new Pods) and ultimately complete the work.
    2. Etc., such as direct controller, custom controller.

Four: Lease.

  1. What is it?
    Leases provide a mechanism to lock shared resources and coordinate activity among collection members. In Kubernetes, the lease concept is represented as the Lease object in the coordination.k8s.io API group, which is commonly used for core system capabilities such as node heartbeats and component-level leader election.

  2. how to use?
    Starting with Kubernetes v1.26, each kube-apiserver uses the Lease API to publish its identity to other locations in the system. While not particularly useful on its own, it provides a mechanism for clients to discover how many kube-apiserver instances are operating the Kubernetes control plane. The existence of kube-apiserver leases allows new capabilities to be coordinated across kube-apiserver in the future.