• Kubernetes
• Kubernetes In Action
• Kubernetes In Action Second Edition

Why K8S

Developer VS Operations

Let developers and operations do what they’re good at

• operations
  • In charge of production deployment, hardware facilities
  • Concerns about system security, utilization, and other aspects that developers don’t pay attention to
  • Don’t want to deal with the dependencies inherent in the application
  • Don’t want to change the underlying system or infrastructure to affect the application
• The development of
  • Love developing new features to improve the user experience
  • Do not want to participate in the underlying system processing, want to leave the management to operation and maintenance

K8S achieves the above objectives:

• By abstracting the hardware, a separate management platform is exposed

• Enables developers to configure and deploy applications

• Monomer to microservice

• The conundrum of microservices

• A server running multiple microservice conflicts

• Virtual machine isolation VS container isolation

• APPS in multiple VMS vs multiple containers

• Docker run

• VM VS container

K8S

• The framework

Container technology

• Namespace: Isolated environment
  • Mount(mnt)
  • ProcessID(PID)
  • Network(NET)
  • Inter-Process Communication(IPC)
  • UTS
  • User ID(user)
• CGroups: Limit resources used, CPU, broadband, memory, etc

Docker

• Images: contains the application and its environment, composed of Image Layers
• Registries: mirror center
• Containers: isolates resources

The sample

const http = require('http');
const os = require('os');

console.log("Kubia server starting...");

var handler = function(request, response) {
  console.log("Received request from " + request.connection.remoteAddress);
  response.writeHead(200);
  response.end("You've hit " + os.hostname() + "\n");
};

var www = http.createServer(handler);
www.listen(8080);
Copy the code

• Dockerfile
  • FROM: basic image for integration
  • ADD: Adds content
  • ENTRYPOINT: indicates the command executed

FROM node:7
ADD app.js /app.js
ENTRYPOINT ["node"."app.js"]
Copy the code

$ docker build -t kubia .
Copy the code

• Docker image composition

• Docker VS Virtual machine

Run the contrast

• Bare metal, virtual machine, Docker

• Docker core development process

Kubernetes

Benefits:

• Simplify Application Deployment
• Better use of hardware resources
• Monitoring detection and self-repair
• Automatic expansion
• Simplify application development

K8S cluster

conclusion

• Individual services are easy to deploy, but difficult to expand, maintain, and develop
• Microservices are convenient to develop each module, but difficult to deploy and configure like individual services
• Linux containers offer some of the benefits of virtual machines, but are lighter and make better use of hardware resources
• Docker improves existing Linux container technology, making it faster and easier to package applications
• Kubernetes exposes the data center to the application as a single computable resource
• Application developers can deploy applications themselves through Kubernetes without the help of system operation and maintenance
• O&m personnel can automatically manage the failed node and retry

Based on the component

• Master
  • K8S API Server: Communication
  • Scheduler: Allocates resources
  • Controller Manager: Controls, such as replication, tracking failed nodes, etc
  • Etcd: distributed storage and storage configuration information
• Worker
  • Containers: Docker or other containers
  • Kubelet: Communication API Server, control container
  • Kube-proxy: load balancer

Operation and maintenance responsibilities

NameSpace

• Belongs to the namespace:
  • pod
  • service
  • ReplicatSet
  • Deployment
  • PVC(Persistent Volume Claim)

  .

• Does not belong to a namespace
  • node
  • PV(persistent volume)
  • namespace

Node

Pod

• A POD can run multiple containers (preferably associated processes)

• As a service unit that can run independently, Pod simplifies the difficulty of application deployment and provides great convenience for application deployment management with a higher level of abstraction.

• As the smallest application instance, Pod can run independently, facilitating deployment, horizontal expansion and contraction, scheduling management, and resource allocation.

• Containers in Pod share the same data and network address space, and unified resource management and allocation is carried out among PODS.

Implementation process

POD network Allocation

Using the principle of

• A container should not run multiple processes
• If two containers do not need to run on the same machine, they should not be in a pod

Yml configuration

Label

Group pods by label

• nodeSelector

Annotating

ReplicationController

Three elements

• Label Selector: Range controlled by RC
• Replica Count: Controls the number of Pods
• Pod template: Create a pod to use

Update the POD template, which will not be replaced until the pod is deleted

ReplicaSet

• ReplicationController upgrade version,

DaemonSet

• With the label the selector

Job/CronJob

• Parallel or serial

• Completions: Indicates the number of executions
• Parallelism: parallelism number
• ActiveDeadlineSeconds: Limits the execution time

CronJob

• StartingDeadlineSeconds: Indicates the latest time to delay the startup

Service

The problem of POD providing services externally

• Pod is ephemeral and can be hung up at any time
• K8S assigns a static IP address to pod after pod is assigned to Node and before POD is started, so that the client cannot extract the address of pod service
• Horizontal scaling means that multiple pods may provide the same service, each with its own address. The client wants to access the POD service from a single address

The usefulness of the Service

• Fixed IP and port, external output service, load balancer

Configure consistent access based on IP fixed routes! Referenced by port name

Service discovery

NodePort Service

LoadBalancer

Ingress

Has advantages that Service does not have

• Cookie-based affinity

• The Ingress Controller finds the POD through the Service and forwards it directly, without going through the Service

Access multiple services through ingress Map different hosts

• The TLS Ingress processing

Service startup problems

• readiness probe
  • Exec probe
  • Http Get probe
  • TCP Socket probe

Differences from LiVENESS Probe:

• Liveness keeps the POD cluster alive by replacing unhealthy PODS
• Only monitored PODS can accept requests for services. Readiness Probe

Add a Readiness probe to the POD

Volumes

Mount hard disks to containers

• Each container has its own file system. When the container is restarted, the contents of the file system are lost
• Volume is part of the POD lifecycle, so restarted containers can see what was saved in the previous container
• A volume under a POD can be shared by multiple containers
• Each container can mount volume anywhere on its own file system

Volume type

• EmptyDir: Empty directory for storing ephemeral data
• HostPath: Mount the Work node to the POD file system
• ConfigMap, Secret, downwardAPI: Special types of volumes used to expose K8S resources and cluster information to PODS
• PersistentVolumeClaim: Uses preset or dynamic storage
• GitRepo: Volume is initialized from the Git repository
• NFS: The NFS system is mounted to a POD
• gcePersistentDisk (Google Compute Engine Persistent Disk), awsElastic BlockStore (Amazon Web Services Elastic Block Store Volume), azureDisk

(Microsoft Azure Disk Volume) : mount storage of the cloud provider

• Cinder, CEPHfs, iscsi, Flocker, Glusterfs, Quobyte, RBD, flexVolume, vsphere Volume, photonPersistentDisk, scaleIO: Storage of other network types

EmptyDir Select volume media

gitRepo

hostPath

External storage

Decouple the underlying storage technology from PODS

PersistentVolumes PersistentVolumeClaims

• Only the administrator needs to deploy the underlying storage and register in the K8S cluster through PV, and can control the PV control size and access mode
• The user creates the PVC, describes the usage size and access method, and submits it to the K8S API Server, which is responsible for finding the suitable PV to bind to the PVC
• PV does not belong to any namespace

PVC

permissions

• Rwo-readwriteonce: Only a single node can mount volume for reading and writing
• Rox-readonlymany: Multiple nodes can mount volumes and read volumes
• RWX-ReadWriteMany: Multiple nodes can mount volumes for reading and writing

PVC is used in POD

Distinguish from others

PersistentVolumeReclaimPolicy: + Retain: reservation, can’t be reused + Recyle: Delete the content, can be the claim again repeated use, can be used by different PVC + Delete: Delete the storage

StorageClass- Provides PV dynamically

Users are more independent in choosing suppliers

• The claim in the PVC StorageClass

StorageClass PVC is used in

For an easier way, do not use StorageClass

Use the default pv

ConfigMap

You can configure the application as follows:

• The container command line passes parameters
  • The packaging container uses ENTRYPOINT to specify the commands to execute after the container is started
  • CMD: Passes the ENTRYPOINT parameter

Overwrite commands in POD

• Add environment variables to the container

Disadvantages:

• Configuration is merged with POD files, resulting in different pod files that must be defined for different environments and cannot be reused!

The decoupling

• Container Mount the special volume configuration file

Environment variable +ConfigMap

Different sources of ConfigMap

Env references ConfigMap in POD

Envs in POD are all from ConfigMap

The POD command line references ConfigMap

ConfigMap Volume

• SubPath path

• DefaultMode permissions

Secret

• K8S ensures that each Secret is distributed only to nodes where it is needed (run the associated pod)
• Node stores Secret in memory and never writes to hard disk
• The Secret configuration needs to be stored on encrypted storage

