Kubernetes in Action笔记—k8s简介【转--好用】

本文是这本书的读书笔记：

https://learning.oreilly.com/library/view/kubernetes-in-action/9781617293726/​learning.oreilly.com/library/view/kubernetes-in-action/9781617293726/

 

本章将介绍：

• 古早味的软件开发以及交互模式，近年来的演变
• 通过container将应用间的环境隔离，减少对环境的依赖
• 理解container和docker是如何在K8s上应用的
• K8s如何使我们的生活更美好

 

古早味的软件开发以及交互模式，近年来的演变

以前所有的东西都堆积在一个环境里，紧耦合，当组件越来越多的时候，维护就变得非常困难。所以近年来兴起了微服务，各个模块之间独立维护，减少相互的依赖，并且可以灵活的对系统的各个模块进行扩充。这样整个系统环境就比以前灵活很多：

微服务之间的沟通方式基本都是异步协议，比如HTTP的RESTful (REpresentational State Transfer) APIs.简单有效并且易于理解，并且编写的语言没有耦合关系。

但微服务也有问题，就是他们的相互依赖性维护起来很蛋疼。

 

从DevOps到NoOps

过去，开发负责开发，开发完了交给op去部署。但现在人们发现开发也应该参与到部署的过程中来，开发也应该负责部署。这意味着开发者，qa,op在整个产品生命周期中都需要写作。这种事件方法就叫做DevOps.

这样虽然大家的参与度都高了，但是侧重点也有所不同。

开发团队更注重产品迭代，开发feature，改善用户体验

而op更关注部署以及底层infra，系统安全。

理想化的，如果开发团队可以当不用关心底层实现的情况下放心的进行软件部署的话，这种方式就叫做NoOps. 这就是k8s可以大展手脚的地方，K8s将硬件抽象化，集群抽象成一个平台，使得开发者可以不需要op帮助自己去配置自己需要的系统资源，也不用去了解底层的硬件情况。

 

简单介绍container技术

k8s就是基于Linux的container技术做出来的。相比虚拟机，container使得组件的维护更方便，并且易扩展，同时组件与组件之间又能像虚拟机那样完美隔离。

实现Container的技术主要有2个：

• Linux Namespaces： 使得各个进程间完全隔离（包括文件，进程，网络Port，hostname等等）
• Linux Control Groups (cgroups)：可以限制每一个进程能够consume的系统资源（CPU, memory, network bandwidth, and so on）

默认来说，每一个Linux系统初始都有单一一个namespace，包括所有的system resources, 像是filesystems, process IDs, user IDs, network interfaces。我们可以在这基础上增加额外的namespaces，同时配资源。在跑一个进程时，可以直接在namespace里跑，进程中的应用将只能看到并使用自己被分配到的资源。

namespaces一般会有以下几种：

• Mount (mnt)
• Process ID (pid)
• Network (net)
• Inter-process communication (ipc)
• UTS
• User ID (user)

Docker技术：

docker是第一个能够使得contaner在不同的系统，机器间灵活切换使用的。它简化了应用的打包过程（all its libraries and other dependencies, even the whole OS file system）。

Docker技术会涉及到三个基本概念：

• Images—A Docker-based container image is something you package your application and its environment into. It contains the filesystem that will be available to the application and other metadata, such as the path to the executable that should be executed when the image is run.

 

• Registries—A Docker Registry is a repository that stores your Docker images and facilitates easy sharing of those images between different people and computers. When you build your image, you can either run it on the computer you’ve built it on, or you can push (upload) the image to a registry and then pull (download) it on another computer and run it there. Certain registries are public, allowing anyone to pull images from it, while others are private, only accessible to certain people or machines

 

• Containers—A Docker-based container is a regular Linux container created from a Docker-based container image. A running container is a process running on the host running Docker, but it’s completely isolated from both the host and all other processes running on it. The process is also resource-constrained, meaning it can only access and use the amount of resources (CPU, RAM, and so on) that are allocated to it.

三者之间的交互示意图如下：

基于docker的container，我们的应用有别于虚拟机，就可以像下图这样运行：

Docker images are composed of layers. Different images can contain the exact same layers because every Docker image is built on top of another image and two different images can both use the same parent image as their base. This speeds up the distribution of images across the network, because layers that have already been transferred as part of the first image don’t need to be transferred again when transferring the other image.

 

KUBERNETES 技术

k8s是一个可以让你非常方便的部署以及管理容器化的应用的平台。他使得开发者可以在一个上千个节点的集群上部署应用就像在一个单机节点部署一样方便。k8s将底层的硬件抽象化，极大的简化了开发，部署，运维工作。

下图是一个简单的ks系统示意图。系统由一个master node和任意数量的worker node组成。当开发者向master节点示意需要部署一些应用时候，k8s会将这些应用部署到worker节点上去，哪个应用部署在哪个节点是无所谓的。

开发者可以声明几个应用必须部署在一起，k8s就会将这些应用部署到一个节点上去。

 

Kubernetes集群的架构

一个k8s集群可以被分为许多个节点，但主要分为2类：

• The master node, which hosts the Kubernetes Control Plane that controls and manages the whole Kubernetes system
• Worker nodes that run the actual applications you deploy

示意图如下：接下来会一个个的讲解示意图中名词的含义：

Control Plane 是控制集群运转的模块，有多个组件构成，这些组件可以都部署在master节点上，也可以在集群上做多复制来保证可用性。组件包括：

• The Kubernetes API Server, which you and the other Control Plane components communicate with
• The Scheduler, which schedules your apps (assigns a worker node to each deployable component of your application)
• The Controller Manager, which performs cluster-level functions, such as replicating components, keeping track of worker nodes, handling node failures, and so on
• etcd, a reliable distributed data store that persistently stores the cluster configuration

以上组件只负责监控管理集群的状态，但不会真的帮忙跑应用，应用都是在worker node上跑的，worker node的组件包括：

• Docker, rkt, or another container runtime, which runs your containers
• The Kubelet, which talks to the API server and manages containers on its node
• The Kubernetes Service Proxy (kube-proxy), which load-balances network traffic between application components

在k8s上跑一个应用的步骤包括：

1. 打包container image
2. push到registry
3. 加一个description给k8s api server

这个description包括了container image或者应用需要的多个image，以及这些image是如何关联的，他们的依赖关系是啥，以及应用是否会向外部或者外部客户暴露端口提供服务。

当api server处理应用描述时，Scheduler就会将根据worker节点的资源可用性，部署应用。

下图可以帮助你更好的理解，app包含了4个container，分化成了3个sets (这个叫做pods）。前两个pods包含一个container，最后一个包含了2个。这意味着2个container是独立运行的。每个container旁边也制定了replica数字。在提交了描述之后，k8s会自动根据指令部署应用数。同时从docker registry上pull这些container下来，并运行。

一旦跑起来,k8s会持续的保证集群中运行的应用数量与你提供的描述完全一致。（多了少了都会进行修正，如果所有的instance都运转不正常，k8s会自动重启。）

如果一个wokder节点挂了，k8s会自动选择一个新的节点并将部署的应用进行转移。

在应用运行时，你可以随心所欲的增加或者减少copy的数量（云上甚至可以做到资源自动化调整）。。当多个应用提供同一个服务时，你可以制定k8s将这几个应用的服务端口绑定到同一个ip地址上。kube-proxy会进行负载均衡的调整。

Kubernetes的好处：

如果集群上都用K8s，op就不用在帮你部署了（容器化了）。开发也不用关心底层硬件，因为k8s将整个集群抽象成了一个单节点。（当然有些应用一定要ssd存储，也可以声明让k8s必须让这些应用泡在有ssd存储的节点上）。

k8s使得infra和开发彻底解耦，并且资源能够得到最充分的应用。另外应用在集群上可以随时迁移对于服务的稳定性也有非常好的保障（有多余的节点的话，服务器挂了k8s就会自动迁移）

对于ops的好处显然意见，那么对于开发的好处呢？显然就是debug起来特别方便，因为开发部署能够保证是同一套环境啦。

最后回顾一下本章节的内容：

• Linux containers provide much the same benefits as virtual machines, but are far more lightweight and allow for much better hardware utilization.
• Docker improved on existing Linux container technologies by allowing easier and faster provisioning of containerized apps together with their OS environments.
• Kubernetes exposes the whole datacenter as a single computational resource for running applications.
• Developers can deploy apps through Kubernetes without assistance from sysadmins.
• Sysadmins can sleep better by having Kubernetes deal with failed nodes automatically.