Kubernetes(一)认识 kubernetes
Kubernetes v1.20 系列文章目录
Kubernetes(一)认识 kubernetes
Kubernets(二)部署非高可用Kubernetes集群的环境准备
Kubernets(三)部署非高可用Kubernetes集群-通过阿里云源安装 kubeadm、kubelet 和 kubectl
Kubernets(四)创建集群
Kubernetes(五)揭开 kubeadm 的神秘面纱
Kubernetes(六)第一个kubernetes 对象
文章目录
- Kubernetes v1.20 系列文章目录
- 前言
- 一、容器编排工具介绍
-
- 1. docker compose
- 2. docker swarm
- 3. kubernetes
- 二、kubernetes 架构介绍
- 三、kubernetes 组件介绍
-
- 1. Master 节点组件
- 2. 其他计算节点组件
-
- 2.1 CRI 容器运行时
- 2.2 gRPC
- 2.3 CNI 和 CSI
- 四、Kubernetes 项目设计思想
-
- 1 POD
- 2 Deployment 多实例管理器
- 3 Service
- 4 Job、CronJob、DaemonSet
- 五、如何使用 kubernetes
文章目录
- Kubernetes v1.20 系列文章目录
- 前言
- 一、容器编排工具介绍
-
- 1. docker compose
- 2. docker swarm
- 3. kubernetes
- 二、kubernetes 架构介绍
- 三、kubernetes 组件介绍
-
- 1. Master 节点组件
- 2. 其他计算节点组件
-
- 2.1 CRI 容器运行时
- 2.2 gRPC
- 2.3 CNI 和 CSI
- 四、Kubernetes 项目设计思想
-
- 1 POD
- 2 Deployment 多实例管理器
- 3 Service
- 4 Job、CronJob、DaemonSet
- 五、如何使用 kubernetes
前言
一、容器编排工具介绍
1. docker compose
孤军奋战
2. docker swarm
努力奋斗的有志青年
3. kubernetes
官二代，够强大
二、kubernetes 架构介绍
项目原型来源于 Google 公司的 Borg 项目, 有Redhat 公司和谷歌公司共同主导，由 kubernetes 社区核心成员维护的一个分布式容器编排系统。
Borg 项目是谷歌公司整个架构的基础核心项目。
图片来源
kubernets 很好的继承了 Borg 项目的设计思想和优点
Kubernetes 项目在 Borg 体系的指导下，体现出了一种独有的“先进性”与“完备性”，而这些特质才是一个基础设施领域开源项目赖以生存的核心价值。
全局架构图如下:
可以看出，kubernetes 由 Master 和 Node 两种节点组成，而这两种角色分别对应着控制节点和计算节点。
三、kubernetes 组件介绍
1. Master 节点组件
Master 节点，由三个紧密协作的独立组件组合而成，它们分别是：
- 负责 API 服务的 kube-apiserver
- 负责调度的 kube-scheduler
- 负责容器编排的 kube-controller-manager。
整个集群的持久化数据，则由 kube-apiserver 处理后保存在 Etcd 中。
2. 其他计算节点组件
计算节点组件中最核心的组件就是 kubelet。
在 Kubernetes 项目中，kubelet 主要负责同容器运行时（比如 Docker 项目）打交道。
2.1 CRI 容器运行时
而这个交互所依赖的，是一个称作 CRI（Container Runtime Interface）的远程调用接口，这个接口定义了容器运行时的各项核心操作，比如：启动一个容器需要的所有参数。
从这里也可以看出， Kubernetes 项目并不关心你部署的是什么容器运行时、使用的什么技术实现，只要你的这个容器运行时能够运行标准的容器镜像，它就可以通过实现 CRI 接入到 Kubernetes 项目当中。
2.2 gRPC
kubelet 还通过 gRPC 协议同一个叫作 Device Plugin 的插件进行交互。这个插件，是 Kubernetes 项目用来管理 GPU 等宿主机物理设备的主要组件，也是基于 Kubernetes 项目进行机器学习训练、高性能作业支持等工作必须关注的功能。
2.3 CNI 和 CSI
kubelet 的另一个重要功能，则是调用网络插件和存储插件为容器配置网络和持久化存储。这两个插件与 kubelet 进行交互的接口，分别是 CNI（Container Networking Interface）和 CSI（Container Storage Interface）
四、Kubernetes 项目设计思想
最主要的设计思想是，从更宏观的角度，以统一的方式来定义任务之间的各种关系，并且为将来支持更多种类的关系留有余地。
1 POD
Kubernetes 项目对容器间的“访问”进行了分类：
- 首先总结出了一类非常常见的“紧密交互”的关系，即：这些应用之间需要非常频繁的交互和访问；比如： Nginx 将动态请求传递给 PHP应用程序。
- 又或者，它们会直接通过本地文件进行信息交换；比如日志收集程序Filebeat 搜集应用程序的日志。
在传统模式下，这些应用往往会被直接部署在同一台机器上，通过 Localhost 通信，通过本地磁盘目录交换文件。
而在 Kubernetes 项目中，这些容器则会被划分为一个“Pod”，Pod 里的容器共享同一个 Network Namespace、同一组数据卷，从而达到高效率交换信息的目的。
后面会再更深入的介绍 POD 的相关知识。
2 Deployment 多实例管理器
对于 web 应用程序来说，随着业务量的增长，客户也会逐渐增多，随之而来的就是访问量的增加。
因此，为了应对日益增长的访问量，我们应该启动多个应用程序的实例来应对，并且这种启动应该是快速响应的。
这就是 kubernetes 中 Deployment 这个 Pod 的多实例管理器所要负责的工作。
3 Service
对于 Web 应用与数据库之间的访问关系，Kubernetes 项目则提供了一种叫作“Service”的服务。
因为，像这样的两个应用，往往故意不部署在同一台机器上，这样即使 Web 应用所在的节点宕机了，数据库也完全不受影响。
可是，我们知道，对于一个容器来说，它的 IP 地址等信息不是固定的，那么 Web 应用又怎么找到数据库容器的 Pod 呢？
Kubernetes 项目的做法是给 Pod 绑定一个 Service 服务，而 Service 服务声明的 IP 地址等信息是“终生不变”的。这个 Service 服务的主要作用，就是作为 Pod 的代理入口（Portal），从而代替 Pod 对外暴露一个固定的网络地址。
这样，对于 Web 应用的 Pod 来说，它需要关心的就是数据库 Pod 所对应的 Service 信息。
所以，Service 后端真正代理的 Pod 的 IP 地址、端口等信息的自动更新、维护，则是 Kubernetes 项目的职责。
另外,Service 还负载对于后端应用程序的访问起到负载均衡的作用。
4 Job、CronJob、DaemonSet
除了应用与应用之间的关系外，应用运行的形态是影响“如何容器化这个应用”的第二个重要因素。为此，Kubernetes 定义了新的、基于 Pod 改进后的对象。比如：
- Job，用来描述一次性运行的 Pod（比如，大数据任务）；
- DaemonSet，用来描述每个宿主机上必须且只能运行一个副本的守护进程服务；
- CronJob，则用于描述定时任务等等。
以上的种种，正是 Kubernetes 项目定义容器间关系和形态的主要方法。
五、如何使用 kubernetes
在 Kubernetes 项目中，推崇的使用方法是：
- 首先，通过一个“编排对象”，比如 Pod、Job、CronJob 等，来描述你试图管理的应用；
- 然后，再为它定义一些“服务对象”，比如 Service、Secret、Horizontal Pod Autoscaler（自动水平扩展器）等。
这些对象，会负责具体的平台级功能。
这种使用方法，就是所谓的 “声明式 API”。
这种 API 对应的“编排对象”和“服务对象”，都是 Kubernetes 项目中的 API 对象（API Object）。