plain text

Downward API

Expose the POD metadata information to the container running in the POD:

• Pod noun
• pod ip
• pod namespace
• pod node name
• CPU information requested by each container
• CPU upper and lower limits for each container
• The label of pod
• The annotation of pod

Exposure through environmental variables

Exposure via downwardAPI Volume

Exposure via K8S RestAPI kubectl proxy

Talk to K8S API Server

ambassador

Client library connection

Deployment

Upgrade the POD step

• Delete the existing pod before starting the new pod

• Start the new pod and then delete the old pod

Toggle label selector, toggle service once

• Rolling Update (deprecated)

imagePullPolicy

• Always
• IfNotPresent

Rolling update

Use kubectl rolling-update command

Change the label request to route to both v1 and V2 versions

Deprecating rolling Update:

• Changed the label of the pod
• Changed the ReplicateController label selector
• The update process is completed by the client requesting the server. If the network is faulty, the update fails

Use Deployment declarative changes

• Deployment is a higher-level resource management tool
• Deployment uses declarative changes, which are handled by K8S
• Deployment can have multiple versions of PODS at the same time, and app versions should not be referenced in metadata
• Hiding deployment details
• It can be automatically rolled back

The sample

RollingUpdate strategy

• Set: Delete the old POD and then create a new pod

Modify resource commandsprocess

The fallback

Deployment history manages deployments like Git Parameter revisionHistoryLimit: limits the number of historical nodes. RollingUpdate: maxSurge: Allows the maximum number of nodes in a Deployment process to exceed replicaCount. MaxUnavailable: Allow Update to allow the maximum proportion of unserviceable pods

pause resume deployment

Readiness probe

MinReadySeconds Effect: When the container is started, the minimum time required to return to ready allows for readiness probe. If the probe fails, the deployment update will be blocked! progressDeadlineSeconds

StatefulSet

Stateless pod and stateful PODUsing shared PV, the volume ConfigMap Storage saves the status Each POD is assigned a ReplicaSet Same volume, separate directory for each pod Question:

• Cannot be configured with a POD template,
• Each redeployment upgrade generates a new POD name and IP address

Service with a fixed IP address

StatefulSet

Each POD retains status and identification information when it is redeployed

Each pod a – fixed domain 0. Foo default. SVC. Cluster. The local update pod process

Extend StatefulSet, sequential additions and deletionsAchieve POD PVC template separation

When scale down, you need to manually delete the PVC and randomly delete the stored data on the POD

The sampleDuring the deployment, one POD is started and the next one is deployed in sequence to view the details

Redeployment process

SRV record mapping service and hostname:port

Deep understanding of K8S

Understand the architecture

• Control Plane
  • Etcd distributed storage
  • API Server
  • Scheduler
  • Controller Manager

• Worker nodes
  • Kubelet
  • kube-proxy
  • Container Runtime(Docker, rkt, others)

• Add – on the plug-in
  • Kubernetes DNS Server
  • The Dashboard
  • Ingress Controller
  • Heapster
  • Container Network Interface network plugin

• Components communicate with each other through the API Server. Components do not communicate directly. Only the API Server connects to etCD

• Etcd: storage cluster status and metadata

Etcd distributed storage brain split problem

API Server

Register listening mode to listen for changes

Scheduler

• Find the node that matches the hardware resource request

Controller Manager

The deployment process

The Controller class

• ReplicaSet
• Deployment
• StatefulSet
• Node
• Service
• Endpoint
• Namespace
• PersistentVolume

The Controller coordination between

Pod between network

There is no NAT

Service Implementation Principle

The allocation of resources

Resource application Actual node allocation Scheduler allocation failure

When there is no limit to the maximum resources, the remaining resources are allocated proportionally Out of resource limit

Pod is eliminated based on resource QOS

• BestEffort (minimum)
• Burstable
• Guaranteed (highest)

eliminate

The best practice

Pod Delete event

Helm K8S package manager

• Helm is a command line tool for local development and management of chart, chart warehouse management, etc
• Tiller is the server for Helm. Tiller is responsible for receiving Helm’s requests, interacting with K8S’s Apiserver, generating a release and managing the release according to chart
• Chart Helm’s packaging format is called Chart. Chart is a series of files, which describes a group of related K8S cluster resources
• Release Chart deployed in the Kubernetes cluster using the helm install command is called release

Chart template

To be continued