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

update deployment sample, due to deprecated option

Browse Source 
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).
This commit is contained in:
sharet-adl
2020-05-19 18:49:32 +03:00
committed by GitHub
parent 898f325532
commit c9a278dc2f
1 changed files with 39 additions and 27 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/en/docs/tasks/debug-application-cluster/debug-service.md
+39 -27
View File
@@ -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 `<none>`, 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: