Notes to Self

Alex Sokolsky's Notes on Computers and Programming

k8s Pods

Listing pods

Short but show labels:

kubectl get pods -A --show-labels --watch

or

kubectl get pods -n all -o=wide

To count the pods with a specific label:

kubectl get pods  --show-labels --no-headers --selector env=dev | wc -l

Describe all the pods:

kubectl describe pods -n all

Save pod yaml

kubectl get pod rabbit -o=yaml

Replace a pod

kubectl replace --force -f rabbit.yaml

Create an ad-hoc pod

Use kubectl run

kubectl run nginx --image=nginx --port=5701

To generate the POD Manifest YAML file:

kubectl run nginx --image=nginx --dry-run=client -o yaml > pod.yaml

Then cat pod.yaml gives:

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - name: nginx
    image: nginx:1.14.2
    ports:
    - containerPort: 80
    envFrom:
    - secretRef:
        name: test-secret

You can specify command line in-place:

kubectl run busybox --image=busybox --command -- sleep 1000

To get an interactive shell within your cluster with an AWS CLI client:

kubectl run ad-hoc --rm -i --tty --image=zulhfreelancer/aws-cli-v2-on-ubuntu -- bash

where:

Create an ad-hoc pod with custom limits

To modify limits and/or specify taints use --overrides :

kubectl run ad-hoc --rm -i --tty --image=zulhfreelancer/aws-cli-v2-on-ubuntu --overrides='
{
    "apiVersion":"v1",
    "kind": "Pod",
    "spec": {
        "containers": [
            {
                "name": "ad-hoc",
                "stdin": true,
                "stdinOnce": true,
                "tty": true,
                "image": "zulhfreelancer/aws-cli-v2-on-ubuntu",
                "resources": {
                    "requests":{
                        "cpu": "8000m",
                        "memory": "512Mi"
                    }}}]}}'

Note: The above uses quantity notation, resource units. Hence:

Setting cpu to 8 cores may force autoscaler (e.g. karpenter) to allocate a new cluster node.

Create an ad-hoc pod in the context of a specific service account

To perform AWS troubleshooting in the context of the service account foo created in the namespace foo:

kubectl run ad-hoc --rm -ti --restart=Never -n foo  \
  --image=zulhfreelancer/aws-cli-v2-on-ubuntu \
  --overrides='{"spec":{"serviceAccount":"foo"}}'

Create an ad-hoc pod on a specific node

To run the pod on the node node01:

kubectl run ad-hoc --rm -ti --restart=Never \
  --image=zulhfreelancer/aws-cli-v2-on-ubuntu \
  --overrides='{"spec":{"nodeName":"node01"}}'

Alternatively, to run the pod on the node of specific architecture, e.g. amd64:

kubectl run ad-hoc --rm -ti --restart=Never \
  --image=zulhfreelancer/aws-cli-v2-on-ubuntu \
  --overrides='{"apiVersion":"v1","spec":{"nodeSelector":{"kubernetes.io/arch":"amd64"}}}'

Tolerations

You specify a toleration for a pod in the PodSpec. Both of the following tolerations “match” the taint created by the kubectl taint line above, and thus a pod with either toleration would be able to schedule onto node1:

tolerations:
- key: "key1"
  operator: "Equal"
  value: "value1"
  effect: "NoSchedule"
tolerations:
- key: "key1"
  operator: "Exists"
  effect: "NoSchedule"

Delete Pod

kubectl delete pod rabbit

Use --force if you are impatient. The above does not work for static pods.

Static Pods

Static pods are defined in /etc/kubernetes/manifests.

Security Context for a Pod or Container

https://kubernetes.io/docs/tasks/configure-pod-container/security-context/

For a pod:

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo
spec:
  securityContext:
    runAsUser: 1000
    runAsGroup: 3000
    fsGroup: 2000
  volumes:
  - name: sec-ctx-vol
    emptyDir: {}
  containers:
  - name: sec-ctx-demo
    image: busybox:1.28
    command: [ "sh", "-c", "sleep 1h" ]
    volumeMounts:
    - name: sec-ctx-vol
      mountPath: /data/demo
    securityContext:
      allowPrivilegeEscalation: false

For a container:

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo-2
spec:
  securityContext:
    runAsUser: 1000
  containers:
  - name: sec-ctx-demo-2
    image: gcr.io/google-samples/node-hello:1.0
    securityContext:
      runAsUser: 2000
      allowPrivilegeEscalation: false

Further to add capabilities:

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo-4
spec:
  containers:
  - name: sec-ctx-4
    image: gcr.io/google-samples/node-hello:1.0
    securityContext:
      capabilities:
        add: ["NET_ADMIN", "SYS_TIME"]

To add capabilities to the container:

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo-4
spec:
  containers:
  - name: sec-ctx-4
    image: gcr.io/google-samples/node-hello:1.0
    securityContext:
      capabilities:
        add: ["NET_ADMIN", "SYS_TIME"]

Use of Labels

Labels are used, e.g. to link replica sets or services to pods:

  1. we label the pod
  2. use the same label in the podSelector field in the NetworkPolicy object

Volume Claim in a Pod

Create a persistent volume.

Then use claims as volumes:

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
    - name: myfrontend
      image: nginx
      volumeMounts:
      - mountPath: "/var/www/html"
        name: mypd
  volumes:
    - name: mypd
      persistentVolumeClaim:
        claimName: myclaim

The same is true for ReplicaSets or Deployments.

Run a Command in a Container

To run a command in a container use kubectl exec:

k exec sleeper -- whoami