Kubernetes

Basic Architecture

kubectl

Useful commands

# Load the kubectl completion code for bash into the current shell, install of bash-completion required
source <(kubectl completion bash)

# Get all namespace
kubectl get ns

# Get pod/nodes list
kubectl -n {namespace} get nodes
kubectl -n {namespace} get pods

# Get more info of pod
kubectl -n {namespace} get pods -o wide
kubectl -n {namespace} get pods -o yaml

# Get specific node
kubectl get nodes {node_name} 

# Get specific node with detailed information
kubectl get nodes {node_name} -o wide

# Get node info in json/yaml format
kubectl get nodes {node_name} -o json
kubectl get nodes {node_name} -o yaml

# Get info of node current status, useful for debugging
kubectl describe node {node_name}

# Get cluster information
kubectl version
kubectl cluster-info
kubectl api-versions
kubectl api-resources

# Get explanation for resource details, hierarhcy of info can be accessed through '.' chaining
kubectl explain
kubectl explain pod
kubectl explain pod.spec

# Show details of a specific resource or group of resources.
kubectl describe pod


# Print container log
kubectl -n {namespace} logs -f {container_name}
kubectl -n {namespace} logs --since=5m {container_name}

# Execute command in container
kubectl -n {namespace} exec {container_name} -- ls

# Get interactive terminal in container
kubectl -n {namespace} exec -it {container_name} -- bash

# Apply yaml
kubectl apply -f {yaml_path}

# Delete resource included in yaml
kubectl delete -f {yaml_path}

# Delete pod resource
kubectl delete pod {pod_name}

# Forward local port to container port, starts a proxy
# locally requires another terminal when running
kubectl port-foward pod/{pod_name} {local_port}:{container_port}

# Add/delete label to node
kubectl label node {node_name} key=value  # Adds a key:value label
kubectl label node {node_name} key-       # Remove key:value label

YAML

There are five status that describes a kubernetes object, four of which is required:

• apiVersion
• kind
• metadata
• spec

Deployment Types

In practice, pods rarely get deployed directly even it's the smallest unit of deployable unit since they get deleted on crash. So simply deploying a pod is often used for testing only.

To provide a more high-level mechanism to handle a broad range of application development and deployment needs, different deploymet configuration types are offered.

Deployment

Deployment is arguably the most used deployment configuration, it has features such as:

• Capable of managing multiple identical replica pods of same images, tags, etc.
• Replica pods may spreard unevenly across nodes
• Pod spec defined under spec.template
• Deployment object manages multiple ReplicaSet objects, and a ReplicaSet object manages multiple pods
• Deployment object binds all related pods through defined pod labels (spec.template.metadata.labels)
• Often used GitOps to perform deploy/rollback of Deployment

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx                   # deployment label, indicate what pod level to select  
  template:
    metadata:
      labels:
        app: nginx                 # pod level label
    spec:
      containers:
        - name: nginx
          image: nginx:1.14.2
          ports:
            - containerPort: 80
      nodeSelector:
        env: test                  # selector rules for node object

To rollback a deployment, use below command:

kubectl rollout undo deployment/{deployment_name}

But manually rollbacking is not a good practice, it is often combined with Git and take advantage of git's version control ability. When deployment yaml is modified, a new version is committed through git. A rollback can be as simple as reverting to next commit and reapply the deployment.

Once the deployment has been successfully rolled out, it generates a replicaSet object which is in charge of managing all pod replicas.

A ReplicaSet's purpose is to maintain a stable set of replica Pods running at any given time. As such, it is often used to guarantee the availability of a specified number of identical Pods.

replicaSet and pod are all given a hash value, so an unique identifier for a pod after applying a yaml file will be:

{podname}-deployment-{replicaSet hash}-{pod hash}

DaemonSet

Job/CronJob

StatefulSet

References

• Kubernetes Official Documentation

---