Cheat Sheet - Kubernetes

Run ad hoc container

When working with containers in Kubernetes, you should be careful not to mix up Kubernetes command and Docker Cmd.

  • the command field in Kubernetes corresponds to the EntryPoint field in Docker
  • the args field in Kubernetes corresponds to the Cmd field in Docker

From the Kubernetes documentation:

When you override the default Entrypoint and Cmd, these rules apply:

  • If you do not supply command or args for a Container, the defaults defined in the Docker image are used.

  • If you supply a command but no args for a Container, only the supplied command is used. The default EntryPoint and the default Cmd defined in the Docker image are ignored.

  • If you supply only args for a Container, the default Entrypoint defined in the Docker image is run with the args that you supplied.

  • If you supply a command and args, the default Entrypoint and the default Cmd defined in the Docker image are ignored. Your command is run with your args.

# pass /bin/bash as CMD args
kubectl run --rm -it --image \
    012345678901.dkr.ecr.eu-central-1.amazonaws.com/my-org/my-image:v1.25.1_20210723T085350 \
    adhoc-container -- /bin/bash

# pass /bin/bash as ENTRYPOINT
kubectl run --rm -it --image \
    012345678901.dkr.ecr.eu-central-1.amazonaws.com/my-org/my-image:v1.25.1_20210723T085350 \
    adhoc-container --command /bin/bash

Restart deployment

# Restart deployment
kubectl get deployment my-app -n int-01
kubectl rollout restart deployment my-app -n int-01
kubectl rollout status deployment my-app -n int-01
kubectl logs deployment/my-app -n int-01

# Dis/enable a node
export NODE="someNode"

# DISABLE NODE
kubectl drain $NODE --ignore-daemonsets
kubectl taint nodes $NODE dedicated=special-user:NoExecute

# ENABLE NODE
kubectl uncordon $NODE
kubectl taint nodes $NODE dedicated-

# WATCH NODES
watch kubectl get nodes
watch "kubectl get nodes -o json | jq '.items[].spec.taints'"

# WATCH ALL PODS
watch kubectl get pods -o wide --sort-by="{.spec.nodeName}" --all-namespaces

Selectors

When using Kubernetes it is more common to use labels and selectors. E.g. if you deployed an application, you usually set a label on the pods e.g. app=my-app and you can then get the pods with e.g. kubectl get pods -l app=my-app.

Using this approach, it is easier to delete the pods you are interested in, with e.g.

kubectl delete pods -l app=my-app

or with namespaces

kubectl delete pods -l app=my-app -n default

See more on Kubernetes Labels and Selectors

Set-based selector

I have some pod’s running in the name of “superset-react” and “superset-graphql” and I want to search my wildcard superset and delete both of them in one command

I suggest that those pods has labels app=something-react and app=something-graphql. If you want to classify those apps, e.g. if your “superset” varies, you could add a label app-type=react and app-type=graphql to all those type of apps.

Then you can delete pods for both app types with this command:

kubectl delete pods -l 'app-type in (react, graphql)'

equality vs set based selectors

https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/

flux

# suspend or resume
flux suspend kustomization -n int-01 my-app
flux suspend receiver -n my-infra my-infra
flux suspend source git -n my-infra my-dev-infra