Skip to main content

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.


Comments

Popular posts from this blog

React JS Basics

  What are side effects in React? In React, side effects are operations that interact with external systems or cause changes outside the component's rendering process. These can include: Data fetching: Retrieving data from APIs or other sources. Subscriptions: Setting up listeners for events or data changes. Timers: Creating timers for delayed actions or animations. DOM manipulation: Directly modifying the DOM (rarely used in modern React with declarative approach). Why use useEffect ? In class-based components, you would typically use lifecycle methods like componentDidMount , componentDidUpdate , and componentWillUnmount to handle side effects. Functional components don't have these methods directly. The useEffect Hook provides a way to manage side effects in functional components. It allows you to run a function after a component renders (or re-renders) and optionally clean up any resources created by that function before the component unmounts. How does useEffect wor...

Difference between SKU and Tenant in multi-tenant SaaS application

SKUs define what you get.  Tenants define who gets it in a securely isolated way. A SaaS provider benefits from SKUs for tiered pricing and multi-tenancy for efficient resource usage.   SKU (Stock Keeping Unit) Features and Pricing: SKUs in a SaaS application typically dictate the set of features, functionalities, and usage limits (e.g., storage, number of users, API call volumes) available to a customer. Customer Choice: Customers choose an SKU based on their needs and budget. Higher-tier SKUs usually offer more capabilities and resources at a higher cost. Within a Tenant: A single tenant (customer) can only be subscribed to one SKU at a time, but may potentially upgrade or downgrade over time. Tenant Data Isolation: A tenant represents a logically isolated instance of the SaaS application dedicated to a specific customer or organization. A customer's data, configurations, and often customizations are kept completely separate from other tenants. Multi-Te...

protobuff vs json

  Protocol Buffers (protobuf) and JSON (JavaScript Object Notation) are both data interchange formats, but they have some key differences in terms of usage, efficiency, and features. Here are some points of comparison: Serialization Format: JSON: It's a human-readable, text-based format. It's easy to read and write for both humans and machines. Protobuf: It's a binary serialization format. While it's not human-readable, it's more compact and efficient for data interchange. Data Types: JSON: Supports a limited set of basic data types, including objects, arrays, strings, numbers, booleans, and null. Protobuf: Supports a broader range of data types, including scalar types (integers, floats, booleans, strings), maps, nested structures, and more. Schema: JSON: Schema is not explicitly defined, which means there is flexibility but less strict validation. Protobuf: Requires a predefined schema (defined in a .proto file). This schema provides a contract for the data s...