From c9a278dc2f2dac93a088f006abe5db2764436887 Mon Sep 17 00:00:00 2001 From: sharet-adl <57949742+sharet-adl@users.noreply.github.com> Date: Tue, 19 May 2020 18:49:32 +0300 Subject: [PATCH] update deployment sample, due to deprecated option Creating a deployment using 'kubectl run' command was deprecated and is not supported anymore, starting with 1.18 version. In order to keep the example as relevant as possible, all 3 pods were kept. Couple of changes: - fix example to use 'kubectl create deployment' command, and scaled it up explicitly - fix missing label for both Deployment and Service - update label key, from 'run' to 'app', as deployments automatically add the label with this key - update comment on how label's key could have used 'run' and 'app' values - update pods names and internal hostnames - which are based on the replicaSet (eg. hostnames-632524106). --- .../debug-service.md | 66 +++++++++++-------- 1 file changed, 39 insertions(+), 27 deletions(-) diff --git a/content/en/docs/tasks/debug-application-cluster/debug-service.md b/content/en/docs/tasks/debug-application-cluster/debug-service.md index a065c9fa85..23b210cb92 100644 --- a/content/en/docs/tasks/debug-application-cluster/debug-service.md +++ b/content/en/docs/tasks/debug-application-cluster/debug-service.md @@ -45,8 +45,7 @@ probably debugging your own Service you can substitute your own details, or you can follow along and get a second data point. ```shell -kubectl run hostnames --image=k8s.gcr.io/serve_hostname \ - --replicas=3 +kubectl create deployment hostnames --image=k8s.gcr.io/serve_hostname ``` ```none deployment.apps/hostnames created @@ -54,6 +53,14 @@ deployment.apps/hostnames created `kubectl` commands will print the type and name of the resource created or mutated, which can then be used in subsequent commands. +Let's scale the deployment to 3 replicas. +```shell +kubectl scale deployment hostnames --replicas=3 +``` +```none +deployment.apps/hostnames scaled +``` + {{< note >}} This is the same as if you had started the Deployment with the following YAML: @@ -62,30 +69,32 @@ YAML: apiVersion: apps/v1 kind: Deployment metadata: + labels: + app: hostnames name: hostnames spec: selector: matchLabels: - run: hostnames + app: hostnames replicas: 3 template: metadata: labels: - run: hostnames + app: hostnames spec: containers: - name: hostnames image: k8s.gcr.io/serve_hostname ``` -The label "run" is automatically set by `kubectl run` to the name of the +The label "app" is automatically set by `kubectl create deployment` to the name of the Deployment. {{< /note >}} You can confirm your Pods are running: ```shell -kubectl get pods -l run=hostnames +kubectl get pods -l app=hostnames ``` ```none NAME READY STATUS RESTARTS AGE @@ -98,7 +107,7 @@ You can also confirm that your Pods are serving. You can get the list of Pod IP addresses and test them directly. ```shell -kubectl get pods -l run=hostnames \ +kubectl get pods -l app=hostnames \ -o go-template='{{range .items}}{{.status.podIP}}{{"\n"}}{{end}}' ``` ```none @@ -122,9 +131,9 @@ done This should produce something like: ``` -hostnames-0uton -hostnames-bvc05 -hostnames-yp2kp +hostnames-632524106-bbpiw +hostnames-632524106-ly40y +hostnames-632524106-tlaok ``` If you are not getting the responses you expect at this point, your Pods @@ -193,10 +202,12 @@ As before, this is the same as if you had started the Service with YAML: apiVersion: v1 kind: Service metadata: + labels: + app: hostnames name: hostnames spec: selector: - run: hostnames + app: hostnames ports: - name: default protocol: TCP @@ -345,9 +356,9 @@ done This should produce something like: ``` -hostnames-0uton -hostnames-bvc05 -hostnames-yp2kp +hostnames-632524106-bbpiw +hostnames-632524106-ly40y +hostnames-632524106-tlaok ``` If your Service is working, you should get correct responses. If not, there @@ -373,7 +384,7 @@ kubectl get service hostnames -o json "resourceVersion": "347189", "creationTimestamp": "2015-07-07T15:24:29Z", "labels": { - "run": "hostnames" + "app": "hostnames" } }, "spec": { @@ -387,7 +398,7 @@ kubectl get service hostnames -o json } ], "selector": { - "run": "hostnames" + "app": "hostnames" }, "clusterIP": "10.0.1.175", "type": "ClusterIP", @@ -414,16 +425,16 @@ actually being selected by the Service. Earlier you saw that the Pods were running. You can re-check that: ```shell -kubectl get pods -l run=hostnames +kubectl get pods -l app=hostnames ``` ```none NAME READY STATUS RESTARTS AGE -hostnames-0uton 1/1 Running 0 1h -hostnames-bvc05 1/1 Running 0 1h -hostnames-yp2kp 1/1 Running 0 1h +hostnames-632524106-bbpiw 1/1 Running 0 1h +hostnames-632524106-ly40y 1/1 Running 0 1h +hostnames-632524106-tlaok 1/1 Running 0 1h ``` -The `-l run=hostnames` argument is a label selector - just like our Service +The `-l app=hostnames` argument is a label selector - just like our Service has. The "AGE" column says that these Pods are about an hour old, which implies that @@ -448,7 +459,8 @@ your Service. If the `ENDPOINTS` column is ``, you should check that the `spec.selector` field of your Service actually selects for `metadata.labels` values on your Pods. A common mistake is to have a typo or other error, such as the Service selecting for `app=hostnames`, but the -Deployment specifying `run=hostnames`. +Deployment specifying `run=hostnames`, as in versions previous to 1.18, where +the `kubectl run` command could have been also used to create a Deployment. ## Are the Pods working? @@ -473,9 +485,9 @@ done This should produce something like: ``` -hostnames-0uton -hostnames-bvc05 -hostnames-yp2kp +hostnames-632524106-bbpiw +hostnames-632524106-ly40y +hostnames-632524106-tlaok ``` You expect each Pod in the Endpoints list to return its own hostname. If @@ -617,7 +629,7 @@ IP from one of your Nodes: curl 10.0.1.175:80 ``` ```none -hostnames-0uton +hostnames-632524106-bbpiw ``` If this fails and you are using the userspace proxy, you can try accessing the @@ -631,7 +643,7 @@ examples it is "48577". Now connect to that: curl localhost:48577 ``` ```none -hostnames-yp2kp +hostnames-632524106-tlaok ``` If this still fails, look at the `kube-proxy` logs for specific lines like: