Show Menu
Cheatography
  1. Home >
  2. Software >

Kubernetes - CKAD Cheat Sheet by

Commands that will help you during the CKAD exam.

General commands

alias k=kubectl
k api-re­sources
List all resource types in the cluster
k explain node
Introspect docume­ntation for a resource
k explain node.spec
Dive deeper into a resource specif­ication

Pods

k get po
List pods
k get po -o wide
Include additional details
k get po <pod name> -o yaml
Output a specific pod in YAML format
k get po <po­d-n­ame> -o yaml > pod.yaml
Output a specific pod in YAML to a file
k get pods -n <po­d-n­ame>
Pods in a specific namespace
k get pods --all-­­na­m­e­spaces
List pods across all namespaces
kubectl get pods -A
Short version of 
--all-­nam­espaces
kubectl get events -A | grep error
All events in all namespaces with errors
k get pod --show­-labels
Show labels for pods
k get pod -l <ke­y>=­<va­lue>
Filter pods by label
k describe po <pod name>
Get details about a pod
k delete po <pod name>
Delete a specific pod
k delete po --all
Delete all pods in the namespace
k apply -f <po­d.y­aml> -n <na­mes­pac­e-n­ame>
Apply pod config­uration
k edit po <po­d-n­ame>
Edit a pod
k run nginx --imag­e=nginx --dry-­run­=client -o yaml > pod.yaml
Generate pod YAML impera­tively
k exec [pod-name] -- [command]
Execute a command in a pod
k exec nginx -- ls /
Execute ls command in the root /
k exec -it nginx -- /bin/sh
Get a shell in the container
Key Notes:
- Pods can have initCo­nta­iners for pre-task operat­ions.
- Use restar­tPolicy (Always, OnFailure, Never) in the pod spec.

Replica set

k apply -f <re­pli­cas­et-­def­ini­tio­n.y­aml>
Create­/Update a ReplicaSet
k get rs
List Replic­aSets
k get rs -o wide
Get ReplicaSet details
k delete rs <re­pli­cas­et-­nam­e>
Delete a ReplicaSet
k scale rs <re­pli­cas­et-­nam­e> --repl­icas=6
Scale replicas
k edit rs <re­pli­cas­et-­nam­e>
Edit a ReplicaSet
k describe rs <re­pli­cas­et-­nam­e>
Get details about a ReplicaSet
k delete po <rs­-po­-na­me>
Delete all pods under ReplicaSet
k get rs <rs­-na­me> -o yaml > rs.yaml
Export a ReplicaSet to a YAML file
Editing ReplicaSet
- Either delete and re-create the ReplicaSet or
- Update the existing ReplicaSet and then delete all PODs, so new ones with the correct image will be created.

The value for labels in spec.s­elector clause and spec.t­emp­lat­e.m­etadata should match in replic­aset.

ConfigMap

k create cm <cm­-na­me> --from­-li­ter­al=­key­=value
k create cm <cm­-na­me> --from­-fi­le=­<pa­th>
k describe cm <cm­-na­me>
Read config map detals
ConfigMaps in Kubernetes
ConfigMaps can be injected into Pods as:
- Enviro­nment variables: Use 
config­Map­KeyRef
(for specific keys) or 
config­MapRef
/
envFrom
(for the whole Config­Map).
- Files in a volume: Mount the ConfigMap as a volume for your applic­ation to read.

Secret

k get secrets
k get secret --all-­nam­espaces
k describe secret <se­cre­t-n­ame>
This shows the attributes in secret but hides the values.
k get secret <se­cre­t-n­ame> -o yaml
To view the values (values are encoded).
k create secret generic <se­cre­t-n­ame> --from­-li­ter­al=­<ke­y1>­=<v­alu­e1> --from­-li­ter­al=­<ke­y2>­=<v­alu­e2>
k create secret generic <se­cre­t-n­ame> --from­-fi­le=­<path to file>
echo -n 'string' | base64
How to decode to base64
echo -n 'encoded string' | base64 --decode
how to decode a base64 string

Taints (on nodes) and Tolera­tions (on pods)

k taint nodes [node_­name] <ke­y>=­<va­lue­>:[­NoS­che­dul­e|N­oEx­ecu­te|­Pre­fer­NoS­che­dule]
Taint effect defines what happens to pods that do not tolerate this taint.
k taint no node01 spray=­mor­tei­n:N­oSc­hedule
k describe nodes node01 | grep -i "­tai­nt"
To check taints on a node
kubectl taint nodes master node-r­ole.ku­ber­net­es.i­o/­mas­ter­:No­Sch­edule-
Remove the taint on the master node that has the NoSchedule effect
kubectl taint nodes foo dedicated-
Remove all taints with the key dedicated from the node named foo: bash Copy code
Tolera­tions in the spec section have properties like key, operator, value, and effect. Their values are written inside quotation marks ("").

Horizontal Pod Auto Scaler

k get hpa
k delete hpa <hp­a-n­ame>
k autoscale deploy nginx --min=5 --max=10 --cpu-­per­cent=80

Monitoring

k top no
Resource usage for nodes
k top po
Resource usage for pods
k top pod --name­spa­ce=­default | head -2 | tail -1 | cut -d " " -f1
k top po --sort-by cpu --no-h­eaders

Events

k get events
k get events -n kube-s­ystem
k get events -w

DaemonSets

k get ds
k get ds --all-­nam­espaces
k describe ds <ds­-na­me> -n <ns­-na­me>
k describe ds <ds­-na­me> -o yaml

Enviro­nment Variables

k run nginx --imag­e=nginx --env=­app=web
nginx pod and with an ENV set to app=web
env and envFrom property is an array.
env property takes two properties - name and value. value takes only string and will always come in double quotes.

Service

k apply -f <sv­c.y­aml>
k get svc
k get svc --show­-labels
k get svc -o wide
k get svc -o yaml
k describe svc <se­rvi­ce-­nam­e>
To get to know about port, target port etc.
k delete svc <se­rvi­ce-­nam­e>
k expose deploy <de­plo­y-n­ame> --port=80 --type­=No­dePort
k expose deploy <de­plo­y-n­ame> --port=80 --type­=No­dePort --dry-­run­=client -o yaml > servic­e.yml

Node

k get no
k get no -o wide
k describe no <no­de-­nam­e>

Network Policy

k get netpol
k describe netpol <na­me>
Note: While creating network policy, make sure that not only network policy is applied to the correct object but also that it allows access from (ingress) / to correct object (egress).

labels and selectors are used.

An empty podSel­ector selects all pods in the namespace.

Annota­tions

k annotate po nginx desc="Hello World"
k annotate po nginx author­=Avnish
k annotate po nginx desc-
Remove this annotation from the pod
k annotate no <no­de-­nam­e>

Labels & Selectors

k get [pod|d­epl­oy|all] --show­-labels
Show labels
k get label [node|­pod­|de­plo­y|etc] <ke­y>=­<va­lue>
Syntax
k label pod nginx env=lab
To label pod
k label deploy my-webapp tier=f­rontend
To label deployment
k label node node01 size=large
To label nodes
k label po nginx <ke­y>-
Remove the label
k label po nginx env=lab1 --over­write
To overwrite a label
k get po --sele­cto­r=a­pp=App1
k get po --sele­cto­r=a­pp!­=App1
k get all --sele­cto­r=e­nv=prod
k get po --sele­cto­r=e­nv=­pro­d,b­u=f­ina­nce­,ti­er=­fro­ntend
Equivalent of && in progra­mming languages

Volumes

k get pv
k describe pv
k delete pv <pv­-na­me>
k get pvc
k describe pvc
k delete pvc <pv­c-n­ame>

Ingress

k get ingress
k describe ingress <in­gress name>
k edit ingress <in­gress name>
k apply -f <in­gre­ss.y­am­l>

Logging

k logs -f <po­d-n­ame> <co­nta­ine­r-n­ame>
Follow the logs
k logs <po­d-n­ame> --previous
Dump pod logs for a previous instan­tiation of a container
k logs --tail=20 <po­d-n­ame>

Deploy­ments

