文章目录
- 序言
- 1 kubernetes概述
- 1.1 kubernetes解决的问题
- 1.1.1 部署方式的演变
- 1.1.2 容器化部署——容器编排问题
- 1.2 kubernetes组件
- 1.2.1 kubernetes组件调用关系
- 1.2.2 调用逻辑示例
序言
序言：本文将从，第一节：kubernetes解决的问题、组件和工作原理；
1 kubernetes概述
kubernetes是谷歌Borg系统的一个开源版本，kubernetes的本质是一组服务器集群，kubernetes可以在每个节点上运行特定程序，实现对节点中容器管理，目的是，实现资源管理自动化，主要提供了如下功能：
- 自我修复：一旦某一个容器崩溃，能够在1s中左右启动容器。
- 弹性伸缩：可以根据需要，自动对集群中正在运行容器数量进行调整。
- 服务发现：服务可通过自动发现的形式找到其所依赖的服务。
- 负载均衡：若一个服务启动多个容器，能自动实现负载均衡。
- 版本回退：若发现新发布的程序版本有问题，可立即回退到原来版本。
- 存储编排：根据容器自身需求自动创建存储卷。
1.1 kubernetes解决的问题
1.1.1 部署方式的演变
| 传统部署 | 虚拟化部署 | 容器化部署 | |
|---|---|---|---|
| 解释 | 早期，直接将应用程序部署在物理机上 | 在一台物理机上运行多个虚拟机，每个虚拟机都是一个独立环境 | 与虚拟化类似，但是共享了操作系统 |
| 优点 | 简单，不需其他技术参与 | 程序环境不会相互影响，每个虚拟机都是一个环境 | 保证每个容器拥有自己的文件系统、CPU等。实现基础架构解耦，容器化应用程序可以跨云服务器进行部署 |
| 缺点 | 不能为程序资源使用边界，程序间容易产生影响 | 增加了操作系统，浪费部分资源 | ① 一个容器故障停机，如何让另一个容器启动去替补停机的容器；② 当并发访问变大时，如何横向扩展容器数量 |
1.1.2 容器化部署——容器编排问题
容器编排问题：针对容器化部署中所遇到的：一个容器故障停机，如何使得另一个容器去启动替补；以及当并发访问变大时，如何横向扩展容器的解决方案，产生了一些容器编排软件
- Swarm：Docker官方容器编排工具。
- Mesos：Apache的资源统一管理工具，需要与Marathon结合使用。
- Kubernetes：Google开源容器编排工具。
1.2 kubernetes组件
1.2.1 kubernetes组件调用关系
| 组件 | 功能 |
|---|---|
| master（控制节点） | 集群的控制平面，负载集群的决策（管理） |
| ApiServer | 资源操作的唯一入口，接收用户输入命令，提供认证、授权、API注册和发现等机制 |
| Scheduler | 负责集群资源调度，按照预定调度策略将pod调度到相应node节点 |
| ControllerManger | 负责维护集群状态，诸如程度部署安装、故障检测、自动扩展、滚动更新等 |
| Etcd | 负责存储集群中各种资源对象信息 |
| node（工作节点） | 集群的数据平面，负责为容器提供运行环境（干活） |
| Kubelet | 负责维护容器生命周期，即通过控制docker，来创建、更新、销毁容器 |
| KubeProxy | 负责提供集群内部服务发现和负载均衡 |
| Docker | 负责节点上容器各种操作 |
1.2.2 调用逻辑示例
以部署nginx服务，来说明kubernetes系统各个组件调用关系：
- ① 首先，当kubernetes环境启动后，master和node都会将自身信息存储到etcd数据库中。
- ② 当我们发送安装nginx服务请求，首先会被发送到master节点的apiServer组件。
- ③ apiServer组件会调用schedule组件，来决定应该把这个服务安装到哪个node节点。同时，schedule组件会从etcd中读取各个node节点信息，然后按照算法进行选择，并将结果反馈给apiServer。
- ④ apiServer调用controller-manager去调度node节点安装nginx服务。
- ⑤ 的pod(
pod相当于一个容器)。
pod是kubernetes的最小操作单元，容器必须跑在pod中。
