Kubernetes Pod Operations: Difference between revisions

From NovaOrdis Knowledge Base
Jump to navigation Jump to search
No edit summary
 
(38 intermediate revisions by the same user not shown)
Line 2: Line 2:


* [[Kubernetes Operations#Subjects|Kubernetes Operations]]
* [[Kubernetes Operations#Subjects|Kubernetes Operations]]
* [[Kubernetes_Pod_and_Container_Concepts|Pod and Container Concepts]]


  kubectl get pods|po
=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|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==


  kubectl describe pod <''pod-name''>
  kubectl describe pod <''pod-name''>
==Logs==


  kubectl log <''pod-name''>
  kubectl log <''pod-name''>


=Create a Pod=
"Follow" logging:
 
kubectl logs -f <''pod-name''>


==From a Manifest==
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''>
=<span id='Create_a_Pod'></span>Create Pods=
A [[Kubernetes Pod and Container Concepts#Singleton_Pod|singleton]] pod can be created by posting a [[Kubernetes_Pod_Manifest#Example|pod manifest]] to the API server with:
[[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'>
<syntaxhighlight lang='yaml'>
apiVersion: v1
apiVersion: v1
kind: Pod
kind: Pod
metadata:
metadata:
   name: loop-pod
   name: 'httpd'
  labels:
    function: 'httpd'
spec:
spec:
   containers:
   containers:
   - name: loop-container
   - name: 'httpd'
     image: loop:1
     image: docker.io/ovidiufeodorov/httpd:latest
</syntaxhighlight>
</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 a command in the first container of the pod:
kubectl exec [-it] <''pod-name''> <''command''>
The <tt>-it</tt> 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=
=Removing an Individual Pod=


Remove immediately:
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 [[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
 
This approach works to [[Kubernetes Deployment Operations#Updating_Deployments|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 delete pod ''pod-name'' --grace-period=0 --force
  kubectl logs -f -c <''container-name''> pod <''pod-name''>

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>