目录
- 1 k8s 是什么
- 2 K8s的由来
- 2.1 K8s发展历程
- 2.2 发展时间线
- 3 为什么使用k8s
- 3.1 什么是容器
- 3.2 什么是 Kubernetes
- 3.3 K8s 的著名优势特色
- 3.3.1 一个平台搞定所有
- 3.3.2 云环境无缝迁移
- 3.3.3 高效的利用资源
- 3.3.4 开箱即用的自动缩放能力
- 3.3.5 使 CI/CD 更加简单
- 3.3.6 可靠性
- 4 核心概念
- 4.1 节点
- 4.1.1 Master 节点
- 4.1.2 Node
- 4.2 Pod
- 4.3 Label
- 4.4 Replica Set
- 4.5 Service
- 4.6 Namespace
1 k8s 是什么
K8S是Kubernetes
的全称,官方称其是
Kubernetes is an open source system for managing containerized applications across multiple hosts. It provides basic mechanisms for deployment, maintenance, and scaling of applications. 用于自动部署、扩展和管理“容器化(containerized)应用程序”的开源系统。
2 K8s的由来
源自谷歌的Borg,Borg是谷歌公司的内部容器管理系统。
Borg系统运行几十万个以上的任务,来自几千个不同的应用,跨多个集群,每个集群(cell)有上万个机器。它通过管理控制、高效的任务包装、超售、和进程级别性能隔离实现了高利用率,它支持高可用性应用程序与运行时功能,最大限度地减少故障恢复时间,减少相关故障概率的调度策略,该项目的目的是实现资源管理的自动化以及跨多个数据中心的资源利用率最大化,Kubernetes项目的目的就是将Borg最精华的部分提取出来,使现在的开发者能够更简单、直接地应用。它以Borg为灵感,但又没那么复杂和功能全面,更强调了模块性和可理解性。
2.1 K8s发展历程
Kubernetes 是 Google 开源的容器编排系统,2014 年对外宣布,2015 年发布 1.0 版本,同年 Google 与 Linux 基金会一起成立云原生计算基金会(CNCF-Cloud Native Computing Foundation),并把 Kubernetes 作为种子产品捐赠给了 CNCF,Google 一直在带领着 Kubernetes 的开发,我们也可以看到 CNCF 的 Kubernetes 项目代码贡献量,Google 所占比重是最高的。
2.2 发展时间线
Google 在容器领域拥有超过 15 年的经验。
- 2003 年,Google 内部几个工程师做了一个集群自动化管理的工具,叫做 Borg;
- 2012 年,Google Borg 升级成 Omega,实现容器的管理;
- 2013 年,随着业界 Docker 发布,整个行业开始往容器方向迁移;
- 2014 年,Borg/Omega 开源为 Kubernetes 项目;
- 到如今,Kubernetes 已经成为整个容器编排的主流技术。
3 为什么使用k8s
Kubernetes (Kube 或 K8s)越来越流行,他是市场上最好的容器编排工具之一。
3.1 什么是容器
- 容器就是一个包,其中包含了应用及其所有依赖。
- 容器中的应用与主机系统是隔离的,不关注环境。
- 不像虚拟机,容器不需要启动操作系统的完整周期,这就是为啥容器启动和停止都非常快,并且可以更高效使用磁盘、内存、处理器的原因。
- 你不必记着你的应用是用什么语言和框架开发的,因为所需的一切都打包在了容器中,例如运行时环境、所需的库等等,可以安全的迁移,可以在任何环境中部署。
左边,应用是直接部署在服务器或者虚拟机里面的,右边,应用是打包在独立的容器中的,可以快速启动、智能扩展、在任何环境中平滑运行。
3.2 什么是 Kubernetes
Kubernetes 是一个开源项目,用于统一管理容器化的应用集群。
- Kubernetes 负责在大规模服务器环境中管理容器组(pod)的扩展、复制、健康,并解决 pod 的启动、负载均衡等问题。
- Kubernetes 最初是 Google 发布的,现在已经被多家大公司支持,例如 Microsoft, RedHat, IBM, Docker。
3.3 K8s 的著名优势特色
3.3.1 一个平台搞定所有
使用 Kubernetes,部署任何应用都是小菜一碟,只要应用可以打包进容器,Kubernetes 就一定能启动它。
不管什么语言什么框架写的应用(Java, Python, Node.js),Kubernetes 都可以在任何环境中安全的启动它,物理服务器、虚拟机、云环境。
3.3.2 云环境无缝迁移
如果你有换云环境的需求,例如从 GCP 到 AWS,使用 Kubernetes 的话,你就不用有任何担心。
Kubernetes 完全兼容各种云服务提供商,例如 Google Cloud、Amazon、Microsoft Azure,还可以工作在 CloudStack, OpenStack, OVirt, Photon, VSphere。
3.3.3 高效的利用资源
看下图,左边,是4个虚拟机,黄色和蓝色部分是运行的应用,白色部分是未使用的内存和处理器资源。
Kubernetes 如果发现有节点工作不饱和,便会重新分配 pod,帮助我们节省开销,高效的利用内存、处理器等资源。
如果一个节点宕机了,Kubernetes 会自动重新创建之前运行在此节点上的 pod,在其他节点上运行。
3.3.4 开箱即用的自动缩放能力
网络、负载均衡、复制等特性,对于 Kubernetes 都是开箱即用的。
- pod 是无状态运行的,任何时候有 pod 宕了,立马会有其他 pod 接替它的工作,用户完全感觉不到。
- 如果用户量突然暴增,现有的 pod 规模不足了,那么会自动创建出一批新的 pod,以适应当前的需求。
- 反之亦然,当负载降下来的时候,Kubernetes 也会自动缩减 pod 的数量。
3.3.5 使 CI/CD 更加简单
你不必精通于 Chef 和 Ansible 这类工具,只需要对 CI 服务写个简单的脚本然后运行它,就会使用你的代码创建一个新的 pod,并部署到 Kubernetes 集群里面。
应用打包在容器中使其可以安全的运行在任何地方,例如你的 PC、一个云服务器,使得测试极其简单。
3.3.6 可靠性
Kubernetes 如此流行的一个重要原因是:应用会一直顺利运行,不会被 pod 或 节点的故障所中断。
如果出现故障,Kubernetes 会创建必要数量的应用镜像,并分配到健康的 pod 或节点中,直到系统恢复,而且用户不会感到任何不适。
4 核心概念
4.1 节点
从上面的图可以看出来,k8s 集群的节点有两个角色,分别为 Master 节点和 Node 节点,整个 K8s 集群Master 和 Node 节点关系如下图所示:
4.1.1 Master 节点
Master 节点也称为控制节点,每个 k8s 集群都有一个 Master 节点负责整个集群的管理控制,我们上面介绍的 k8s 三大能力都是经过 Master 节点发起的,Master 节点包含了以下几个组件:
- API Server:提供了 HTTP Rest 接口的服务进程,所有资源对象的增、删、改、查等操作的唯一入口;
- Controller Manager:k8s 集群所有资源对象的自动化控制中心;
- Scheduler:k8s 集群所有资源对象自动化调度控制中心;
- ETCD:k8s 集群注册服务发现中心,可以保存 k8s 集群中所有资源对象的数据。
4.1.2 Node
Node 节点的作用是承接 Master 分配的工作负载,它主要有以下几个关键组件:
- kubelet:负责 Pod 对应容器的创建、启停等操作,与 Master 节点紧密协作;
- kube-porxy:实现 k8s 集群通信与负载均衡的组件。
从图上可看出,在 Node 节点上面,还需要一个容器运行环境,如果使用 Docker 技术栈,则还需要在 Node 节点上面安装 Docker Engine,专门负责该节点容器管理工作。
4.2 Pod
Pod 是 k8s 最重要而且是最基本的一个资源对象,它的结构如下:
从以上 Pod 的结构图可以看出,它其实是容器的一个上层包装结构,这也就是为什么 K8s 可以支持多种容器类型的原因,基于这方面, k8s 的定位就是一个编排与调度工具,而容器只是它调度的一个资源对象而已。
Pod 可包含多个容器在里面,每个 Pod 至少会有一个 Pause 容器,其它用户定义的容器都共享该 Pause 容器,Pause 容器的主要作用是用于定义 Pod 的 ip 和 volume。
Pod 在 k8s 集群中的位置如下图所示:
4.3 Label
Label 在 k8s 中是一个非常核心的概念,我们可以将 Label 指定到对应的资源对象中
例如 Node、Pod、Replica Set、Service 等,一个资源可以绑定任意个 Label,k8s 通过 Label 可实现多维度的资源分组管理,后续可通过 Label Selector 查询和筛选拥有某些 Label 的资源对象,例如创建一个 Pod,给定一个 Label,workerid=123,后续可通过 workerid=123 删除拥有该标签的 Pod 资源。
4.4 Replica Set
Replica Set 目的是为了定义一个期望的场景,比如定义某种 Pod 的副本数量在任意时刻都处于 Peplica Set 期望的值
假设 Replica Set 定义 Pod 的副本数目为:replicas=2,当该 Replica Set 提交给 Master 后,Master 会定期巡检该 Pod 在集群中的数目,如果发现该 Pod 挂掉了一个,Master 就会尝试依据 Replica Set 设置的 Pod 模版创建 Pod,以维持 Pod 的数量与 Replica Set 预期的 Pod 数量相同。
通过 Replica Set,k8s 集群实现了用户应用的高可用性,而且大大减少了运维工作量。因此生产环境一般用 Deployment 或者 Replica Set 去控制 Pod 的生命周期和期望值,而不是直接单独创建 Pod。
类似 Replica Set 的还有 Deployment,它的内部实现也是通过 Replica Set 实现的,可以说 Deployment 是 Replica Set 的升级版,它们之间的 yaml 配置文件格式大部分都相同。
4.5 Service
Service 是 k8s 能够实现微服务集群的一个非常重要的概念
顾名思义,k8s 的 Service 就是我们平时所提及的微服务架构中的“微服务”,本文上面提及的 Pod、Replica Set 等都是为 Service 服务的资源, 如下图表示 Service、Pod、Replica Set 的关系:
从上图可看出,Service 定义了一个服务访问的入口,客户端通过这个入口即可访问服务背后的应用集群实例,而 Service 则是通过 Label Selector 实现关联与对接的,Replica Set 保证服务集群资源始终处于期望值。
以上只是一个微服务,通常来说一个应用项目会由多个不同业务能力而又彼此独立的微服务组成,多个微服务间组成了一个强大而又高可用的应用服务集群。
4.6 Namespace
Namespace 顾名思义是命名空间的意思,在 k8s 中主要用于实现资源隔离的目的
用户可根据不同项目创建不同的 Namespace,通过 k8s 将资源分配到不同 Namespace 中,即可实现不同项目的资源隔离: