kubectl: create pod

Let’s try creating a pod.

  1. create a pod.ymlwith your favourite image:

 

Then:

kubectl create -f pod.yml

returns

pod/hello-pod created

but we need to check what’s going on behind the scenes with:

kubectl get pods

Or if you have loads of pods, you can use:

kubectl get pods/hello-pod

or all pods in all namespaces:

kubectl get pods --all-namespaces

“kubectl get pods” warnings

kubectl get pods
NAME READY STATUS RESTARTS AGE
hello-pod 0/1 ContainerCreating 0 1m

kubectl describe pods

This:

Reason: ContainerCreating

is because it’s still creating the container.

kubectl get pods
NAME READY STATUS RESTARTS AGE
hello-pod 0/1 ImagePullBackOff 0 10m

Again:

kubectl describe pods

Reason: ImagePullBackOff

means there’s a problem with the image.

Check with:

docker inspect --type=image <name of image>:latest

I was getting:

Error: No such image:

So, let’s try another image. i.e. in pod.ymllet’s use:

image: hello-world:latest

Now create hits:

 

Let’s try deleting this pod with:

https://kubernetes.io/docs/tasks/run-application/force-delete-stateful-set-pod/

 

Let’s try --all as mentioned:

Solution is:

Note: this can take a few minutes.

https://kubernetes.io/docs/tasks/run-application/force-delete-stateful-set-pod/

 

Let’s try create again:

What is a CrashLoopBackOff? How to alert, debug / troubleshoot, and fix Kubernetes CrashLoopBackOff events.

Why am I getting this?

‘cos the hello-world image exits after printing out its introductory message.

Let’s try:

image: yeasy/simple-web:latest

We can keep track of events with:

kubectl get events

After around 5 mins it comes up. Let’s interact with the web server. First what IP does it have?

kubectl get pods -l zone=prod -o yaml | grep IP

kubectl get pods
NAME READY STATUS RESTARTS AGE
hello-pod 1/1 Running 0 12m

kubectl exec -it hello-pod — /bin/bash

and

curl -i localhost:80

shows it’s working.

 

Note: you’d normally deploy a pod using a ReplicationController.

Delete existing pod with:

kubectl delete pods hello-pod

and create a ReplicationController with:

Note: 4 top-level objects are:

  • apiVersion
  • kind
  • metadata
  • spec

then

kubectl create -f rc.yml

And inspect with:

To increase replicas, update rc.yml and apply with:

kubectl apply -f rc.yml

 

Other errors

Unable to connect to the server

Unable to connect to the server: dial tcp 192.168.64.5:8443: i/o timeout

  • check minikube is started – minikube start

kubectl describe pods

 

 

 

Kubernetes Architecture – Master, apiserver {}, Nodes, Pods, Services, Deployments – the basics

A Kubernetes architecture comprises masterand worker nodes.

Master (a.k.a control plane)

  • keep free of user workloads
  • apiserver {} – front-end to the control plane and should be the only component we should speak to (i.e. we send the Manifest files to this)
  • Cluster Store – persistent storage (i.e. the memory) – currently uses etcd (an OpenSource Key-Value store) as the source of truth for the cluster. Only stateful part.
  • kube-controller-manager – Controller of controllers – node, endpoints, namespace controllers – watch for changes and help maintain desired state
  • kube-scheduler – watches apiserver for new pods and assigns work to nodes

Multi-master soon.

apiserver {}

  • Aka master cos we only speak to it rather than the other components
  • port 443
  • kubectl sends commands in JSON to it
  • It then talks to the other components and commands get sent out to nodes

Node (a.k.a “Minions”)

Kubernetes Workers

  • Kubelet
    • main Kubernetes agent on the node
    • registers node with cluster
    • watches apiserver
    • instantiates pods
    • reports back to master
    • exposes endpoint on :10255 (lets you inspect your node – e.g. /spec, /healthz, /pods)
  • Container Engine
    • Container management
      • pulling images
      • starting / stopping containers
    • Pluggable
      • usually Docker
      • can be rkt
  • kube-proxy
    • Kubernetes networking
      • Pod IP addresses
        • All containers in a pod share a single IP
      • Load balances across all pods in a service

Desired State and the Declarative Model

  • declare to apiserver{} using Manifest file (which describes desired state)

Pods

  • Containers always run inside of pods
  • Pods can have multiple containers
  • All containers in the pod share pod environment – e.g. volumes, IP address, IPC namespace – e.g. web server (main) and log scraper (sidecar)
  • Scaling – unit of scaling is a Pod. i.e. you don’t add containers to a Pod, you add Pods (each with a container)
  • Pods are Atomic – Pod is never declared up and available until it’s completely up (i.e. when Manifest file is given to apiserver it’s lifecycle goes Pending -> Running -> Succeeded in which case it’s declared up. Alternatively it goes into the Failed state).
  • Deployed via Manifest file or Replication Controller (superceded a bit now by Deployments)

Services

Every new pod gets a new IP => IP churn

Service object (declared using a Manifest) – sits between backend and frontend and load balances using IP and DNS.

Pod belongs to a Service via a Label.

Label ties Pod to Service.

Deployments

  • Self documenting
  • Versioned
  • Spec-once deploy-many
  • Simple rolling updates and rollbacks
  • REST objects
  • Deployed via YAML or JSON manifests
  • Deployed via the apiserver
  • Add features to Replication Controllers (Replica Sets – next generation Replication Controllers – i.e. RC v2)

Multiple concurrent versions:

  • Blue-green deployments
  • Canary releases
  • Simple versioned rollbacks