Merge pull request #21065 from sharet-adl/patch-2

update deployment sample, due to deprecated option
This commit is contained in:
Kubernetes Prow Robot
2020-05-19 10:55:37 -07:00
committed by GitHub
@@ -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. can follow along and get a second data point.
```shell ```shell
kubectl run hostnames --image=k8s.gcr.io/serve_hostname \ kubectl create deployment hostnames --image=k8s.gcr.io/serve_hostname
--replicas=3
``` ```
```none ```none
deployment.apps/hostnames created 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. `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 >}} {{< note >}}
This is the same as if you had started the Deployment with the following This is the same as if you had started the Deployment with the following
YAML: YAML:
@@ -62,30 +69,32 @@ YAML:
apiVersion: apps/v1 apiVersion: apps/v1
kind: Deployment kind: Deployment
metadata: metadata:
labels:
app: hostnames
name: hostnames name: hostnames
spec: spec:
selector: selector:
matchLabels: matchLabels:
run: hostnames app: hostnames
replicas: 3 replicas: 3
template: template:
metadata: metadata:
labels: labels:
run: hostnames app: hostnames
spec: spec:
containers: containers:
- name: hostnames - name: hostnames
image: k8s.gcr.io/serve_hostname 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. Deployment.
{{< /note >}} {{< /note >}}
You can confirm your Pods are running: You can confirm your Pods are running:
```shell ```shell
kubectl get pods -l run=hostnames kubectl get pods -l app=hostnames
``` ```
```none ```none
NAME READY STATUS RESTARTS AGE 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. Pod IP addresses and test them directly.
```shell ```shell
kubectl get pods -l run=hostnames \ kubectl get pods -l app=hostnames \
-o go-template='{{range .items}}{{.status.podIP}}{{"\n"}}{{end}}' -o go-template='{{range .items}}{{.status.podIP}}{{"\n"}}{{end}}'
``` ```
```none ```none
@@ -122,9 +131,9 @@ done
This should produce something like: This should produce something like:
``` ```
hostnames-0uton hostnames-632524106-bbpiw
hostnames-bvc05 hostnames-632524106-ly40y
hostnames-yp2kp hostnames-632524106-tlaok
``` ```
If you are not getting the responses you expect at this point, your Pods 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 apiVersion: v1
kind: Service kind: Service
metadata: metadata:
labels:
app: hostnames
name: hostnames name: hostnames
spec: spec:
selector: selector:
run: hostnames app: hostnames
ports: ports:
- name: default - name: default
protocol: TCP protocol: TCP
@@ -345,9 +356,9 @@ done
This should produce something like: This should produce something like:
``` ```
hostnames-0uton hostnames-632524106-bbpiw
hostnames-bvc05 hostnames-632524106-ly40y
hostnames-yp2kp hostnames-632524106-tlaok
``` ```
If your Service is working, you should get correct responses. If not, there 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", "resourceVersion": "347189",
"creationTimestamp": "2015-07-07T15:24:29Z", "creationTimestamp": "2015-07-07T15:24:29Z",
"labels": { "labels": {
"run": "hostnames" "app": "hostnames"
} }
}, },
"spec": { "spec": {
@@ -387,7 +398,7 @@ kubectl get service hostnames -o json
} }
], ],
"selector": { "selector": {
"run": "hostnames" "app": "hostnames"
}, },
"clusterIP": "10.0.1.175", "clusterIP": "10.0.1.175",
"type": "ClusterIP", "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: Earlier you saw that the Pods were running. You can re-check that:
```shell ```shell
kubectl get pods -l run=hostnames kubectl get pods -l app=hostnames
``` ```
```none ```none
NAME READY STATUS RESTARTS AGE NAME READY STATUS RESTARTS AGE
hostnames-0uton 1/1 Running 0 1h hostnames-632524106-bbpiw 1/1 Running 0 1h
hostnames-bvc05 1/1 Running 0 1h hostnames-632524106-ly40y 1/1 Running 0 1h
hostnames-yp2kp 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. has.
The "AGE" column says that these Pods are about an hour old, which implies that 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 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 `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 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? ## Are the Pods working?
@@ -473,9 +485,9 @@ done
This should produce something like: This should produce something like:
``` ```
hostnames-0uton hostnames-632524106-bbpiw
hostnames-bvc05 hostnames-632524106-ly40y
hostnames-yp2kp hostnames-632524106-tlaok
``` ```
You expect each Pod in the Endpoints list to return its own hostname. If 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 curl 10.0.1.175:80
``` ```
```none ```none
hostnames-0uton hostnames-632524106-bbpiw
``` ```
If this fails and you are using the userspace proxy, you can try accessing the 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 curl localhost:48577
``` ```
```none ```none
hostnames-yp2kp hostnames-632524106-tlaok
``` ```
If this still fails, look at the `kube-proxy` logs for specific lines like: If this still fails, look at the `kube-proxy` logs for specific lines like: