Summary fc

position ease box interval due
front 2.20 0 0.00 2021-08-31T08:00:10Z

Master Node Components

  1. kube-api-server frontend of kuberentes control plane. user sends requests as yaml/json format request
  2. etcd distributed key-value store for cluster state: brain of cluster.
  3. kube-scheduler manages new requests from api-server and assigns them to healthy nodes.
  4. kube-controller manager control loop to maintain state of cluster.

Worker Node Components

  1. Kubelet
    1. agent that runs on each worker node and communicates with master node.
    2. makes sure that container is healthy.
    3. watches for tasks from the API server, executes tasks such as deploy or destroy and reports back to master
  2. Kube-proxy used to communicate between containers of multiple worker nodes.
  3. Pod
    1. one or more container deployed together on the same host.
    2. Can be considered as container of containers
    3. pod is an abstraction over container and deployment is an abstraction over pod
    4. deployment is a management tool for pod.
  4. Container Runtime Software responsible for running containers. e.g. Docker.

Concepts fc

position ease box interval due
front 2.65 3 6.00 2021-10-25T16:11:54Z

ref

What is Kubernetes?

Kubernetes is a portable, extensible, open-source platform for managing containerized workloads and services, that facilitates both declarative configuration and automation. It has a large, rapidly growing ecosystem. Kubernetes services, support, and tools are widely available.

Workloads

  • A workload is an application running on Kubernetes.
  • Whether your workload is a single component or several that work together, on Kubernetes you run it inside a set of pods.
  • In Kubernetes, a Pod represents a set of running containers on your cluster.

What is a Pod?

Pods are the smallest deployable units of computing that you can create and manage in Kubernetes. ref

A Pod (as in a pod of whales or pea pod) is a group of one or more containers, with shared storage and network resources, and a specification for how to run the containers

A Pod’s contents are always co-located and co-scheduled, and run in a shared context. A Pod models an application-specific “logical host”: it contains one or more application containers which are relatively tightly coupled. In non-cloud contexts, applications executed on the same physical or virtual machine are analogous to cloud applications executed on the same logical host.

Kubernetes deployments vs. pods

ref In short, a pod is the core building block for running applications in a Kubernetes cluster; a deployment is a management tool used to control the way pods behave. Let’s take a closer look at when and where to use pods and deployments. ref Pods are the smallest, most basic deployable objects in Kubernetes.

  • A Pod represents a single instance of a running process in your cluster .
  • Pods contain one or more containers, such as Docker containers.
  • When a Pod runs multiple containers, the containers are managed as a single entity and share the Pod’s resources Generally, running multiple containers in a single Pod is an advanced use case.

Kubernetes Components

A Kubernetes cluster consists of the components that represent the control plane and a set of machines called nodes.

  • ConfigMaps

    A ConfigMap is an API object used to store non-confidential data in key-value pairs. Pods can consume ConfigMaps as environment variables, command-line arguments, or as configuration files in a volume.

    A ConfigMap allows you to decouple environment-specific configuration from your container images, so that your applications are easily portable.

    Caution: ConfigMap does not provide secrecy or encryption. If the data you want to store are confidential, use a Secret rather than a ConfigMap, or use additional (third party) tools to keep your data private.

  • Secrets

    Kubernetes Secrets let you store and manage sensitive information, such as passwords, OAuth tokens, and ssh keys. Storing confidential information in a Secret is safer and more flexible than putting it verbatim in a Pod definition or in a container image. See Secrets design document for more information.

    A Secret is an object that contains a small amount of sensitive data such as a password, a token, or a key. Such information might otherwise be put in a Pod specification or in an image. Users can create Secrets and the system also creates some Secrets.

    • Caution:

      Kubernetes Secrets are, by default, stored as unencrypted base64-encoded strings. By default they can be retrieved - as plain text - by anyone with API access, or anyone with access to Kubernetes' underlying data store, etcd. In order to safely use Secrets, it is recommended you (at a minimum):

      • Enable Encryption at Rest for Secrets.
      • Enable or configure RBAC rules that restrict reading and writing the Secret. Be aware that secrets can be obtained implicitly by anyone with the permission to create a Pod.

Working with Kubernetes Objects

