20221215 2. k8s 介绍
kubernetes 与 docker swarm 对比
Docker Swarm | Kubernetes | |
---|---|---|
开发者 | Docker 公司 | 谷歌 |
发布年份 | 2013 | 2014 |
Controller | Manager | Master |
Storage | Volumes | Persistent and Epherma |
兼容性 | 不那么广泛和可定制 | 更广泛和高度可定制 |
安装 | 易于设置 | 需要时间安装 |
容错性 | 低 | 高 |
大集群 | 对于强集群状态考虑速度 | 在不考虑速度的情况下,即使在大型集群中也提供容器部署和扩展 |
负载均衡 | 当容器中的pod定义为服务时,提供负载平衡 | 通过集群中的任何节点提供自动的内部负载平衡 |
部署单位 | Task | Pod |
Port | Published Port | Endpoint |
社区 | 活跃的用户群,定期更新各种应用程序的镜像 | 获得开源社区和谷歌,亚马逊,微软和IBM等大公司的大力支持 |
弱点 | 没有供应商的认证计划。大多数组织需要商业认证版本 | 倾向于开发人员而不是中央IT |
优势 | 主要由可以决定产品方向的单一供应商控制 | 明确的市场领导者;最高的采用率 |
Slave | Worker | Nodes |
容器设置 | 功能由 Docker API 提供并受其限制 | 客户端 API 和 YAML |
可扩展性 | 即使在大型容器中也可以快速部署容器 | 以牺牲速度为代价为集群状态提供强有力的保证 |
Docker Swarm
Docker是一种容器管理服务,它帮助开发人员设计应用程序,使用容器能更容易地创建、部署和运行应用程序。Docker有一个用于集群容器的内置机制,称为“集群模式”(swarm mode)。使用集群模式,你可以使用Docker引擎在多台机器上启动应用程序。
Docker Swarm是Docker自己针对Docker容器的原生集群解决方案,它的优点是紧密集成到Docker的生态系统中,并且使用自己的API。它监视跨服务器集群的容器数量,是创建集群docker应用程序的最方便的方法,不需要额外的硬件。它为Dockerized应用程序提供了一个小型但有用的编排系统。
使用Docker Swarm的优点
- 更快的运行速度
- 完备的相关技术文档
- 快速简单的配置
- 确保程序独立(容器间低耦合)
- 版本控制与组件重用
使用Docker Swarm的缺点
- 跨平台支持效果差
- 不提供存储选项
- 监控信息不足
Kubernetes
Kubernetes 是一个用于在集群环境中管理容器化应用程序的开源系统。以正确的方式使用Kubernetes可以帮助DevOps作为一个服务团队自动扩展应用程序,并在零停机的情况下进行更新。
使用Kubernetes的优点:
-
速度很快:Kubernetes的目标是以恒定的正常运行时间更新应用程序
-
遵循不可变基础架构的原则:在不可变的基础架构中,如果想要更新任何应用程序,需要使用新标记构建容器映像并部署它,用旧映像版本销毁旧容器。这样,你就会有一个记录,并了解你做了什么,万一有什么错误;您可以轻松地回滚到前面的映像。
-
提供声明式配置:用户可以知道系统应该处于什么状态以避免错误
-
可以大规模部署和更新软件
-
水平基础架构扩展
-
自动扩展:根据CPU资源或其他应用程序指标的使用情况,您可以更改正在运行的容器数
-
手动扩展
-
复制控制器:复制控制器确保集群在运行状态下具有指定数量的等效pod。如果存在太多pod,则复制控制器可以删除额外的pod,反之亦然
-
-
处理应用程序的可用性:Kubernetes检查节点和容器的运行状况,并在由于错误导致的盒中崩溃时提供自我修复和自动替换。此外,它在多个pod之间分配负载,以便在意外流量期间快速平衡资源
-
存储卷: 在Kubernetes中,数据是在容器之间共享的,但是如果pod被杀死,则自动删除卷。此外,数据是远程存储的,因此如果将pod移动到另一个节点,数据将一直保留,直到用户删除它
使用Kubernetes的缺点
-
初始进程需要时间:当创建一个新进程时,您必须等待应用程序启动,然后用户才能使用它。如果您要迁移到Kubernetes,则需要对代码库进行修改,以提高启动流程的效率,这样用户就不会有不好的体验
-
迁移到无状态需要做很多工作: 如果您的应用程序是集群的或无状态的,那么将不会配置额外的pod,并且必须重新处理应用程序中的配置
-
安装过程非常单调乏味:如果不使用Azure、谷歌或Amazon等云提供商,就很难在集群上设置 Kubernetes
K8S 集群安全机制
Kubernetes 作为一个分布式集群的管理工具,保证集群的安全性是其一个重要的任务。API Server 是集群内部各个组件通信的中介,也是外部控制的入口。所以 Kubernetes 的安全机制基本就是围绕保护 API Server 来设计的。
Kubernetes 使用了认证(Authentication)、鉴权(Authorization)、准入控制(Admission Control)三步来保证API Server的安全 。
Authentication(认证)
-
第三方授权协议:authenticating proxy
-
HTTP Token 认证:通过一个 Token 来识别合法用户
-
HTTP Token 的认证是用一个很长的特殊编码方式的并且难以被模仿的字符串 Token 来表达客户的一种方式
-
当客户端发起 API 调用请求时,需要在 HTTP Header 里放入 Token
-
-
HTTP Base 认证:通过 用户名+密码 的方式认证
用户名:密码
用 BASE64 算法进行编码后的字符串放在 HTTP Request 中的 Heather Authorization 域里发送给服务端,服务端收到后进行编码,获取用户名及密码
-
最严格的 HTTPS 证书认证:基于 CA 根证书签名的客户端身份认证方式
-
HTTPS 证书认证: 采用双向加密认证方式
-
证书颁发
-
手动签发:通过 k8s 集群的跟 ca 进行签发 HTTPS 证书
-
自动签发:kubelet 首次访问 API Server 时,使用 token 做认证,通过后,Controller Manager 会为 kubelet 生成一个证书,以后的访问都是用证书做认证了
-
-
安全性说明
-
Controller Manager、Scheduler 与 API Server 在同一台机器,所以直接使用 API Server 的非安全端口访问, --insecure-bind-address=127.0.0.1
-
kubectl、kubelet、kube-proxy 访问 API Server 就都需要证书进行 HTTPS 双向认证
-
-
-
kubeconfig 文件包含集群参数(CA证书、API Server地址),客户端参数(上面生成的证书和私钥),集群context 信息(集群名称、用户名)。Kubenetes 组件通过启动时指定不同的 kubeconfig 文件可以切换到不同的集群
Kubernetes 基础组件
一个 Kubernetes 集群由一组被称作节点的机器组成。这些节点上运行 Kubernetes 所管理的容器化应用。集群具有至少一个工作节点和至少一个主节点。
工作节点托管作为应用程序组件的 Pod 。主节点管理集群中的工作节点和 Pod 。多个主节点用于为集群提供故障转移和高可用性。
下图展示了包含所有相互关联组件的 Kubernetes 集群:
控制平面组件(Control Plane Components)
控制平面的组件对集群做出全局决策(比如调度),以及检测和响应集群事件(例如,当不满足部署的 replicas 字段时,启动新的 pod)。
控制平面组件可以在集群中的任何节点上运行。然而,为了简单起见,设置脚本通常会在同一个计算机上启动所有控制平面组件,并且不会在此计算机上运行用户容器。
kube-apiserver
主节点上负责提供 Kubernetes API 服务的组件;它是 Kubernetes 控制面的前端。
-
kube-apiserver 是Kubernetes最重要的核心组件之一
-
提供集群管理的 REST API 接口,包括认证授权,数据校验以及集群状态变更等
-
提供其他模块之间的数据交互和通信的枢纽(其他模块通过API Server查询或修改数据,只有API Server才直接操作etcd)
-
生产环境可以为apiserver做LA或LB。在设计上考虑了水平扩缩的需要。 换言之,通过部署多个实例可以实现扩缩。 参见构造高可用集群。
etcd
kubernetes需要存储很多东西,像它本身的节点信息,组件信息,还有通过kubernetes运行的pod,deployment,service等等。都需要持久化。etcd就是它的数据中心。生产环境中为了保证数据中心的高可用和数据的一致性,一般会部署最少三个节点。
这里只部署一个节点在master。etcd也可以部署在kubernetes每一个节点。组成etcd集群。
如果已经有etcd外部的服务,kubernetes直接使用外部etcd服务
etcd 是兼具一致性和高可用性的键值数据库,可以作为保存 Kubernetes 所有集群数据的后台数据库。
Kubernetes 集群的 etcd 数据库通常需要有个备份计划。
kube-scheduler
主节点上的组件,该组件监视那些新创建的未指定运行节点的 Pod,并选择节点让 Pod 在上面运行。
kube-scheduler负责分配调度Pod到集群内的节点上,它监听kube-apiserver,查询还未分配Node的Pod,然后根据调度策略为这些Pod分配节点。
kube-controller-manager
在主节点上运行控制器的组件
Controller Manager由kube-controller-manager和cloud-controller-manager组成,是Kubernetes的大脑,它通过apiserver监控整个集群的状态,并确保集群处于预期的工作状态。
kube-controller-manager由一系列的控制器组成,像Replication Controller控制副本,Node Controller节点控制,Deployment Controller管理deployment等等
cloudcontroller-manager在Kubernetes启用Cloud Provider的时候才需要,用来配合云服务提供商的控制
控制器类型
控制器名称 | 作用 |
---|---|
Deployment | 声明式更新控制器,用于发布无状态应用 |
ReplicaSet | 副本集控制器,用于对Pod进行副本规模 扩大或剪裁 |
StatefulSet | 有状态副本集,用于发布有状态应用 |
DaemonSet | 在k8s集群每一个Node上运行一个副本, 用于发布监控或日志收集类等应用 |
Job | 运行一次性作业任务 |
CronJob | 运行周期性作业任务 |
DaemonSet
具有上线部署、滚动升级、创建副本、回滚到以前某一版本(成功/ 稳定)等功能。
Deployment包含ReplicaSet,除非需要自定义升级功能或者根本不需要升级Pod,否则还是建议使用Deployment而不直接使用ReplicaSet 。
cloud-controller-manager
云控制器管理器
cloud-controller-manager 运行与基础云提供商交互的控制器
cloud-controller-manager 仅运行云提供商特定的控制器循环
cloud-controller-manager 允许云供应商的代码和 Kubernetes 代码彼此独立地发展。在以前的版本中,核心的 Kubernetes 代码依赖于特定云提供商的代码来实现功能。在将来的版本中,云供应商专有的代码应由云供应商自己维护,并与运行 Kubernetes 的云控制器管理器相关联。
kubectl
主节点上的组件
kubectl是Kubernetes的命令行工具,是Kubernetes用户和管理员必备的管理工具。
kubectl提供了大量的子命令,方便管理Kubernetes集群中的各种功能
Node 组件
节点组件在每个节点上运行,维护运行的 Pod 并提供 Kubernetes 运行环境
kubelet
一个在集群中每个节点上运行的代理。它保证容器都运行在 Pod 中
在集群中每个工作节点上都运行一个kubelet服务进程,默认监听10250端口,接收并执行master发来的指令,管理Pod及Pod中的容器。每个kubelet进程会在API Server上注册节点自身信息,定期向master节点汇报节点的资源使用情况,并通过cAdvisor监控节点和容器的资源。
kube-proxy
一个在集群中每台工作节点上都应该运行一个kube-proxy服务,它监听API server中service
和endpoint的变化情况,并通过iptables等来为服务配置负载均衡,是让我们的服务在集群
外可以被访问到的重要方式。
容器运行环境 (Container Runtime)
容器运行环境是负责运行容器的软件。
Kubernetes 支持多个容器运行环境:Docker、 containerd、cri-o、 rktlet 以及任何实现 Kubernetes CRI (容器运行环境接口)
插件(Addons)
插件使用 Kubernetes 资源 (DaemonSet, Deployment等) 实现集群功能。因为这些提供集群级别的功能,所以插件的命名空间资源属于 kube-system 命名空间。
KUBE-DNS
kube-dns为Kubernetes集群提供命名服务,主要用来解析集群服务名和Pod的hostname。
目的是让pod可以通过名字访问到集群内服务。它通过添加记录的方式实现名字和service
的解析。普通的service会解析到service-ip。headless service会解析到pod列表
用户界面(Dashboard)
Dashboard 是 Kubernetes 集群的通用基于 Web 的 UI。它使用户可以管理集群中运行的应用程序以及集群本身并进行故障排除。
容器资源监控
容器资源监控将关于容器的一些常见的时间序列度量值保存到一个集中的数据库中,并提供用于浏览这些数据的界面。
集群层面日志
集群层面日志机制负责将容器的日志数据保存到一个集中的日志存储中,该存储能够提供搜索和浏览接口