- Follow the steps described here
- Make sure that the
kubernetes/machine-deployment.yaml
points to the same class name as thekubernetes/aws-machine-class.yaml
. - Similarily
kubernetes/aws-machine-class.yaml
secret name and namespace should be same as that mentioned inkubernetes/aws-secret.yaml
- Modify
kubernetes/machine-deployment.yaml
as per your requirement. Modify the number of replicas to the desired number of machines. Then, create an machine-deployment
$ kubectl apply -f kubernetes/machine-deployment.yaml
Now the Machine Controller Manager picks up the manifest immediately and starts to create a new machines based on the number of replicas you have provided in the manifest.
- Check Machine Controller Manager machine-deployments in the cluster
$ kubectl get machinedeployment
NAME KIND
test-machine-deployment MachineDeployment.v1alpha1.machine.sapcloud.io
You will notice a new machine-deployment with your given name
- Check Machine Controller Manager machine-sets in the cluster
$ kubectl get machineset
NAME KIND
test-machine-deployment-5bc6dd7c8f MachineSet.v1alpha1.machine.sapcloud.io
You will notice a new machine-set backing your machine-deployment
- Check Machine Controller Manager machines in the cluster
$ kubectl get machine
NAME KIND
test-machine-deployment-5bc6dd7c8f-5d24b Machine.v1alpha1.machine.sapcloud.io
test-machine-deployment-5bc6dd7c8f-6mpn4 Machine.v1alpha1.machine.sapcloud.io
test-machine-deployment-5bc6dd7c8f-dpt2q Machine.v1alpha1.machine.sapcloud.io
Now you will notice N (number of replicas specified in the manifest) new machines whose name are prefixed with the machine-deployment object name that you created.
- After a few minutes (~3 minutes for AWS), you would see that new nodes have joined the cluster. You can see this using
$ kubectl get nodes
NAME STATUS AGE VERSION
ip-10-250-20-19.eu-west-1.compute.internal Ready 1m v1.8.0
ip-10-250-27-123.eu-west-1.compute.internal Ready 1m v1.8.0
ip-10-250-31-80.eu-west-1.compute.internal Ready 1m v1.8.0
This shows how new nodes have joined your cluster
To inspect the status of any created machine-deployment run the command below,
$ kubectl get machinedeployment test-machine-deployment -o yaml
apiVersion: machine.sapcloud.io/v1alpha1
kind: MachineDeployment
metadata:
annotations:
deployment.kubernetes.io/revision: "1"
kubectl.kubernetes.io/last-applied-configuration: |
{"apiVersion":"machine.sapcloud.io/v1alpha1","kind":"MachineDeployment","metadata":{"annotations":{},"name":"test-machine-deployment","namespace":""},"spec":{"minReadySeconds":200,"replicas":3,"selector":{"matchLabels":{"test-label":"test-label"}},"strategy":{"rollingUpdate":{"maxSurge":1,"maxUnavailable":1},"type":"RollingUpdate"},"template":{"metadata":{"labels":{"test-label":"test-label"}},"spec":{"class":{"kind":"AWSMachineClass","name":"test-aws"}}}}}
clusterName: ""
creationTimestamp: 2017-12-27T08:55:56Z
generation: 0
initializers: null
name: test-machine-deployment
namespace: ""
resourceVersion: "12634168"
selfLink: /apis/machine.sapcloud.io/v1alpha1/test-machine-deployment
uid: c0b488f7-eae3-11e7-a6c0-828f843e4186
spec:
minReadySeconds: 200
replicas: 3
selector:
matchLabels:
test-label: test-label
strategy:
rollingUpdate:
maxSurge: 1
maxUnavailable: 1
type: RollingUpdate
template:
metadata:
creationTimestamp: null
labels:
test-label: test-label
spec:
class:
kind: AWSMachineClass
name: test-aws
status:
availableReplicas: 3
conditions:
- lastTransitionTime: 2017-12-27T08:57:22Z
lastUpdateTime: 2017-12-27T08:57:22Z
message: Deployment has minimum availability.
reason: MinimumReplicasAvailable
status: "True"
type: Available
readyReplicas: 3
replicas: 3
updatedReplicas: 3
Health monitor is also applied similar to how it's described for machine-sets
Let us consider the scenario where you wish to update all nodes of your cluster from t2.xlarge machines to m4.xlarge machines. Assume that your current test-aws has its spec.machineType: t2.xlarge and your deployment test-machine-deployment points to this AWSMachineClass.
- Check Nodes present in the cluster
$ kubectl get nodes
NAME STATUS AGE VERSION
ip-10-250-20-19.eu-west-1.compute.internal Ready 1m v1.8.0
ip-10-250-27-123.eu-west-1.compute.internal Ready 1m v1.8.0
ip-10-250-31-80.eu-west-1.compute.internal Ready 1m v1.8.0
- Check Machine Controller Manager machine-sets in the cluster. You will notice one machine-set backing your machine-deployment
$ kubectl get machineset
NAME KIND
test-machine-deployment-5bc6dd7c8f MachineSet.v1alpha1.machine.sapcloud.io
- Login to your cloud provider (AWS). In the VM management console, you will find N VMs created of type t2.xlarge.
To update this machine-deployment VMs to m4.xlarge, we would do the following:
- Copy your existing aws-machine-class.yaml
$ cp kubernetes/aws-machine-class.yaml kubernetes/aws-machine-class-new.yaml
- Modify aws-machine-class-new.yaml, and update its metadata.name: test-aws2 and spec.machineType: m4.xlarge
- Now create this modified MachineClass
$ kubectl apply -f kubernetes/aws-machine-class-new.yaml
- Edit your existing machine-deployment
$ kubectl edit machinedeployment test-machine-deployment
- Update from spec.template.spec.class.name: test-aws to spec.template.spec.class.name: test-aws2
After a few minutes (~ 3mins)
- Check nodes present in cluster now. They are different nodes.
kubectl get nodes
NAME STATUS AGE VERSION
ip-10-250-11-171.eu-west-1.compute.internal Ready 4m v1.8.0
ip-10-250-17-213.eu-west-1.compute.internal Ready 5m v1.8.0
ip-10-250-31-81.eu-west-1.compute.internal Ready 5m v1.8.0
- Check Machine Controller Manager machine-sets in the cluster. You will notice two machine-sets backing your machine-deployment
$ kubectl get machineset
NAME KIND
test-machine-deployment-5bc6dd7c8f MachineSet.v1alpha1.machine.sapcloud.io
test-machine-deployment-86ff45cc5 MachineSet.v1alpha1.machine.sapcloud.io
- Login to your cloud provider (AWS). In the VM management console, you will find N VMs created of type t2.xlarge in terminated state, and N new VMs of type m4.xlarge in running state.
This shows how a rolling update of a cluster from nodes with t2.xlarge to m4.xlarge went through.
- The above demonstration was a simple use case. This could be more complex like - updating the system disk image versions/ kubelet versions/ security patches etc.
- You can also play around with the maxSurge and maxUnavailable fields in machine-deployment.yaml
- You can also change the update strategy from rollingupdate to recreate
- Edit the existing machine-deployment
$ kubectl edit machinedeployment test-machine-deployment
- Edit the deployment to have this new field of spec.rollbackTo.revision: 0 as shown as comments in
kubernetes/machine-deployment.yaml
- This will undo your update to the previous version.
- You can also pause the update while update is going on by editing the existing machine-deployment
$ kubectl edit machinedeployment test-machine-deployment
-
Edit the deployment to have this new field of spec.paused: true as shown as comments in
kubernetes/machine-deployment.yaml
-
This will pause the rollingUpdate if it's in process
-
To resume the update, edit the deployment as mentioned above and remove the field spec.paused: true updated earlier
- To delete the VM using the
kubernetes/machine-deployment.yaml
$ kubectl delete -f kubernetes/machine-deployment.yaml
The Machine Controller Manager picks up the manifest and starts to delete the existing VMs by talking to the cloud provider. The nodes should be detached from the cluster in a few minutes (~1min for AWS).