From 2ef03fabd6ff1bc1a76902584e351e48fea6c5bd Mon Sep 17 00:00:00 2001 From: Phillip Wittrock Date: Wed, 23 Mar 2016 17:21:04 -0700 Subject: [PATCH] Update hello-node example to use deployments --- docs/hellonode.md | 144 +++++++++++++++++++++++++++------------------- 1 file changed, 85 insertions(+), 59 deletions(-) diff --git a/docs/hellonode.md b/docs/hellonode.md index 46097a58cb..1a72dccfe0 100755 --- a/docs/hellonode.md +++ b/docs/hellonode.md @@ -83,14 +83,14 @@ Now there is a trusted source for getting an image of your containerized app. Let's try your image out with Docker: ```shell -docker run -d -p 8080:8080 gcr.io/PROJECT_ID/hello-node:v1 +$ docker run -d -p 8080:8080 gcr.io/PROJECT_ID/hello-node:v1 325301e6b2bffd1d0049c621866831316d653c0b25a496d04ce0ec6854cb7998 ``` Visit your app in the browser, or use `curl` or `wget` if you’d like : ```shell -curl http://localhost:8080 +$ curl http://localhost:8080 Hello World! ``` @@ -108,7 +108,7 @@ $ docker stop 2c66d0efcbd4 Now that the image works as intended and is all tagged with your `PROJECT_ID`, we can push it to the [Google Container Registry](https://cloud.google.com/tools/container-registry/), a private repository for your Docker images accessible from every Google Cloud project (but also from outside Google Cloud Platform) : ```shell -gcloud docker push gcr.io/PROJECT_ID/hello-node:v1 +$ gcloud docker push gcr.io/PROJECT_ID/hello-node:v1 ``` If all goes well, you should be able to see the container image listed in the console: *Compute > Container Engine > Container Registry*. We now have a project-wide Docker image available which Kubernetes can access and orchestrate. @@ -133,73 +133,113 @@ A kubernetes **pod** is a group of containers, tied together for the purposes of Create a pod with the `kubectl run` command: ```shell -kubectl run hello-node \ +$ kubectl run hello-node \ --image=gcr.io/PROJECT_ID/hello-node:v1 \ --port=8080 -CONTROLLER CONTAINER(S) IMAGE(S) SELECTOR REPLICAS -hello-node hello-node gcr.io/..../hello-node:v1 run=hello-node 1 +deployment "hello-node" created ``` -Now is probably a good time to run through some of the following interesting kubectl commands (none of these will change the state of the cluster, full documentation is available [here](https://cloud.google.com/container-engine/docs/kubectl/)): +As shown in the output, the `kubectl run` created a **deployment** object. Deployments are the recommended way for managing creation and scaling of pods. In this example, a new deployment manages a single pod replica running the *hello-node:v1* image. + +To view the deployment we just created: + +```shell +$ kubectl get deployments +NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE +hello-node 1 1 1 1 3m +``` + +To view the pod created by the deployment: ```shell $ kubectl get pods -$ kubectl logs -$ kubectl cluster-info -$ kubectl config view +NAME READY STATUS RESTARTS AGE +hello-node-714049816-ztzrb 1/1 Running 0 6m +``` + +To view the stdout / stderr from a pod (hello-node image has no output, so logs will be empty in this case): + +```shell +$ kubectl logs +``` + +To view metadata about the cluster: + +```shell +$ kubectl get cluster-info +``` + +To view cluster events: + +```shell $ kubectl get events ``` +Full documentation for kubectl commands is available [here](https://cloud.google.com/container-engine/docs/kubectl/)): + At this point you should have our container running under the control of Kubernetes but we still have to make it accessible to the outside world. ## Allow external traffic -By default, the pod is only accessible by its internal IP within the Kubernetes cluster. In order to make the `hello-node` container accessible from outside the kubernetes virtual network, you have to expose the pod as a kubernetes service. +By default, the pod is only accessible by its internal IP within the Kubernetes cluster. In order to make the `hello-node` container accessible from outside the kubernetes virtual network, you have to expose the pod as a kubernetes **service**. From our development machine we can expose the pod with the `kubectl` expose command and the `--type="LoadBalancer"` flag which creates an external IP to accept traffic: ```shell -kubectl expose rc hello-node --type="LoadBalancer" +$ kubectl expose deployment hello-node --type="LoadBalancer" ``` -The flag used in this command specifies that we’ll be using the load-balancer provided by the underlying infrastructure (in this case the [Compute Engine load balancer](https://cloud.google.com/compute/docs/load-balancing/)). The `rc` refers to the Kubernetes "replication controller" -- which is a Kubernetes service which controls load balancing and scaling behavior for your cluster. +The flag used in this command specifies that we’ll be using the load-balancer provided by the underlying infrastructure (in this case the [Compute Engine load balancer](https://cloud.google.com/compute/docs/load-balancing/)). Note that we expose the deployment, and not the pod directly. This will cause the resulting service to load balance traffic across all pods managed by the deployment (in this case only 1 pod, but we will add more replicas later). The Kubernetes master creates the load balancer and related Compute Engine forwarding rules, target pools, and firewall rules to make the service fully accessible from outside of Google Cloud Platform. -To find the publicly-accessible IP address, ask `kubectl` to describe the `hello-node` cluster service: +To find the ip addresses associated with the service. ```shell -kubectl get services hello-node +$ kubectl get services hello-node NAME CLUSTER_IP EXTERNAL_IP PORT(S) SELECTOR AGE -hello-node 10.3.246.12 23.251.159.72 8080/TCP run=hello-node 53s +hello-node 10.3.246.12 8080/TCP run=hello-node 23s ``` -Note there are 2 IP addresses listed, both serving port 8080. One is the internal IP that is only visible inside your cloud virtual network; the other is the external load-balanced IP. In this example, the external IP address is 23.251.159.72. Traffic to the load-balanced IP will be load balanced to the three nodes you provisioned when initially creating the cluster! +The EXTERNAL_IP may take several minutes to become available and visible. If the EXTERNAL_IP is missing, wait a few minutes and try again. -You should now be able to reach the service by pointing your browser to this address: http://**:8080** +```shell +$ kubectl get services hello-node +NAME CLUSTER_IP EXTERNAL_IP PORT(S) SELECTOR AGE +hello-node 10.3.246.12 23.251.159.72 8080/TCP run=hello-node 2m +``` + +Note there are 2 IP addresses listed, both serving port 8080. CLUSTER_IP is only visible inside your cloud virtual network. EXTERNAL_IP is externally accessible. In this example, the external IP address is 23.251.159.72. + +You should now be able to reach the service by pointing your browser to this address: http://**:8080** or running `curl http://:8080` ![image](/images/hellonode/image_12.png) ## Scale up your website -One of the powerful features offered by Kubernetes is how easy it is to scale your application. Suppose you suddenly need more capacity for your application; you can simply tell the replication controller to manage a new number of replicas for your pod: +One of the powerful features offered by Kubernetes is how easy it is to scale your application. Suppose you suddenly need more capacity for your application; you can simply tell the deployment to manage a new number of replicas for your pod: + +```shell +$ kubectl scale deployment hello-node --replicas=4 +``` + +You now have four replicas of your application, each running independently on the cluster with the load balancer you created earlier and serving traffic to all of them. + +```shell +$ kubectl get deployment +NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE +hello-node 4 4 4 3 40m +``` ```shell -kubectl scale rc hello-node --replicas=4 $ kubectl get pods -NAME READY STATUS RESTARTS AGE -hello-node-6uzt8 1/1 Running 0 8m -hello-node-gxhty 1/1 Running 0 34s -hello-node-z2odh 1/1 Running 0 34s +NAME READY STATUS RESTARTS AGE +hello-node-714049816-g4azy 1/1 Running 0 1m +hello-node-714049816-rk0u6 1/1 Running 0 1m +hello-node-714049816-sh812 1/1 Running 0 1m +hello-node-714049816-ztzrb 1/1 Running 0 41m ``` -You now have four replicas of your application, each running independently on the cluster with the load balancer you created earlier and serving traffic to all of them. - -```shell -kubectl get rc hello-node -CONTROLLER CONTAINER(S) IMAGE(S) SELECTOR REPLICAS -hello-node hello-node gcr.io/..../hello-node:v1 run=hello-node 3 -``` Note the **declarative approach** here - rather than starting or stopping new instances you declare how many instances you want to be running. Kubernetes reconciliation loops simply make sure the reality matches what you requested and take action if needed. @@ -221,36 +261,28 @@ First, let’s modify the application. On the development machine, edit server.j We can now build and publish a new container image to the registry with an incremented tag: ```shell -docker build -t gcr.io/PROJECT_ID/hello-node:v2 . -docker push gcr.io/PROJECT_ID/hello-node:v2 +$ docker build -t gcr.io/PROJECT_ID/hello-node:v2 . +$ docker push gcr.io/PROJECT_ID/hello-node:v2 ``` Building and pushing this updated image should be much quicker as we take full advantage of the Docker cache. -We’re now ready for kubernetes to smoothly update our replication controller to the new version of the application: +We’re now ready for kubernetes to smoothly update our deployment to the new version of the application. Change the image from gcr.io/PROJECT_ID/hello-node:v1 to gcr.io/PROJECT_ID/hello-node:v2 using `kubectl edit`: ```shell -kubectl rolling-update hello-node \ - --image=gcr.io/PROJECT_ID/hello-node:v2 \ - --update-period=2s -Creating hello-node-324d23dd3e0e2474d6b76dc599abb519 -At beginning of loop: hello-node replicas: 2, hello-node-324d23dd3e0e2474d6b76dc599abb519 replicas: 1 -... -At end of loop: hello-node replicas: 0, hello-node-324d23dd3e0e2474d6b76dc599abb519 replicas: 3 -Update succeeded. Deleting old controller: hello-node -Renaming hello-node-324d23dd3e0e2474d6b76dc599abb519 to hello-node -hello-node +$ kubectl edit deployment hello-node +deployment "hello-node" edited ``` -You should see in the standard output how the rolling update actually works: +This updates the deployment with the new image, causing new pods to be created with the new image and old pods to be deleted. -1. A new replication controller is created based on the new image +``` +$ kubectl get deployments +NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE +hello-node 4 5 4 3 1h +``` -2. The replica count on the new and old controllers is increased/decreased by one respectively until the desired number of replicas is reached - -3. The original replication controller is deleted. - -While this is happening, the users of the services should not see any interruption. After a little while they will start accessing the new version of your application. You can find more details on rolling updates in [this documentation](https://cloud.google.com/container-engine/docs/rolling-updates). +While this is happening, the users of the services should not see any interruption. After a little while they will start accessing the new version of your application. You can find more details in the [deployment documentation](/docs/user-guide/deployments.md). Hopefully with these deployment, scaling and update features you’ll agree that once you’ve setup your environment (your GKE/Kubernetes cluster here), Kubernetes is here to help you focus on the application rather than the infrastructure. @@ -275,16 +307,10 @@ Navigate to the URL that is shown under after KubeUI is running at and log in wi That's it for the demo! So you don't leave this all running and incur charges, let's learn how to tear things down. -First, delete the Service, which also deletes your external load balancer: +Delete the Deployment (which also deletes the running pods) and Service (which also deletes your external load balancer): ```shell -kubectl delete services hello-node -``` - -Delete the running pods: - -```shell -kubectl delete rc hello-node +kubectl delete service,deployment hello-node ``` Delete your cluster: