ctechbits: Control plane and Data plane

OCI Network Planes:

Management Plane

The management plane consists of the components that make up the Oracle Cloud Native Environment platform, that is, the Platform API Server, the Platform Agent, and the Platform CLI.

Communication between the components is secured using Transport Layer Security (TLS). You can configure the cipher suites to use for TLS for the management plane.

You can set up the X.509 certificates used for TLS before you create environment, or have a certificate management application, such as Vault, manage these for you.

Control Plane

The control plane contains the Kubernetes components and any load balancer.

Kubernetes has a sophisticated networking model with many options that allow users to finely tune the networking configuration. Oracle Cloud Native Environment simplifies the Kubernetes networking by setting network defaults that align closely with community best practices.

By default, all Kubernetes services are bound to the network interface that handles the default route for the system. The default route is set to the network interface used by the Platform Agent, and it is used for both the Kubernetes control plane and the data plane.

There are two motivations behind this choice. The first is that the Platform API Server always needs to be able to communicate with the Kubernetes API server. By making sure the Kubernetes API server is bound to the same interface as the Platform Agent, this condition is always met. Also, if nodes have multiple network interfaces, it will usually be the case that the sensitive networks are not the networks that Oracle Cloud Native Environment is using to communicate.

When deploying a highly available cluster having multiple control plane nodes with an internal load balancer, the Platform API Server uses the same network interface as was set to host the Kubernetes control plane services to host the virtual IP address.

Data Plane

The data plane is the network used by the pods running on Kubernetes.

The same algorithm for determining the default control plane interface is used when instantiating the Kubernetes pod network. That is, the network interface used by the Platform Agent is used for both the Kubernetes control plane and the data plane. In multi-network environments, this may not be the best choice. Oracle Cloud Native Environment allows you to customize the network interface used for pod networking when you create the Kubernetes module. When Flannel is brought up, it uses the network interface you specify for the pod network.

In the case of OCI Functions:

• The control plane is a set of components that manages function definitions.
• The data plane is a set of components that executes functions in response to invocation requests.

For resiliency and high availability, both the control plane and data plane components are distributed across different availability domains and fault domains in a region. If one of the domains ceases to be available, the components in the remaining domains take over to ensure that function definition management and execution are not disrupted.

Reference: https://docs.oracle.com/en-us/iaas/Content/Functions/Concepts/functionsavailability.htm

Kubernetes Control Plane

The control plane is the brain of Kubernetes. It consists of various components that, together, make global decisions about the cluster. The control plane components run on multiple servers across availability zones to provide high availability. The core components of the Kubernetes control plane include:

• 
  

  1. Kubernetes API Server:

      Role: Acts as the front end for the Kubernetes control plane. It exposes the Kubernetes API, which is used to interact with the cluster.

      Functionality: Validates and configures data for the API objects (such as Pods, Services, Deployments), enforces policies, and initiates updates to objects. All administrative tasks and user commands are handled by communicating with the API server.

  
  

  2. etcd:

     Role: A distributed key-value store that stores the configuration data of the Kubernetes cluster.

     Functionality: Maintains the state of the entire cluster. It stores configuration details, such as cluster state, configuration details, and metadata. The high availability and consistency of etcd are crucial for the overall reliability of the Kubernetes control plane.

  
  

  3. Kubernetes Controller Manager:

     Role: Runs controller processes, each responsible for managing a specific aspect of the cluster's state.

     Functionality: Monitors the state of the cluster through the API server and works to reconcile the current state with the desired state. Examples of controllers include the Replication Controller (ensuring the specified number of replicas for a Pod) and the Node Controller (detecting and responding when nodes go down).

  
  

  4. Kubernetes Scheduler:

     Role: Assigns Pods to nodes in the cluster.

     Functionality: Monitors for newly created Pods with no assigned node and selects an appropriate node for them to run on based on factors such as resource requirements, affinity and anti-affinity rules, and other constraints. The scheduler then binds the Pod to the chosen node.

  
  

  These components collectively form the control plane, and they are distributed across multiple nodes in the cluster to ensure high availability. The control plane components work together to maintain the desired state of the cluster, respond to changes, and ensure the proper functioning and scalability of the Kubernetes environment.