whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Fix typo: exportfs=>exports and offical=>official (#8609)

Browse Source 
* Fix typo: exportfs=>exports

* Typo fix: offical=>official

* Revert commit
This commit is contained in:
Wen Gao
2018-05-23 22:56:33 +08:00
committed by k8s-ci-robot
parent 2bae676e0c
commit f4158d642b
1 changed files with 1 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/en/blog/_posts/2018-05-17-gardener-the-kubernetes-botanist.md
+1 -1
View File
@@ -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