Kubernetes

Container orchestration tool

What it is?

Definition

  • Container orchestration Tool by Google

  • Help manage containerized applications in different environment

Problem Solved

  • Increase microservices leads to increased usage of containers

  • Demand for proper way to manage hundreds of containers

  • High availability

  • Scalability

  • Disaster recovery

Architecture

  • At least 1 Master Node (Run important processes, API Server+Controller Manager+Scheduler+ETCD key value storage)+ Many Worker Node (Docker, Container, Apps in worker node, application running) through Virtual Network (Turn many machines into one uniformed machine)

Pod, Service, Ingress

Pod

  • Smallest unit of K8

  • Abstraction over container (Create running environment, a layer that is interacted with)

  • Usually 1 application per Pod (Also side services possible)

  • Each Pod get IP address and communicate using virtual network

  • They can die easily, new one will replace with a new IP address (Can be tiring to change IP each time it changes-->Use Service below)

Service

  • Permanent IP address attached to each pod

  • Lifecycle of Pod and Service NOT connected (Pod die doesn't affect Service)

  • External (Public API, HTTP of node IP address + Port number of service) & Internal (Private like database) Service

  • Load Balance between nodes

Ingress

  • Need url be like https://my-app.com instead of https://127.0.0.1:8080 for end product, so that Ingress is needed

  • Request goes to Ingress and forward to service

Config Map and Secret

  • Configure DB for application-->DB url is built in application-->New db url, need to rebuild app and push to repo and pull new image into pod (Frustrating!)

  • Therefore, ConfigMap:

    • External configuration of application

    • Adjust config map and no need to rebuild

    • Don't push credential into Config Map, so use Secret:

      • Used to store secret data

      • base64 encoded

Volumes

  • Attach physical storage hard drive to pod, can be local or remote (outside of K8 cluster)

Deployment Stateful Set

  • If application pod dies --> Downtime

  • So, replicate everything, replica connected to the service

  • Not define a second pod, but define blueprints for pods, define replica numbers

  • Pod=Abstraction of Container; Deployment=Abstraction of Pod

  • DB cannot be replicated via Deployment: because database has states, so use StatefulSet:

    • Take care of replicating pods, and insure database transaction consistency

    • Not easy to do, use DB that is host outside K8 cluster instead

How to use?

Minikube and Kubectl

Minikube

  • One node cluster where master and worker process on ONE machine to test locally

  • Run on local machine via Virtual Box

Kubectl

  • Interact with the cluster created by minikube

  • Command line tool for K8 to communicate with Api Server

  • Can be also communicate with Cloud clusters

Install Minikube

  • Virtual environment needed -- Hypervisor

Use Kubectl

  • kubectl get nodes to get status of minikube clusters

  • kubectl get pod / kubectl get services

  • kubectl create deployment NAME --image=image [--dry-run] [options] to create deployment and pods underneath it

  • kubectl logs [pod name] / kubectl describe pod [pod name] to see logs and status changing regarding the pods

  • kubectl exec -it [pod-name] -- bin/bash to get into pod's terminal, same as docker exec -it

  • kubectl apply -f [file name] to use the config file (name.yaml)

    • Sample config file:

apiVersion: apps/v1
kind: Deployment
metadata:
    name: nginx-deployment
    labels:
        app: nginx
spec: // Specification for deployment
    replicas: 1
    selector:
        matchLabels:
            app: nginx
    template:
        metadata:
            labels:
                app: nginx
        spec: // Specification for pods
            containers:
            -   name: nginx
                image: nginx:1.16
                ports:
                -   containerPort: 80

Last updated