Kubernetes objects are persistent entities in the Kubernetes system. Kubernetes uses these entities to represent the state of your cluster . Learn about the Kubernetes object model and how to work with these objects.

Understanding Kubernetes objects

ref Kubernetes objects are persistent entities in the Kubernetes system. Kubernetes uses these entities to represent the state of your cluster . Specifically, they can describe:

  • What containerized applications are running (and on which nodes)

  • The resources available to those applications

  • The policies around how those applications behave, such as restart policies, upgrades, and fault-tolerance

    A Kubernetes object is a “record of intent”–once you create the object, the Kubernetes system will constantly work to ensure that object exists. By creating an object, you’re effectively telling the Kubernetes system what you want your cluster’s workload to look like; this is your cluster’s desired state.

    To work with Kubernetes objects–whether to create, modify, or delete them–you’ll need to use the Kubernetes API. When you use the kubectl command-line interface, for example, the CLI makes the necessary Kubernetes API calls for you. You can also use the Kubernetes API directly in your own programs using one of the Client Libraries.

  • Describing a Kubernetes object

    When you create an object in Kubernetes, you must provide the object spec that describes its desired state, as well as some basic information about the object (such as a name).

    Example:

    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
    
    • apply command

      One way to create a Deployment using a .yaml file like the one above is to use the kubectl apply

      kubectl apply -f https://k8s.io/examples/application/deployment.yaml --record
      
    • 4 Required fields

      ref In the .yaml file for the Kubernetes object you want to create, you’ll need to set values for the following fields:

      1. apiVersion - Which version of the Kubernetes API you’re using to create this object
      2. kind - What kind of object you want to create
      3. metadata - Data that helps uniquely identify the object, including a name string, UID, and optional namespace
      4. spec - What state you desire for the object

Services

Cluster Architecture fc

position ease box interval due
front 2.65 3 6.00 2021-08-13T07:38:56Z

Node

Kubernetes runs your workload by placing containers into Pods to run on Nodes. A node may be a virtual or physical machine, depending on the cluster. Each node is managed by the control plane and contains the services necessary to run Pods.

Control Plane-Node Communication

This document catalogs the communication paths between the control plane (apiserver) and the Kubernetes cluster. The intent is to allow users to customize their installation to harden the network configuration such that the cluster can be run on an untrusted network (or on fully public IPs on a cloud provider).

Controllers

In robotics and automation, a control loop is a non-terminating loop that regulates the state of a system.

Here is one example of a control loop: a thermostat in a room.

When you set the temperature, that’s telling the thermostat about your desired state. The actual room temperature is the current state. The thermostat acts to bring the current state closer to the desired state, by turning equipment on or off.

In Kubernetes, controllers are control loops that watch the state of your cluster, then make or request changes where needed. Each controller tries to move the current cluster state closer to the desired state.

Running it locally

Best way to run locally is by using MiniKube

Start kubernetes cloud with non root user

why docker container should be run as non root user?

Minikube for development

Installation

ref

curl -LO https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64
sudo install minikube-linux-amd64 /usr/local/bin/minikube

# then
minikube start
minikube stop

# to use kubectl instead of minikube kubectl
ln -s $(which minikube) /usr/local/bin/kubectl

Install kubectl command

Actual kubectl

ref

curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl"
curl -LO https://dl.k8s.io/release/v1.21.0/bin/linux/amd64/kubectl
sudo install -o root -g root -m 0755 kubectl /usr/local/bin/kubectl

Installing Kubernetes

Deploying Services on Kubernetes

Elastic Cloud in Kubernetes

Kubernetes CS

Tutorial

Kubernetest the Hardway Docker and Kubernetes The complete guide

Delete namespace, when stuck

Following this steps worked: https://computingforgeeks.com/how-to-force-delete-a-kubernetes-namespace/

Manifest files to fetch images from private repository

apiVersion: v1
kind: Pod
metadata:
  name: private-reg
spec:
  containers:
  - name: private-reg-container
    image: <your-private-image>
  imagePullSecrets:
  - name: regcred
kubectl create secret generic regcred \
    --from-file=.dockerconfigjson=<path/to/.docker/config.json> \
    --type=kubernetes.io/dockerconfigjson

ref regcred should be in the same workspace.