Menu

Kubernetes Basics

Terms

API Server

  • This runs on the Master Node.  This is how users communicate with the Kubernetes service.
    • Think of this as the Cluster Gateway
    • UI, Kubernetes dashboard
    • Command line tool like Kubelet
    • API, etc.
  • Used for
    • Updates into the Cluster
    • Queries from the Cluster
    • Gatekeeper for authentication
  • This process is itself a container.

Container

  • These are often Docker containers, but any container technology should be fine.

Controller Manager

  • Detects state changes
    • Crashing of Pods
  • When detected, makes a request to the Scheduler
  • Is a container

etcd (et-see-dee)

  • Key: Value store of the Cluster state
  • Think of etcd as the Cluster Brain
  • Every change in a Cluster is stored here.
    • New Pod gets scheduled
    • Pod Dies
  • Scheduler and Controller Manager rely on this data
  • Does NOT store Application Data!
  • Will create distributed storage across multiple Master Nodes
  • allows for snapshots so state of cluster can be restored.

DB Service

  • Like a Load Balancer.
  • Catches requests from services and directs them to the respective Pod

Kubelet

  • Interacts with the Container Runtime and the Note itself
  • Starts and runs the pods with a container inside.
  • Assigns resources from the Node to the container. (CPU, RAM, Storage resources)
  • Must be running on every Worker Node

Kube Proxy

  • Forwards requests from Services to Pods
  • Intelligent logic
    • Communication is performed in a performant manor with low overhead.
    • If a container requests resources from another container, it will first check to see if the other container is available locally to reduce network traffic.
  • Must be running on every node.

Namespace

  • Organize resources in Namespaces
  • Multiple Namespaces may be used in a Cluster
    • Like a virtual cluster within a Cluster
  • Default Namespaces (OOB)
    • default
      • Used to create resources if you have not created any other namespaces
    • kube-node-lease (New)
      • Heartbeats of nodes
      • Each node has associated leased object that determines the availability of a node.
    • kube-public
      • Publicly accessible data
      • A config map that contains cluster information
        • Accessible even without authentication!
    • kube-system
      • System resources only – DO NOT create nor modify anything in this namespace.
      • System processes
      • Master and Kubectl processes
    • kubernetes-dashboard
      • Specific to minikube installation. Not available in standard clusters

Nodes or Worker Nodes

  • The server or VM that is running Kubernetes Pods
  • There are generally many nodes in a Cluster
  • At a Minimum, Each Nodes must be running:
    • Container Runtime (Docker or other containerization technology)
    • Kubelet
    • Kube Proxy
  • Require more resources than Master Nodes

Masters or Master Nodes

  • Control
    • How to schedule a Pod
    • Node and Pod monitoring
    • Reschedule / restart Pods
    • Add new Nodes to the cluster
  • Required services
    • API Server
    • Scheduler
    • Controller Manager
    • etcd
  • Master Nodes require less resources than Worker Nodes
  • Master nodes more important than Worker Nodes
    • If you lose your master, you will lose access to your cluster!
    • This should always be N+1!

Pod

  • Think of Pods as containers for containers.  Since each Pod is assigned its own IP, you can have multiple Pods running the same ports/processes on the same Node
    • When Pods die, the new Pod will get a new IP address.
  • Generally, 1 pod = 1 container, but this is not a requirement.

Scheduler

  • Determines which node to start new Pods
    • Checks resources required by the Pod (CPU/Ram)
    • Checks resources available on Worker Nodes
  • Note: Does not actually start the Pod.  This is done by Kubelet.
  • Must be running on each Master Node
  • Is a container

Services

  • Sit in front of each Pod.  Think of these as replacements for IP addresses.
  • If a Pod dies and is replaced, the Service stays since it is not tied to the Pod.
    • Provides a static IP to the Pod
    • Acts as a load balancer
  • Assigned by URL
    • Example: SERVICENAME-NAMESPACE
  • Services can be shared between Namespaces

Adding Additional Master/Worker Nodes

  1. Start with a bare server
  2. Install the required processes
    1. Worker
      1. Container runtime (Docker or similar)
      2. Kubelet
      3. Kube Proxy
    2. Master
      1. API Server
      2. Scheduler
      3. Controller Manager
      4. etcd
  3. Add it to the cluster

Namespaces

Create new namespaces

  • CLI
kubectl create namespace <NAMESPACE-NAME>
  • Namespace Configuration Files

Why use Namespaces

  • Great way to organize your cluster.
    • Multiple deployments, replicas of many pods, services, configmaps
  • Multiple Teams, same cluster
    • Both teams have a depoyment of the same name.  When team 2 updates their deployment, it would override team 1’s.
  • Hosting Staging and Production in the same cluster
  • Different Application versions
    • GR, Dev
    • Both could use common, shared resources.
  • Access Limits on Namespaces
    • Prevent users from different teams from accessing other namespaces.
  • Limit resources
    • Assign CPU, RAM and Storage per namespace.

Namespace Limitations

  • You cannot share Configmaps between Namespaces.
    • Each namespace will require its own Configmap
  • You cannot assign Volumes or Nodes to a Namespace.
    • These belong to the Cluster.

 

Last posts

Sidebar