You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The section of chapter 6 titled "Applying Labels" would have the reader run commands like this to create and label some deployments:
$ kubectl run alpaca-prod \
--image=gcr.io/kuar-demo/kuard-amd64:blue \
--replicas=2 \
--labels="ver=1,app=alpaca,env=prod"
A user running any recent version of kubectl will find this command does not work. As of March 2020, Kubernetes v1.18 changed the run command to create pods instead of deployments. You might then try kubectl create deployment and find the command does not take a --labels option.
The commands I've found to work instead take the form:
# First, create the deployment
$ kubectl create deployment alpaca-prod --image=gcr.io/kuar-demo/kuard-amd64:blue --replicas=2
# After the deployment is created, you can add some labels
$ kubectl label deployments alpaca-prod --overwrite ver=1 app=alpaca env=prod
Note that kubectl create deployment alpaca-prod ... automatically added a label app=alpaca-prod to the deployment. That's why we need the --overwrite option there.
Also note, in the next section, "Label Selectors", where the book would have you select the pods in the deployment by the labels you just applied to the deployment, pods do not inherit labels applied to the deployments this way. You will see this when you run kubectl get pods. The pods have the default app labels with values "alpaca-prod", "bandicoot-staging", etc, and also a pod-template-hash label, but not the labels you applied to the deployments.
I assume this statement from the "Label Selectors" section...
Each deployment (via a ReplicaSet) creates a set of Pods using the labels specified in the template embedded in the deployment. This is configured by the kubectl run command.
is not longer true of how the Kubernetes API works. Or maybe in creating deployments another way, such as by applying a YAML manifest, there is a way to have the pods inherit the labels of the deployment. Maybe that's where the ReplicaSet is involved. The book hasn't covered ReplicaSets by chapter 6.
Hopefully this will be helpful to anyone else who gets stuck on chapter 6. And hopefully the changed API makes it into the next edition of the book.
The text was updated successfully, but these errors were encountered:
Hi @ckingbailey. Thank you very much for taking the time to provide such a detailed correction report. I've raised an errata to track these updates and make sure they are corrected in the online version and subsequent prints of 3rd edition. I will report back once complete.
The section of chapter 6 titled "Applying Labels" would have the reader run commands like this to create and label some deployments:
$ kubectl run alpaca-prod \ --image=gcr.io/kuar-demo/kuard-amd64:blue \ --replicas=2 \ --labels="ver=1,app=alpaca,env=prod"
A user running any recent version of kubectl will find this command does not work. As of March 2020, Kubernetes v1.18 changed the
run
command to create pods instead of deployments. You might then trykubectl create deployment
and find the command does not take a--labels
option.The commands I've found to work instead take the form:
Note that
kubectl create deployment alpaca-prod ...
automatically added a labelapp=alpaca-prod
to the deployment. That's why we need the--overwrite
option there.Also note, in the next section, "Label Selectors", where the book would have you select the pods in the deployment by the labels you just applied to the deployment, pods do not inherit labels applied to the deployments this way. You will see this when you run
kubectl get pods
. The pods have the defaultapp
labels with values "alpaca-prod", "bandicoot-staging", etc, and also apod-template-hash
label, but not the labels you applied to the deployments.I assume this statement from the "Label Selectors" section...
is not longer true of how the Kubernetes API works. Or maybe in creating deployments another way, such as by applying a YAML manifest, there is a way to have the pods inherit the labels of the deployment. Maybe that's where the ReplicaSet is involved. The book hasn't covered ReplicaSets by chapter 6.
Hopefully this will be helpful to anyone else who gets stuck on chapter 6. And hopefully the changed API makes it into the next edition of the book.
The text was updated successfully, but these errors were encountered: