-
Notifications
You must be signed in to change notification settings - Fork 515
/
cka_question_answers
276 lines (220 loc) · 9.43 KB
/
cka_question_answers
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
1. Understand deployments and how to perform rolling update and rollbacks
Create the DaemonSet with nginx:1.10.1 image, update the ds with newer version of the nginx:1.12.1-alpine server, change the updateStrategy to OnDelete
show
Create the yaml file
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: ds-one
spec:
selector:
matchLabels:
name: ds-one
template:
metadata:
labels:
name: ds-one
spec:
containers:
- name: nginx
image: nginx:1.10.1
ports:
- containerPort: 80
Using the yaml file to create the ds
kubectl create -f ds.yaml
Check the updateStrategy. DaemonSet has two update strategy types:
OnDelete: after you update a DaemonSet template, new DaemonSet pods will only be created when you manually delete old DaemonSet pods.
RollingUpdate: after updating a DaemonSet template, old DaemonSet pods will be killed, and new DaemonSet pods will be created automatically. The default is RollingUpdate.
kubectl get ds ds-one -o yaml | grep -a3 updateStrategy:
Check the Image of the pod. It should be 1.10.1
kubectl describe pod ds-one-<tab> | grep Image:
Set the new version of nginx server. Check the Image of the pod. It should be 1.12.1-alpine
kubectl set image ds ds-one nginx=nginx:1.12.1-alpine
kubectl describe pod ds-one-<tab> | grep Image:
Check the rollout history. View the settings for various versions
kubectl rollout history ds ds-one
kubectl rollout history ds ds-one --revision=1
kubectl rollout history ds ds-one --revision=2
Change DaemonSet back to the earlier version, check the Image:
kubectl rollout undo ds ds-one --to-revision=1
kubectl describe pod ds-one-<tab> | grep Image:
Change the updateStrategy to OnDelete:
kubectl edit ds ds-one
updateStrategy:
#rollingUpdate: <-- Delete these 2 lines
# maxUnavailable: 1
type: OnDelete <-- Change this line
Check the rollout history and undo to revision 2. Check the Image:, still 1.10.1. After delete one pod, the Image of the new Pod will be 1.12.1-alpine
kubectl rollout history ds ds-one
kubectl rollout undo ds ds-one --to-revision=2
kubectl describe pod ds-one-<tab> | grep Image: # <-- still 1.10.1
kubectl delete pod ds-one-<tab>
kubectl describe pod ds-one-<tab> | grep Image: # <-- new pod should be 1.12.1-alpine
==============================================================
2. Know various ways to configure applications
Configuring Command and Arguments on applications
Create a pod (Pod name: ubuntu-sleeper) with the ubuntu image to run a container to sleep for 5000 seconds.
Create a pod with the given specifications. By default it displays a 'blue' background. Set the given command line arguments to change it to 'green' (Pod Name: webapp-green, Image: kodekloud/webapp-color, Command line arguments: --color=green)
show
Using kubectl run with --dry-run option to create yaml file, then add command to the yaml file.
kubectl run ubuntu-sleeper --generator=run-pod/v1 --image=ubuntu --dry-run -o yaml > ubuntu-sleeper.yaml
vi ubuntu-sleeper.yaml
spec:
containers:
- image: ubuntu
name: ubuntu-sleeper
command:
- sleep
- "5000"
Using kubectl run with --dry-run option to create yaml file, then add command to the yaml file.
kubectl run webapp-green --generator=run-pod/v1 --image=kodekloud/webapp-color --dry-run -o yaml > webapp.yaml
vi webapp.yaml
kubectl create -f webapp.yaml
spec:
containers:
- image: kodekloud/webapp-color
name: webapp-green
args:
- --color
- "green"
Configuring Environment Variables
Create a pod with the given specifications.
Pod name: print-greeting, image: ubuntu,
3 env variables GREETING, HONORIFIC, and NAME are set to Warm greetings to, The Most Honorable, and Kubernetes, respectively,
run in the bash shell the command: echo $(GREETING) $(HONORIFIC) $(NAME), then sleep 5000.
Setting env variables using ConfigMap:
create a configmap name family with father=lkd, mother=tn, son=bob
create a pod name shell-demo, image: nginx, env name (iam) from the key father of configmap family.
use envFrom to define all of the ConfigMap’s data as Pod environment variables
Using kubectl run with --dry-run option to create yaml file, then add command to the yaml file.
kubectl run print-greeting --generator=run-pod/v1 --image=bash --dry-run -o yaml > envars.yaml
vi envars.yaml
kubectl create -f envars.yaml
spec:
containers:
- image: ubuntu
name: print-greeting
resources: {}
env:
- name: GREETING
value: Warm greetings to
- name: HONORIFIC
value: The Most Honorable
- name: NAME
value: Kubernetes
command: ["/bin/bash"]
args: ["-c", "echo $(GREETING) $(HONORIFIC) $(NAME); sleep 5000"]
Check the output
kubectl logs print-greeting
Setting env variables using ConfigMap:
kubectl create configmap family --from-literal=father=lkd --from-literal=mother=tn --from-literal=son=bob
kubectl run shell-demo --generator=run-pod/v1 --image=nginx --dry-run -o yaml > config-app.yaml
vi config-app.yaml
spec:
containers:
- image: nginx
name: shell-demo
env:
- name: iam
valueFrom:
configMapKeyRef:
name: family
key: father
Create the pod, and check output:
kubectl create -f config-app.yaml
kubectl exec shell-demo -it -- /bin/bash -c 'echo $iam'
Modify the env:
spec:
containers:
- image: nginx
name: shell-demo
envFrom:
- configMapRef:
name: family
Delete and recreate the pod, check the output:
kubectl delete pod shell-demo
kubectl create -f config-app.yaml
kubectl exec shell-demo -it -- /bin/bash -c 'env'
Configuring Secrets
A tutorial of how to use and config Secrets is here.
Create a secret name db-user-password with username=admin, password=kd248asid9sasp, then decode the secret db-user-password
Using Secrets as Files from a Pod
Create a pod name nginx, image=nginx
Make the Secret db-user-password available to the Pod as a mounted volume at /etc/db_confidentials
Verify the volume exits
Create the secret and decode.
kubectl create secret generic db-user-password --from-literal=user=admin --from-literal=password=kd248asid9sasp
kubectl get secret db-user-password -o yaml
apiVersion: v1
data:
password: a2QyNDhhc2lkOXNhc3A=
user: YWRtaW4=
kind: Secret
metadata:
name: db-user-password
type: Opaque
Decode the password field:
echo 'a2QyNDhhc2lkOXNhc3A=' | base64 --decode
Using Secrets as Files from a Pod
Using kubectl run with --dry-run option to create yaml file, then add command to the yaml file.
kubectl run nginx --generator=run-pod/v1 --image=nginx --dry-run -o yaml > secret.yaml
vi secret.yaml
spec:
containers:
- image: nginx
name: nginx
resources: {}
volumeMounts:
- name: pass-vol
mountPath: /etc/db_confidentials
volumes:
- name: pass-vol
secret:
secretName: db-user-password
Verify the volume exits
kubectl exec -it nginx -- /bin/bash -c 'df -ha | grep db_confi'
kubectl exec -it nginx -- /bin/bash -c 'ls /etc/db_confidentials'
Multi-container Pod
Create a multi-container pod with 2 containers (Name: yellow, Container 1 Name: lemon, Container 1 Image: busybox, Container 2 Name: gold ,Container 2 Image: redis).
show
```bash kubectl run yellow --generator=run-pod/v1 --image=busybox --dry-run -o yaml > yellow.yaml vi yellow.yaml ``` ```yaml apiVersion: v1 kind: Pod metadata: labels: run: yellow name: yellow spec: containers: - image: busybox name: lemon - image: redis name: gold ```
InitContainers
Create the pod name red using nginx image,
Update the pod red to use an initContainer that uses the busybox image and sleeps for 20 seconds
show
kubectl run red --generator=run-pod/v1 --image=nginx --dry-run -o yaml > init-red.yaml
vi init-red.yaml
spec:
containers:
- image: nginx
name: red
resources: {}
initContainers:
- image: init-container-red
name: busybox
command: ["sleep 20"]
===============================================================
3. Know how to scale applications
Create the Deployment with nginx image, scale to replicas=3
show
kubectl create deployment nginx --image=nginx
kubectl scale deployment nginx --replicas=3
Change the deployment to autoscale, with target CPU utilization set to 80% and the number of replicas between 2 and 5.
kubectl autoscale deployment nginx --min=2 --max=5 --cpu-percent=80
kubectl get hpa
See the hpa settings:
kubectl describe hpa
You can notice that the warning:
ScalingActive False FailedGetResourceMetric the HPA was unable to compute the replica count: unable to get metrics for resource cpu: unable to fetch metrics from resource metrics API: the server could not find the requested resource (get pods.metrics.k8s.io)
You need to install metrics-server.
git clone https://github.com/kubernetes-incubator/metrics-server
kubectl create -f metrics-server/deploy/1.8+/
# edit metric-server deployment to add the flags
# args:
# - --kubelet-insecure-tls
# - --kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname
$ kubectl edit deploy -n kube-system metrics-server
==============================================================================
4. Understand the primitives necessary to create a self-healing application
Kubernetes supports self-healing applications through ReplicaSets and Replication Controllers. The replication controller helps in ensuring that a POD is re-created automatically when the application within the POD crashes. It helps in ensuring enough replicas of the application are running at all times.
Kubernetes provides additional support to check the health of applications running within PODs and take necessary actions through Liveness and Readiness Probes.