k create deploy nginx --imag­e=nginx --repl­icas=2
k get deploy
k get deploy -n <na­mes­pac­e-n­ame>
k get deploy <de­plo­yme­nt-­nam­e>
k get deploy <de­plo­yme­nt-­nam­e> -o yaml | more
k get deploy -o wide
k describe deploy <de­plo­yme­nt-­nam­e>
k apply -f deploy.yaml
k apply -f deploy.yaml --record
Record the change­-cause in revision history
k rollout status deploy <de­plo­yme­nt-­nam­e>
k rollout history deploy <de­plo­yme­nt-­nam­e>
k rollout history deploy nginx --revi­sion=2
to get detailed history for a specific revision.T
k rollout undo deploy <de­plo­yme­nt-­nam­e>
k rollout undo deploy <de­plo­yme­nt-­nam­e> --to-r­evi­sion=1
k rollout pause deploy <de­plo­yme­nt-­nam­e>
k rollout resume deploy <de­plo­yme­nt-­nam­e>
k delete deploy <de­plo­yme­nt-­nam­e>
k create deploy nginx --imag­e=nginx --dry-­run­=client -o yaml > deploy.yaml
k scale deploy <de­plo­yme­nt-­nam­e> --repl­icas=3
To scale up / down a deploy­ment. Not recorded in revision history.
k create deploy <de­plo­yme­nt-­nam­e> --imag­e=redis -n <na­mes­pac­e-n­ame>
k edit deploy <de­plo­yme­nt-­nam­e> -n <na­mes­pac­e-n­ame>
k expose deploy <de­plo­yme­nt-­nam­e> --port=80 --type­=No­deP­ort­|Cl­usterIp
k autoscale deployment <de­plo­yme­nt-­nam­e> --max 6 --min 3 --cpu-­percent 50
Autoscale deployment
Deploy­ments can be paused and resumed. When paused, no changes are recorded to revision history.

Rollin­gUp­dat­eSt­rategy in define upto how many pods can be down/up during the update at a time.
spec.s­tra­teg­y.t­ype­==R­oll­ing­Upd­ate­|Re­create
spec.s­tra­teg­y.r­oll­ing­Upd­ate.ma­xUn­ava­ilable
spec.s­tra­teg­y.r­oll­ing­Upd­ate.ma­xSurge

Updating images or new deploy­ements, triggers rollout. A new rollout creates a new deployment revision.

Service Account

k create sa <sa­-na­me>
k get sa
k get sa <sa­-na­me> -o yaml
k describe sa <sa­-na­me>
Fetch token: gives secret name
k describe secret <se­cre­t-n­ame>
Fetch token: gives token stored in secret
k run nginx --imag­e=nginx --serv­ice­acc­oun­t=m­yuser --dry-­run­=client -o yaml > pod.yaml
nginx pod that uses 'myuser' as a service account
When we use service account inside the pod, the secret for that service account is mounted as volume inside the pod.

Property to remember: spec -> servic­eAc­cou­ntName # set at pod level
Injected into the Pod.
For a deploy­ment, can set service account in pod template.

A user makes a request to API server through k using user account.
A process running inside a container makes a request to API server using service account.
A service account just like user account has certain permis­sions.

CronJobs

k get cj
k create cj busybox --imag­e=b­usybox --sche­dul­e="/1 *" -- /bin/sh -c "­date; echo Hello from Kubernetes cluste­r"
cron job with image busybox that runs on a schedule and writes to standard output
In a cronjob, there are 2 templates - one for job and another for pod.

In a cronjob, there are 3 spec sections - one for cronjob, one for job and one for pod (in order).

Properties to remember: spec -> succes­sfu­lJo­bHi­sto­ryL­imit, spec -> failed­Job­His­tor­yLimit

Jobs

k create job busybox --imag­e=b­usybox -- /bin/sh -c "echo hello;­sleep 30;echo world"
k get jobs
k logs busybo­x-qhcnx
pod under job
k delete job <jo­b-n­ame>
restar­tPolicy defaults to Never.

Job has 2 spec sections - one for job and one for pod (in order).

restar­tPolicy has to be OnFailure or Never. If the restar­tPolicy is OnFailure, a failed container will be re-run on the same pod. If the restar­tPolicy is Never, a failed container will be re-run on a new pod.

Job properties to remember: comple­tions, backof­fLimit, parall­elism, active­Dea­dli­neS­econds, restar­tPo­licy.

By default Pods in a job are created in sequence

Namespace

k get ns
k get ns -o yaml
k create ns <na­mes­pac­e-n­ame>
k apply -f <na­mes­pac­e.y­aml>
k get po -n kube-s­ystem
k describe ns <na­mes­pac­e-n­ame>
k delete ns <na­mes­pac­e-n­ame>
k config set-co­ntext $(k config curren­t-c­ontext) --name­spa­ce=dev
To switch to a namespace perman­ently
k run redis --imag­e=redis -n <na­mes­pac­e-n­ame>
Create/run in a specific ns
k exec -it <po­d-n­ame> -n <na­mes­pac­e-n­ame> -- sh
k create ns <na­mes­pac­e-n­ame> --dry-­run­=client -o yaml
       
 

Metadata

  • Languages:
  • Published: 26th November, 2024

Comments

No comments yet. Add yours below!

Add a Comment

Your Comment

Please enter your name.

    Please enter your email address

      Please enter your Comment.

          Related Cheat Sheets

          Kubectl Cheat Sheet