From f4158d642bf398d7ac08851dacb69ecfbed305c0 Mon Sep 17 00:00:00 2001 From: Wen Gao Date: Wed, 23 May 2018 22:56:33 +0800 Subject: [PATCH] Fix typo: exportfs=>exports and offical=>official (#8609) * Fix typo: exportfs=>exports * Typo fix: offical=>official * Revert commit --- .../blog/_posts/2018-05-17-gardener-the-kubernetes-botanist.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/blog/_posts/2018-05-17-gardener-the-kubernetes-botanist.md b/content/en/blog/_posts/2018-05-17-gardener-the-kubernetes-botanist.md index d269ab78e6..b98fe8e8f7 100644 --- a/content/en/blog/_posts/2018-05-17-gardener-the-kubernetes-botanist.md +++ b/content/en/blog/_posts/2018-05-17-gardener-the-kubernetes-botanist.md @@ -92,7 +92,7 @@ One of the first requirements when creating a cluster is a well-prepared infrast ### Machine controller manager -What is required next are the nodes to which the actual workload of a cluster is to be scheduled. However, Kubernetes offers no primitives to request nodes forcing a cluster administrator to use external mechanisms. The considerations include the full lifecycle, beginning with initial provisioning and continuing with providing security fixes, and performing health checks and rolling updates. While we started with instantiating static machines or utilizing instance templates of the cloud providers to create the worker nodes, we concluded (also from our previous production experience with running a cloud platform) that this approach requires extensive effort. During discussions at KubeCon 2017, we recognized that the best way, of course, to manage cluster nodes is to again apply core Kubernetes concepts and to teach the system to self-manage the nodes/machines it runs. For that purpose, we developed the [machine controller manager](https://github.com/gardener/machine-controller-manager) (cf. `[E]`) which extends Kubernetes with `MachineDeployment`, `MachineClass`, `MachineSet` & `Machine` resources and enables declarative management of (virtual) machines from within the Kubernetes context just like `Deployments`, `ReplicaSets` & `Pods`. We reused code from existing Kubernetes controllers and just needed to abstract a few IaaS/cloud provider specific methods for creating, deleting, and listing machines in dedicated drivers. When comparing Pods and Machines a subtle difference becomes evident: creating virtual machines directly results in costs, and if something unforeseen happens, these costs can increase very quickly. To safeguard against such rampage, the machine controller manager comes with a safety controller that terminates orphaned machines and freezes the rollout of MachineDeployments and MachineSets beyond certain thresholds and time-outs. Furthermore, we leverage the existing offical [cluster-autoscaler](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler) already including the complex logic of determining which node pool to scale out or down. Since its cloud provider interface is well-designed, we enabled the autoscaler to directly modify the number of replicas in the respective `MachineDeployment` resource when triggering to scale out or down. +What is required next are the nodes to which the actual workload of a cluster is to be scheduled. However, Kubernetes offers no primitives to request nodes forcing a cluster administrator to use external mechanisms. The considerations include the full lifecycle, beginning with initial provisioning and continuing with providing security fixes, and performing health checks and rolling updates. While we started with instantiating static machines or utilizing instance templates of the cloud providers to create the worker nodes, we concluded (also from our previous production experience with running a cloud platform) that this approach requires extensive effort. During discussions at KubeCon 2017, we recognized that the best way, of course, to manage cluster nodes is to again apply core Kubernetes concepts and to teach the system to self-manage the nodes/machines it runs. For that purpose, we developed the [machine controller manager](https://github.com/gardener/machine-controller-manager) (cf. `[E]`) which extends Kubernetes with `MachineDeployment`, `MachineClass`, `MachineSet` & `Machine` resources and enables declarative management of (virtual) machines from within the Kubernetes context just like `Deployments`, `ReplicaSets` & `Pods`. We reused code from existing Kubernetes controllers and just needed to abstract a few IaaS/cloud provider specific methods for creating, deleting, and listing machines in dedicated drivers. When comparing Pods and Machines a subtle difference becomes evident: creating virtual machines directly results in costs, and if something unforeseen happens, these costs can increase very quickly. To safeguard against such rampage, the machine controller manager comes with a safety controller that terminates orphaned machines and freezes the rollout of MachineDeployments and MachineSets beyond certain thresholds and time-outs. Furthermore, we leverage the existing official [cluster-autoscaler](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler) already including the complex logic of determining which node pool to scale out or down. Since its cloud provider interface is well-designed, we enabled the autoscaler to directly modify the number of replicas in the respective `MachineDeployment` resource when triggering to scale out or down. ### Addons