Kubernetes Pod Operations: Difference between revisions

From NovaOrdis Knowledge Base
Jump to navigation Jump to search
No edit summary
 
(10 intermediate revisions by the same user not shown)
Line 24: Line 24:
More general options:
More general options:
  [[Kubectl#get|kubectl get]]
  [[Kubectl#get|kubectl get]]
===List all Pods on a Specific Node===
<syntaxhighlight lang='bash'>
kubectl get pods --all-namespaces -o wide --field-selector spec.nodeName=<node>
</syntaxhighlight>
Example:
<syntaxhighlight lang='bash'>
kubectl get pods --all-namespaces -o wide --field-selector spec.nodeName=ip-11-11-11-11.us-west-2.compute.internal
</syntaxhighlight>


==describe==
==describe==
Line 54: Line 65:


  [[Kubectl#POSTing_a_Manifest|kubectl apply]] -f <''pod-manifest-file-name''>.yaml
  [[Kubectl#POSTing_a_Manifest|kubectl apply]] -f <''pod-manifest-file-name''>.yaml
This manifest will create a httpd server that listens for requests:
<syntaxhighlight lang='yaml'>
apiVersion: v1
kind: Pod
metadata:
  name: 'httpd'
  labels:
    function: 'httpd'
spec:
  containers:
  - name: 'httpd'
    image: docker.io/ovidiufeodorov/httpd:latest
</syntaxhighlight>
Another example:
<syntaxhighlight lang='yaml'>
apiVersion: v1
kind: Pod
metadata:
  name: 'centos'
spec:
  containers:
  - name: 'centos'
    image: docker.io/centos
    command: ['sh', '-c', 'while true; do echo .; sleep 2; done;']
</syntaxhighlight>


=Execute Commands inside a Pod=
=Execute Commands inside a Pod=
Line 77: Line 116:
=Scaling Up and Down=
=Scaling Up and Down=


This usually involves one of the [[Kubernetes Higher Level Pod Controllers|higher level pod controllers]].
This usually involves one of the [[Kubernetes Workload Resources|workload resources]]:
* [[Kubernetes_Deployment_Operations#Scaling_Up_and_Down|Scaling Deployments Up and Down]]
 
=Updating Pods=
 
Pod metadata cannot be updated with kubectl get pod -o yaml → modify → kubectl apply -f except for very specific fields:
* spec.containers[*].image
* spec.initContainers[*].image
* spec.activeDeadlineSeconds
* spec.tolerations


kubectl scale --replicas=0 deployment <''my-deployment''>
This approach works to [[Kubernetes Deployment Operations#Updating_Deployments|update deployment configurations]], though.
kubectl scale --replicas=2 deployment <''my-deployment''>


=Troubleshooting Containers=
=Troubleshooting Containers=

Latest revision as of 23:26, 11 July 2023

Internal

Get Information about Pods

get

All pods in a namespace (or the default namespace if -n is not used):

kubectl [-n namespace] get pods|po

Monitor a pod and be notified when the status of the pod is changing:

kubectl get --watch pod <pod-name>

Get more columns in the output:

kubectl get -o wide pod <pod-name>

Along the default columns, we get IP, NODE, NOMINATED NODE, READINESS GATES.

More general options:

kubectl get

List all Pods on a Specific Node

kubectl get pods --all-namespaces -o wide --field-selector spec.nodeName=<node>

Example:

kubectl get pods --all-namespaces -o wide --field-selector spec.nodeName=ip-11-11-11-11.us-west-2.compute.internal

describe

kubectl describe pod <pod-name>

Logs

kubectl log <pod-name>

"Follow" logging:

kubectl logs -f <pod-name>

This shell command could be used to log a pod in such a way logging survives a pod restart:

while ! kubectl -n my-namespace logs -f my-pod; do sleep 1; done

If the pod has multiple containers, the target container can be specified with the --container flag:

kubectl logs ... --container <target-container-name> ...

Obtaining a Pod's Phase

kubectl-o jsonpath="{.status.phase}" get pod <pod-name>

Create Pods

A singleton pod can be created by posting a pod manifest to the API server with:

kubectl apply -f <pod-manifest-file-name>.yaml

This manifest will create a httpd server that listens for requests:

apiVersion: v1
kind: Pod
metadata:
  name: 'httpd'
  labels:
    function: 'httpd'
spec:
  containers:
  - name: 'httpd'
    image: docker.io/ovidiufeodorov/httpd:latest

Another example:

apiVersion: v1
kind: Pod
metadata:
  name: 'centos'
spec:
  containers:
  - name: 'centos'
    image: docker.io/centos
    command: ['sh', '-c', 'while true; do echo .; sleep 2; done;']

Execute Commands inside a Pod

Execute a command in the first container of the pod:

kubectl exec [-it] <pod-name> <command>

The -it flags make the exec session interactive and connects stdin and stdout of the terminal kubectl was executed from to the stdin and stdout of the process executing inside the first container of the pod.

If the pod has multiple containers, the target container can be specified with the --container flag:

kubectl exec ... --container <target-container-name> ...

Removing an Individual Pod

kubectl delete pod <pod-name>

Remove Immediately

kubectl delete pod <pod-name> --grace-period=0 --force

Scaling Up and Down

This usually involves one of the workload resources:

Updating Pods

Pod metadata cannot be updated with kubectl get pod -o yaml → modify → kubectl apply -f except for very specific fields:

  • spec.containers[*].image
  • spec.initContainers[*].image
  • spec.activeDeadlineSeconds
  • spec.tolerations

This approach works to update deployment configurations, though.

Troubleshooting Containers

This procedure applies to both application containers and init containers. The logs of a container can be accessed by identifying the name of the container (application or init) with

kubectl describe pod <pod-name>

or

kubectl get -o yaml get pod <pod-name>

then

kubectl logs -f -c <container-name> pod <pod-name>