Links & References
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 theEntryPoint
field in Docker - the
args
field in Kubernetes corresponds to theCmd
field in Docker
From the Kubernetes documentation:
When you override the default
Entrypoint
andCmd
, these rules apply:
If you do not supply
command
orargs
for a Container, the defaults defined in the Docker image are used.If you supply a
command
but noargs
for a Container, only the suppliedcommand
is used. The defaultEntryPoint
and the defaultCmd
defined in the Docker image are ignored.If you supply only
args
for a Container, the defaultEntrypoint
defined in the Docker image is run with theargs
that you supplied.If you supply a
command
andargs
, the defaultEntrypoint
and the defaultCmd
defined in the Docker image are ignored. Yourcommand
is run with yourargs
.
# 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