如果云是水滴,Kubernetes 就是水滴管理平台
摘要:云是由很多小水滴组成的,把每一个计算机想象成小水滴,联合起来就形成了云。一般水滴先出现,然后出现管理水滴的平台(如 OpenStack,Kubernetes)。
一、云计算–独立宇宙

1.云是由很多小水滴组成的,把每一个计算机想象成小水滴,联合起来就形成了云;传统的水滴就是 VM;Docker 的出现,改变了小水滴的粒度
2.水滴独立可运行,内部完整 (如 VM,Docker 容器)
3.一般水滴先出现,然后出现管理水滴的平台(如 OpenStack,Kubernetes)
二、Kubernetes 简介
1.Kubernetes 是一个开源的,用于管理云平台中多个主机上的容器化的应用,Kubernetes 的目标是让部署容器化的应用简单并且高效(powerful),Kubernetes 提供了应用部署,规划,更新,维护的一种机制
2.Kubernetes 一个核心的特点就是能够自主的管理容器来保证云平台中的容器按照用户的期望状态运行着(比如用户想让 dlcatalog 一直运行,用户不需要关心怎么去做,Kubernetes 会自动去监控,然后去重启,新建,总之,让 dlcatalog 一直提供服务)
3.在 Kubenetes 中,所有的容器均在 Pod 中运行,一个 Pod 可以承载一个或者多个相关的容器
三、Kubernetes 典型名词

1.Pod
在 Kubernetes 中,最小的管理元素不是一个个独立的容器,而是 Pod;一个 Pod 是一个容器环境下的“逻辑主机”,一个 Pod 是由多个相关的并且共享磁盘的容器组成;在同一个 Pod 里,容器之间的端口不能重复,否则 Pod 会起不来,或者起来后无限重启
2. Node
Node 是 Pod 真正运行的主机,可以是物理机,也可以是虚拟机;为了管理 Pod,每个 Node 节点上至少要运行 container runtime(比如 Docker)、kubelet 和 kube-proxy 服务;Node 本质上不是 Kubernetes 来创建的,Kubernetes 只是管理 Node 上的资源;虽然可以通过 manifest 创建一个 Node 对象(如下 json 所示),但 Kubernetes 也只是去检查是否真的是有这么一个 Node,如果检查失败,也不会往上调度 Pod
3. Service
Service 是一个抽象的概念,是 K8s 里面的精华;每个 K8s 上的 App,都可以申请集群内部的“名号”,用来代表自己;K8s 就会给你的 App 分配一个 Service 许可证,许可证上面带着“假 IP”,任何集群内部只要访问这个 IP,就等于访问你的 App
假设我们拥有一些 Pod,每个 Pod 都开放了 9083 端口,并且都带有一个标签 app=MyApp;如下这段 json 代码会创建一个新的 Service 对象,名称为 my-dlcatalog-metastore-service,并且会连接目标端口 9083;并且带有标签 app=MyApp 的 Pod 会被分配一个 ip 地址,这个 ip 是给 kube-proxy 使用的,集群内部只要访问这个 ip,就等于访问你的 App;需要注意的是,K8s 里面的 Pod 实际 ip 一般没什么用
4. ConfigMap
ConfigMap 用于保存配置数据的键值对,可以用来保存单个属性,也可以用来保存配置文件;ConfigMap 跟 secret 很类似,但它可以更方便地处理不包含敏感信息的字符串;
使用 volume 将 ConfigMap 作为文件或目录直接挂载
如下表示将创建的 ConfigMap 直接挂载至 Pod 的/etc/config 目录下
四、Kubernetes 资源花式调度

指定 Node 节点调度
有三种方式指定 Pod 只运行在指定的 Node 节点上
方式一:
nodeSelector:只调度到匹配指定 label 的 Node 上
方式二:
nodeAffinity:功能更丰富的 Node 选择器,比如支持集合操作
nodeAffinity 目前支持两种:requiredDuringSchedulingIgnoredDuringExecution 与 preferredDuringSchedulingIgnoredDuringExecution,分别代表必须满足条件和优选条件
比如下面的例子代表调度到包含标签 http://kubernetes.io/e2e-az-name 并且值为 e2e-az1 或 e2e-az2 的 Node 上,并且优选还带有标签 another-node-label-key=another-node-label-value 的 Node
方式三:
podAffinity:调度到满足条件的 Pod 所在的 Node 上
podAffinity 基于 Pod 的标签来选择 Node,仅调度到满足条件 Pod 所在的 Node 上,支持 podAffinity 和 podAntiAffinity
这个功能比较绕,以下面的两个例子作为讲解:
第一个例子表示:
如果一个 “Node 所在 Zone 中包含至少一个带有 security=S1 标签且运行中的 Pod”,那么可以调度到该 Node;不调度到 “包含至少一个带有 security=S2 标签且运行中 Pod” 的 Node 上
第二个例子表示:
如果一个 “Node 所在 Zone 中包含至少一个带有 appVersion= jwsdlcatalog-x86_64-1.0.1.20200918144530 标签且运行中的 Pod”,那么推荐不调度到该 Node;不调度到 “包含至少一个带有 app= jwsdlcatalog-x86_64 标签且运行中 Pod” 的 Node 上
注:本文纯属个人观点,部分图片如有雷同,纯属意外
版权声明: 本文为 InfoQ 作者【华为云开发者社区】的原创文章。
原文链接:【http://xie.infoq.cn/article/d2a286c7a475e464a6882cff1】。文章转载请联系作者。
评论