Kubernetes is an open source container scheduling platform across host clusters that automates the deployment, expansion, and operation of application containers and provides a container-centric infrastructure. (First line of official document)
1.1 Kubernetes for microservices
Each microservice is a separate process that calls each other through a defined restful API (AMQP)
1.1.1 Common Problems of microservices
Confusion caused by different service dependency libraries, need to open each service independently (improved by Docker)
Service registration, service discovery: The current service needs to be updated dynamically.
Service choreography (that is, the orchestration of Docker containers, which is difficult for Docker itself to solve the problem of cluster deployment) : which services need to be started on which hosts
1.2 Once dominant container choreography tools
Docker Swarm
Mesos + marathon
Kubernetes
2. Main components of Kubernetes
Master can simply be understood as a control center
Etcd: distributed K-V database, choose CP or AP according to the configuration, K8S only API Server and ETCD communication, other components and API server communication
API Server: Can be thought of as a prefilter for ETCD, another perspective, it and ETCD are similar to mysql and file systems.
Controller Manager: the core, responsible for adjusting the current state to the state that should be on etCD, contains all the implementation logic
Scheduler: A node is used to scheduler a pod.
Slave can be simply understood as worker
Kubelet: connect to master, register node, listen-watch local node tasks, etc
Kube-proxy: used for k8S service objects, described later.
Container runtime: In addition to Docker K8S, container implementations such as RKT are supported
Add-on Some functions not provided by K8S require plug-in implementation
Pod is the smallest object managed by K8S. It is a group of containers that share UTS, network and IPC namespace (shared PID is also supported, disabled by default).
Each POD will have an infrastructure container, volumne, network are actually shared network and Volumne of this container
Pods enable logically closely related processes to be properly isolated to maintain some degree of correlation:
Rc manages Pods, but pods are not started by RC. Rc synchronizes pods configuration files to API Server, Scheduler allocates nodes, and Kubelet running nodes.
3.service
Pod is not durable, it will be restarted constantly, resulting in pod IP is changing at any time, and the number of POD will be dynamic change, it is difficult for the client to communicate with pod directly, service is used to solve this problem
Service provides a unified entry point for pods that provide the same service
The binding IP of a service does not change during its lifetime
CMD kubectl set image deployment kubia nodejs=luksa/kubia:v2
The approximate implementation logic is that deployment continuously reduces the replicas of the old version of RC and increases the replicas of the new version
Just as RC does not directly control pod, deployment is similar in that deployment declaratively notifies the API Server of the results of the upgrade, the logic of which is handled by the Development Controller