本文參考自 https://kubernetes.io/docs/tutorials/
The Deployment instructs Kubernetes how to create and update instances of your application. Once you've created a Deployment, the Kubernetes master schedules mentioned application instances onto individual Nodes in the cluster.
Deployment 指示Kubernetes如何創(chuàng)建和更新應(yīng)用程序的實例。一旦創(chuàng)建了部署谜疤，Kubernetes主調(diào)度就會將應(yīng)用程序?qū)嵗岬郊褐械母鱾€節(jié)點上佃延。
Once the application instances are created, a Kubernetes Deployment Controller continuously monitors those instances. If the Node hosting an instance goes down or is deleted, the Deployment controller replaces the instance with an instance on another Node in the cluster. This provides a self-healing mechanism to address machine failure or maintenance.
一旦創(chuàng)建了應(yīng)用程序?qū)嵗琄ubernetes部署控制器就會持續(xù)監(jiān)視這些實例夷磕。如果承載實例的節(jié)點宕機或被刪除履肃，部署控制器將使用集群中另一個節(jié)點上的實例替換該實例。這提供了一種自修復(fù)機制來處理機器故障或維護(hù)坐桩。
When you create a Deployment, you'll need to specify the container image for your application and the number of replicas that you want to run. You can change that information later by updating your Deployment; Modules 5and 6 of the bootcamp discuss how you can scale and update your Deployments.
創(chuàng)建部署時尺棋，需要為應(yīng)用程序指定容器映像和要運行的副本數(shù)量。您可以稍后通過更新部署來更改該信息;bootcamp的模塊5和模塊6討論了如何擴展和更新部署绵跷。
實踐
kubectl create deployment nginx --image=nginx:alpine
kubectl get pods -l app=nginx -o wide
kubectl scale deployment nginx --replicas=5
kubectl expose deployment nginx --port=80 --type=NodePort
Using kubectl to Create a Deployment
Step 1 Create a new service
Let’s verify that our application is running. We’ll use the kubectl get command and look for existing Pods:
kubectl get pods
Next let’s list the current Services from our cluster:
kubectl get services
We have a Service called kubernetes that is created by default when minikube starts the cluster. To create a new service and expose it to external traffic we’ll use the expose command with NodePort as parameter (minikube does not support the LoadBalancer option yet).
kubectl expose deployment/kubernetes-bootcamp --type="NodePort" --port 8080
Let’s run again the get services command:
kubectl get services
We have now a running Service called kubernetes-bootcamp. Here we see that the Service received a unique cluster-IP, an internal port and an external-IP (the IP of the Node).
To find out what port was opened externally (by the NodePort option) we’ll run the describe service command:
kubectl describe services/kubernetes-bootcamp
Create an environment variable called NODE_PORT that has the value of the Node port assigned:
export NODE_PORT=$(kubectl get services/kubernetes-bootcamp -o go-template='{{(index .spec.ports 0).nodePort}}')
echo NODE_PORT=$NODE_PORT
Now we can test that the app is exposed outside of the cluster using curl, the IP of the Node and the externally exposed port:
curl $(minikube ip):$NODE_PORT
And we get a response from the server. The Service is exposed.
Step 2: Using labels
The Deployment created automatically a label for our Pod. With describe deployment command you can see the name of the label:
kubectl describe deployment
Let’s use this label to query our list of Pods. We’ll use the kubectl get pods command with -l as a parameter, followed by the label values:
kubectl get pods -l run=kubernetes-bootcamp
You can do the same to list the existing services:
kubectl get services -l run=kubernetes-bootcamp
Get the name of the Pod and store it in the POD_NAME environment variable:
export POD_NAME=$(kubectl get pods -o go-template --template '{{range .items}}{{.metadata.name}}{{"\n"}}{{end}}')
echo Name of the Pod: $POD_NAME
To apply a new label we use the label command followed by the object type, object name and the new label:
kubectl label pod $POD_NAME app=v1
This will apply a new label to our Pod (we pinned the application version to the Pod), and we can check it with the describe pod command:
kubectl describe pods $POD_NAME
We see here that the label is attached now to our Pod. And we can query now the list of pods using the new label:
kubectl get pods -l app=v1
And we see the Pod.
Step 3 Deleting a service
To delete Services you can use the delete service command. Labels can be used also here:
kubectl delete service -l run=kubernetes-bootcamp
Confirm that the service is gone:
kubectl get services
This confirms that our Service was removed. To confirm that route is not exposed anymore you can curl the previously exposed IP and port:
curl $(minikube ip):$NODE_PORT
This proves that the app is not reachable anymore from outside of the cluster. You can confirm that the app is still running with a curl inside the pod:
kubectl exec -ti $POD_NAME curl localhost:8080
We see here that the application is up.
Scaling Your App
Step 1: Scaling a deployment
To list your deployments use the get deployments command: kubectl get deployments
We should have 1 Pod. If not, run the command again. This shows:
The READY column shows the ratio of CURRENT to DESIRED replicas
CURRENT is the number of replicas running now
DESIRED is the configured number of replicas
The UP-TO-DATE is the number of replicas that were updated to match the desired (configured) state
The AVAILABLE state shows how many replicas are actually AVAILABLE to the users
Next, let’s scale the Deployment to 4 replicas. We’ll use the kubectl scale command, followed by the deployment type, name and desired number of instances:
kubectl scale deployments/kubernetes-bootcamp --replicas=4
To list your Deployments once again, use get deployments:
kubectl get deployments
The change was applied, and we have 4 instances of the application available. Next, let’s check if the number of Pods changed:
kubectl get pods -o wide
There are 4 Pods now, with different IP addresses. The change was registered in the Deployment events log. To check that, use the describe command:
kubectl describe deployments/kubernetes-bootcamp
You can also view in the output of this command that there are 4 replicas now.
Step 2: Load Balancing
Let’s check that the Service is load-balancing the traffic. To find out the exposed IP and Port we can use the describe service as we learned in the previously Module:
kubectl describe services/kubernetes-bootcamp
Create an environment variable called NODE_PORT that has a value as the Node port:
export NODE_PORT=$(kubectl get services/kubernetes-bootcamp -o go-template='{{(index .spec.ports 0).nodePort}}')
echo NODE_PORT=$NODE_PORT
Next, we’ll do a curl to the exposed IP and port. Execute the command multiple times:
curl $(minikube ip):$NODE_PORT
We hit a different Pod with every request. This demonstrates that the load-balancing is working.
Step 3: Scale Down
To scale down the Service to 2 replicas, run again the scale command:
kubectl scale deployments/kubernetes-bootcamp --replicas=2
List the Deployments to check if the change was applied with the get deployments command:
kubectl get deployments
The number of replicas decreased to 2. List the number of Pods, with get pods:
kubectl get pods -o wide
This confirms that 2 Pods were terminated.
Update Your App
Step 1: Update the version of the app
To list your deployments use the get deployments command: kubectl get deployments
To list the running Pods use the get pods command:
kubectl get pods
To view the current image version of the app, run a describe command against the Pods (look at the Image field):
kubectl describe pods
To update the image of the application to version 2, use the set image command, followed by the deployment name and the new image version:
kubectl set image deployments/kubernetes-bootcamp kubernetes-bootcamp=jocatalin/kubernetes-bootcamp:v2
The command notified the Deployment to use a different image for your app and initiated a rolling update. Check the status of the new Pods, and view the old one terminating with the get pods command:
kubectl get pods
Step 2: Verify an update
First, let’s check that the App is running. To find out the exposed IP and Port we can use describe service:
kubectl describe services/kubernetes-bootcamp
Create an environment variable called NODE_PORT that has the value of the Node port assigned:
export NODE_PORT=$(kubectl get services/kubernetes-bootcamp -o go-template='{{(index .spec.ports 0).nodePort}}')
echo NODE_PORT=$NODE_PORT
Next, we’ll do a curl to the the exposed IP and port:
curl $(minikube ip):$NODE_PORT
We hit a different Pod with every request and we see that all Pods are running the latest version (v2).
The update can be confirmed also by running a rollout status command:
kubectl rollout status deployments/kubernetes-bootcamp
To view the current image version of the app, run a describe command against the Pods:
kubectl describe pods
We run now version 2 of the app (look at the Image field)
Step 3: Rollback an update
Let’s perform another update, and deploy image tagged as v10 :
kubectl set image deployments/kubernetes-bootcamp kubernetes-bootcamp=gcr.io/google-samples/kubernetes-bootcamp:v10
Use get deployments to see the status of the deployment:
kubectl get deployments
And something is wrong… We do not have the desired number of Pods available. List the Pods again:
kubectl get pods
A describe command on the Pods should give more insights:
kubectl describe pods
There is no image called v10 in the repository. Let’s roll back to our previously working version. We’ll use the rollout undo command:
kubectl rollout undo deployments/kubernetes-bootcamp
The rollout command reverted the deployment to the previous known state (v2 of the image). Updates are versioned and you can revert to any previously know state of a Deployment. List again the Pods:
kubectl get pods
Four Pods are running. Check again the image deployed on the them:
kubectl describe pods
We see that the deployment is using a stable version of the app (v2). The Rollback was successful.
