kubernetes 已经成为容器编排领域的王者,它是基于容器的集群编排引擎,具有扩展集群、滚动升级回滚、弹性伸缩、自动治愈、服务发现等多种特性能力。更多关注Kubernetes的介绍请参阅旧文:Kubernetes 前世此生( 附学习导图 )node
本文将带着你们快速了解 kubernetes ,从零开始学习 kubernetes 技术。docker
从宏观上来看 kubernetes 的总体架构,包括 Master、Node 以及 Etcd。后端
Master 即主节点,负责控制整个 kubernetes 集群。它包括 Api Server、Scheduler、Controller 等组成部分。它们都须要和 Etcd 进行交互以存储数据。设计模式
Node 即工做节点,为整个集群提供计算力,是容器真正运行的地方,包括运行容器、kubelet、kube-proxy。api
deployment 是用于编排 pod 的一种控制器资源,咱们会在后面作介绍。这里以 deployment 为例,来看看架构中的各组件在建立 deployment 资源的过程当中都干了什么。安全
至此,通过 kubenetes 各组件的分工协调,完成了从建立一个 deployment 请求开始到具体各 pod 正常运行的全过程。网络
在 kubernetes 众多的 api 资源中,pod 是最重要和基础的,是最小的部署单元。架构
首先咱们要考虑的问题是,咱们为何须要 pod?pod 能够说是一种容器设计模式,它为那些"超亲密"关系的容器而设计,咱们能够想象 servelet 容器部署 war 包、日志收集等场景,这些容器之间每每须要共享网络、共享存储、共享配置,所以咱们有了 pod 这个概念。并发
对于 pod 来讲,不一样 container 之间经过 infra container 的方式统一识别外部网络空间,而经过挂载同一份 volume 就天然能够共享存储了,好比它对应宿主机上的一个目录。app
更多关于Kubernetes pod 的详细介绍请参阅旧文:Kubernetes 之 Pod 实现原理
容器编排是 kubernetes 的看家本领了,因此咱们有必要了解一下。kubernetes 中有诸多编排相关的控制资源,例如编排无状态应用的 deployment,编排有状态应用的 statefulset,编排守护进程 daemonset 以及编排离线业务的 job/cronjob 等等。
咱们仍是以应用最普遍的 deployment 为例。deployment、replicatset、pod 之间的关系是一种层层控制的关系。简单来讲,replicaset 控制 pod 的数量,而 deployment 控制 replicaset 的版本属性。这种设计模式也为两种最基本的编排动做实现了基础,即数量控制的水平扩缩容、版本属性控制的更新/回滚。
水平扩缩容很是好理解,咱们只需修改 replicaset 控制的 pod 副本数量便可,好比从 2 改到 3,那么就完成了水平扩容这个动做,反之即水平收缩。
更新/回滚则体现了 replicaset 这个对象的存在必要性。例如咱们须要应用 3 个实例的版本从 v1 改到 v2,那么 v1 版本 replicaset 控制的 pod 副本数会逐渐从 3 变到 0,而 v2 版本 replicaset 控制的 pod 数会注解从 0 变到 3,当 deployment 下只存在 v2 版本的 replicaset 时变完成了更新。回滚的动做与之相反。
能够发现,在上述例子中,咱们更新应用,pod 老是一个一个升级,而且最小有 2 个 pod 处于可用状态,最多有 4 个 pod 提供服务。这种"滚动更新"的好处是显而易见的,一旦新的版本有了 bug,那么剩下的 2 个 pod 仍然可以提供服务,同时方便快速回滚。
在实际应用中咱们能够经过配置 RollingUpdateStrategy 来控制滚动更新策略,maxSurge 表示 deployment 控制器还能够建立多少个新 Pod;而 maxUnavailable 指的是,deployment 控制器能够删除多少个旧 Pod。
咱们了解了容器编排是怎么完成的,那么容器间的又是怎么通讯的呢?
讲到网络通讯,kubernetes 首先得有"三通"基础:
简单来讲,不一样 pod 之间经过 cni0/docker0 网桥实现了通讯,node 访问 pod 也是经过 cni0/docker0 网桥通讯便可。而不一样 node 之间的 pod 通讯有不少种实现方案,包括如今比较广泛的 flannel 的 vxlan/hostgw 模式等。flannel 经过 etcd 获知其余 node 的网络信息,并会为本 node 建立路由表,最终使得不一样 node 间能够实现跨主机通讯。
在了解接下来的内容以前,咱们得先了解一个很重要的资源对象:service。
咱们为何须要 service 呢?在微服务中,pod 能够对应实例,那么 service 对应的就是一个微服务。而在服务调用过程当中,service 的出现解决了两个问题:
pod 的 ip 不是固定的,利用非固定 ip 进行网络调用不现实 服务调用须要对不一样 pod 进行负载均衡 service 经过 label 选择器选取合适的 pod,构建出一个 endpoints,即 pod 负载均衡列表。实际运用中,通常咱们会为同一个微服务的 pod 实例都打上相似app=xxx的标签,同时为该微服务建立一个标签选择器为app=xxx的 service。
在有了上述"三通"的网络基础后,咱们能够开始微服务架构中的网络调用在 kubernetes 中是怎么实现的了。
这部份内容能够参考:Kubernetes 之服务发现,比较细节的地方能够参考上述文章,这里作一个简单的介绍。
首先是东西向的流量调用,即服务间调用。这部分主要包括两种调用方式,即 clusterIp 模式以及 dns 模式。
clusterIp 是 service 的一种类型,在这种类型模式下,kube-proxy 经过 iptables/ipvs 为 service 实现了一种 VIP(虚拟 ip)的形式。只须要访问该 VIP,便可负载均衡地访问到 service 背后的 pod。
上图是 clusterIp 的一种实现方式,此外还包括 userSpace 代理模式(基本不用),以及 ipvs 模式(性能更好)。
dns 模式很好理解,对 clusterIp 模式的 service 来讲,它有一个 A 记录是 service-name.namespace-name.svc.cluster.local,指向 clusterIp 地址。因此通常使用过程当中,咱们直接调用 service-name 便可。
南北向的流量,即外部请求访问 kubernetes 集群,主要包括三种方式:nodePort、loadbalancer、ingress。
nodePort 一样是 service 的一种类型,经过 iptables 赋予了调用宿主机上的特定 port 就能访问到背后 service 的能力。
loadbalancer 则是另外一种 service 类型,经过公有云提供的负载均衡器实现。
咱们访问 100 个服务可能须要建立 100 个 nodePort/loadbalancer。咱们但愿经过一个统一的外部接入层访问内部 kubernetes 集群,这就是 ingress 的功能。ingress 提供了统一接入层,经过路由规则的不一样匹配到后端不一样的 service 上。ingress 能够看作是"service 的 service"。ingress 在实现上每每结合 nodePort 以及 loadbalancer 完成功能。
到如今为止,咱们简单了解了 kubernetes 的相关概念,它大体是怎么运做的,以及微服务是怎么运行在 kubernetes 中的。因而当咱们听到别人讨论 kubernetes 时,咱们能够知道他们在讨论什么。
做者:fredalxin 地址:https://fredal.xin/what-is-ku...