Kubernetes Pod Operations: Difference between revisions
No edit summary |
|||
(31 intermediate revisions by the same user not shown) | |||
Line 6: | Line 6: | ||
=Get Information about Pods= | =Get Information about Pods= | ||
kubectl get pods|po | ==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''> | ||
"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''> | |||
=<span id='Create_a_Pod'></span>Create Pods= | =<span id='Create_a_Pod'></span>Create Pods= | ||
Line 17: | 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 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 | 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 | 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>