Palette strictly follows the above design principles. Putting theory into practice with Palette A more sound approach would be to have the control plane collect the metrics to make the decisions and act, based on the policies that were selected in the clearly-separated management plane. If we are sending all the cluster metrics to the management plane to make decisions, it now becomes mission-critical. It can initiate certain operations by sending the command to the control plane and check the execution status, but it should not play an important role in orchestrating the operation.Ī common mistake to avoid is auto-scaling. It can be used to define the policy and push it to the - more intelligent - control plane for enforcement. To ensure the management plane stays at a non-mission-critical state (as opposed to the control plane), the key design point is to have the management plane stay as passive as possible: it can be a dashboard to display the health status across all clusters and generate alerts if needed. Equally, treat the management plane as the lightweight plane to present to their human operators consolidated options for one or more of the clusters and their administrative tasks or use it to integrate with external APIs and automate. A good architectural approach based on this principle is to always leave the control plane alone to take care of the interactions with its local cluster and data plane, without any error-prone human involvement.
Creating unwanted latency is another risk.īy design, the control plane was intended to enforce the policies that were “decided” using the management plane. However, when managing multiple clusters that each one has its own individual control plane, the two layers need to stay clearly separated, in order to ensure that everything that needs to be cluster-specific is not exposed to the other clusters. But that’s ok since we are not worried about isolating traffic between clusters. When dealing with a single-cluster environment, sometimes the line between Management Plane and Control Plane can be a bit blurry. Management Plane vs Control Plane and why you should “keep em separated” It can be a local dashboard of the Kubernetes cluster or an external management platform that manages the operations of Kubernetes clusters. The management plane, which carries administrative traffic, is considered less mission-critical. If it goes down, although it may not immediately impact the data plane, it will render it out of control, with the application pods not able to be deployed, updated, or relaunched. It is composed of the master nodes and the traffic from the controller in master nodes to each worker node’s kubelet component. The control plane carries signaling traffic. In Kubernetes, you can think of the network between the worker nodes, the ingress controller, and the load balancer, all part of the data plane. This is mission-critical traffic and will immediately impact the user if the plane is unavailable. The logical planes concept can be easily mapped to the Kubernetes architecture and associated management platforms:
0 kommentar(er)
