Kubernetes容器云——基础概念篇
前言
前面我们讲解了有关docker的基础以及进阶的部分内容,本文开始将进入Kubernetes的云原生平台结合容器的云服务的世界。本文将从Kubernetes的基础概念,核心作用,基本组件、架构和原理来讲述Kubernetes,带你从入门到进阶搞定Kubernetes。
Kubernetes基础概念
从docker容器引入Kubernetes
近十几年来,IT领域的技术发展可谓是日新月异,新的架构新的概念层出不穷,例如DevOPs、微服务、容器、云计算及区块链等。而由于各种业务的需要,IT应用模型也在不断变革,而前面所讲数的docker容器技术的出现,其终结了Devops中交付和部署环节因环境、配置及开发语言等不同因素造成的困境,如今愈来愈多的企业或组织开始选择以镜像文件为交付载体。容器镜像内包含了应用程序及其依赖的系统环境、库、基础程序等,从而可以在安装了容器引擎上直接运行。这样,IT运维工程师就无需关注编程语言和开发环境,只需要掌握管理容器的工具链即可。
新的问题
虽然部署简化了,但是以容器形式运行的应用程序之间的协同却是一个新的问题,于是各种编排系统应运而生,其中为代表的就是Kubernetes。
Kubernetes概述
Kubernetes,来着希腊语,意为“舵手”或者说是“飞行员”,个人在这里还是倾向于舵手这个更加形象的解释。还记得docker的logo吗?一条拖着集装箱的鲸鱼,而Kubernetes就是担任管理这些集装箱的一个角色。Kubernetes的logo是什么呢?请看下面的图片:(我将docker【左】和Kubernetes【右】的logo放在一起了)
Kubernetes(k8s)是自动化容器操作的开源平台,这些操作包括部署,调度和节点集群间扩展。如果你曾经用过Docker容器技术部署容器,那么可以将Docker看成Kubernetes内部使用的低级别组件。Kubernetes不仅仅支持Docker,还支持Rocket,这是另一种容器技术。 使用Kubernetes可以:
- 自动化容器的部署和复制
- 随时扩展或收缩容器规模
- 将容器组织成组,并且提供容器间的负载均衡
- 很容易地升级应用程序容器的新版本
- 提供容器弹性,如果容器失效就替换它等等
Kubernetes核心作用
容器是打包和运行应用程序的好方式。在生产环境中,需要管理运行应用程序的容器,并确保不会停机。例如,如果一个容器发生故障,则需要启动另一个容器。如果系统处理此行为,会不会更容易?
这就是 Kubernetes 的救援方法!Kubernetes 提供了一个可弹性运行分布式系统的框架。Kubernetes 会满足扩展要求、故障转移、部署模式等。Kubernetes可以提供:
-
服务发现和负载均衡
Kubernetes 可以使用 DNS 名称或自己的 IP 地址公开容器,如果到容器的流量很大,Kubernetes 可以负载均衡并分配网络流量,从而使部署稳定。 -
存储编排
Kubernetes 允许您自动挂载您选择的存储系统,例如本地存储、公共云提供商等。 -
自动部署和回滚
您可以使用 Kubernetes 描述已部署容器的所需状态,它可以以受控的速率将实际状态更改为所需状态。例如,您可以自动化 Kubernetes 来为您的部署创建新容器,删除现有容器并将它们的所有资源用于新容器。 -
自动二进制打包
Kubernetes 允许您指定每个容器所需 CPU 和内存(RAM)。当容器指定了资源请求时,Kubernetes 可以做出更好的决策来管理容器的资源。 -
自我修复
Kubernetes 重新启动失败的容器、替换容器、杀死不响应用户定义的运行状况检查的容器,并且在准备好服务之前不将其通告给客户端。 - 密钥与配置管理
Kubernetes 允许您存储和管理敏感信息,例如密码、OAuth 令牌和 ssh 密钥。您可以在不重建容器镜像的情况下部署和更新密钥和应用程序配置,也无需在堆栈配置中暴露密钥。
Kubernetes基本架构与组件
一个 Kubernetes 集群包含 集群由一组被称作节点的机器组成。这些节点上运行 Kubernetes 所管理的容器化应用。集群具有至少一个工作节点和至少一个主节点。
工作节点托管作为应用程序组件的 Pod 。主节点管理集群中的工作节点和 Pod 。多个主节点用于为集群提供故障转移和高可用性。
Kubernetes集群中互相关联的所有组件如下图所示
首先是左边框体内的控制平面组件——control plane
Kubernetes Control Plane
控制平面中的组件主要是负责对集群做出全局的决策(例如调度后端节点服务器),以及检测及响应集群事件
下面逐一介绍这类组件
kube-apiserver
主节点上负责提供 Kubernetes API 服务的组件;它是 Kubernetes 控制面的前端,你可以将之理解为服务的唯一入口。kube-apiserver 在设计上考虑了水平扩缩的需要,即通过部署多个实例可以实现扩缩。
etcd
etcd 是兼具一致性和高可用性的键值数据库,可以作为保存 Kubernetes 所有集群数据的后台数据库。需要在节点服务器上部署搭建该集群,这也将会是后面我们搭建Kubernetes集群的第一个任务。
将会在主节点和其他服务节点上搭建etcd集群
kube-scheduler
主节点上的组件,该组件监视那些新创建的未指定运行节点的 Pod,并选择节点让 Pod 在上面运行。
调度决策考虑的因素包括单个 Pod 和 Pod 集合的资源需求、硬件/软件/策略约束、亲和性和反亲和性规范、数据位置、工作负载间的干扰和最后时限。
kube-controller-manager
在主节点上运行控制器的组件。
从逻辑上讲,每个控制器都是一个单独的进程,但是为了降低复杂性,它们都被编译到同一个可执行文件,并在一个进程中运行。
这些控制器包括(暂作了解即可):
- 节点控制器(Node Controller): 负责在节点出现故障时进行通知和响应。
- 副本控制器(Replication Controller): 负责为系统中的每个副本控制器对象维护正确数量的 Pod。
- 端点控制器(Endpoints Controller): 填充端点(Endpoints)对象(即加入 Service 与 Pod)。
- 服务帐户和令牌控制器(Service Account & Token Controllers): 为新的命名空间创建默认帐户和 API 访问令牌
cloud-controller-manager
云控制器管理器——cloud-controller-manager 运行与基础云提供商交互的控制器。cloud-controller-manager 二进制文件是 Kubernetes 1.6 版本中引入的 alpha 功能。
cloud-controller-manager 仅运行云提供商特定的控制器循环。须在 kube-controller-manager 中禁用这些控制器循环,可以通过在启动 kube-controller-manager 时将 --cloud-provider 参数设置为 external 来禁用控制器循环。
cloud-controller-manager 允许云供应商的代码和 Kubernetes 代码彼此独立地发展。在以前的版本中,核心的 Kubernetes 代码依赖于特定云提供商的代码来实现功能。在将来的版本中,云供应商专有的代码应由云供应商自己维护,并与运行 Kubernetes 的云控制器管理器相关联。
以下控制器具有云提供商依赖性:
- 节点控制器(Node Controller): 用于检查云提供商以确定节点是否在云中停止响应后被删除
- 路由控制器(Route Controller): 用于在底层云基础架构中设置路由
- 服务控制器(Service Controller): 用于创建、更新和删除云提供商负载均衡器
- 数据卷控制器(Volume Controller): 用于创建、附加和装载卷、并与云提供商进行交互以编排卷
以上组件及Kubernetes Control Plane中的组件都是属于安装在master上的组件,下面来看看node上的组件
Kubernetes Nodes组件
此类组件在每个节点上运行,维护运行的Pod且提供Kubernetes的运行环境
kubelet
一个在集群中每个节点上运行的代理。它保证容器都运行在 Pod 中。
kubelet 接收一组通过各类机制提供给它的 PodSpecs,确保这些 PodSpecs 中描述的容器处于运行状态且健康。kubelet 不会管理不是由 Kubernetes 创建的容器。
kube-proxy
kub-proxy是集群中每个节点上运行的网络代理,实现 Kubernetes Service概念的一部分。
kube-proxy 维护节点上的网络规则。这些网络规则允许从集群内部或外部的网络会话与 Pod 进行网络通信。
如果操作系统提供了数据包过滤层并可用的话,kube-proxy会通过它来实现网络规则。否则,kube-proxy 仅转发流量本身。
当然Kubernetes还有一些其他的插件来为搭建的集群提供其他的功能,例如DNS 、Dashboard用户界面、容器资源监控及集群日志等
Kubernetes的基本组件就暂时讲到这里,下面看一下整个Kubernetes云平台的架构示意图
该架构就是一个单节点的Kubernetes平台搭建的基础架构图了,后面的文章将一步一步地以生产环境中二进制方式来来搭建单节点的Kubernetes集群,最后升级为高可用集群的搭建部署。
PS:补充一下Pod,这里简单解释一下,之后会额外讲述Pod。这里就理解为:Pod就是在Kubernetes对象模型创建或部署最小最简单的单元,或者简单认为是容器运行时的一个进程。
来源:oschina
链接:https://my.oschina.net/u/4271231/blog/4266888