Skip to main content

One Page | Kubernetes Notes

What is Orchestration​

  • Football coach analogy (from Kindle book) Team consists of players.
  • Coach makes sure that the team maintains its formations.

Thinking in Kubernetes​

  • Pods run in Nodes (physical devices)
  • Nodes can be added to the cluster (as in Rancher)
  • Pods are ephmeral (they come and go, as in replica changes)
    • Pods can hold one or more containers
    • Multicontainers access eachother with localhost
  • Deployments create stateless application workloads
  • Services are required to expose apps
    • Load Balancers are also services
    • Network access using service names
  • Ingress for routing, TLS etc.
  • Stateful Sets for persistent apps as in DBs
    • Need Persistent Volumes and Per Volume Claims
  • Secrets and Config maps provide meta data and env vars
  • Jobs and CronJobs uses pods to run and die after running.

Workloads​

ref

A workload is an application running on Kubernetes. On Kubernetes you run it inside a set of pods. In Kubernetes, a Pod represents a set of running containers on your cluster.

Workload Resources​

  • Deployment and ReplicaSet (replacing the legacy resource ReplicationController). Deployment is a good fit for managing a stateless application workload on your cluster

  • StatefulSet lets you run one or more related Pods that do track state somehow. For example, if your workload records data persistently, you can run a StatefulSet that matches each Pod with a PersistentVolume. Your code, running in the Pods for that StatefulSet, can replicate data to other Pods in the same StatefulSet to improve overall resilience.

  • DaemonSet defines Pods that provide node-local facilities. Every time you add a node to your cluster that matches the specification in a DaemonSet, the control plane schedules a Pod for that DaemonSet onto the new node.

  • Job and CronJob define tasks that run to completion and then stop. Jobs represent one-off tasks, whereas CronJobs recur according to a schedule.

    Run a Stateless Application Using a Deployment​

    ref

    Creating and exploring an nginx deployment​

    apiVersion: apps/v1

kind: Deployment

metadata: name: nginx-deployment

spec: selector: matchLabels: app: nginx

replicas: 2 # tells deployment to run 2 pods matching the template

template: metadata: labels: app: nginx

spec: containers:

      - name: nginx

image: nginx:1.14.2

ports:

            - containerPort: 80

kubectl apply -f https://k8s.io/examples/application/deployment.yaml

kubectl describe deployment nginx-deployment kubectl get pods -l app=nginx

kubectl describe pod pod-name


#### Scaling the application by increasing the replica count
```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 4 # Update the replicas from 2 to 4
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.16.1
        ports:
        - containerPort: 80

Services, Load Balancing, and Networking​

ref

Kubernetes networking addresses four concerns:

  • Containers within a Pod use networking to communicate via loopback.
  • Cluster networking provides communication between different Pods.
  • The Service API lets you expose an application running in Pods to be reachable from outside your cluster.
    • Ingress provides extra functionality specifically for exposing HTTP applications, websites and APIs.
  • You can also use Services to publish services only for consumption inside your cluster.

Ingress​

ref

What is Ingress? Ingress exposes HTTP and HTTPS routes from outside the cluster to services within the cluster. Traffic routing is controlled by rules defined on the Ingress resource.

Simple fanout - example​

A fanout configuration routes traffic from a single IP address to more than one Service, based on the HTTP URI being requested. An Ingress allows you to keep the number of load balancers down to a minimum. For example, a setup like:

arch

TLS​

You can secure an Ingress by specifying a Secret that contains a TLS private key and certificate.

Load balancing​

An Ingress controller is bootstrapped with some load balancing policy settings that it applies to all Ingress, such as the load balancing algorithm, backend weight scheme, and others. More advanced load balancing concepts (e.g. persistent sessions, dynamic weights) are not yet exposed through the Ingress.