【51CTO.com原创稿件】上一篇文章我们着重讲解了 Docker,其实遗留了一个大问题。Docker 虽好用,但面对强大的集群,成千上万的容器,突然感觉不香了。
图片来自 Pexels
这时候就需要我们的主角 Kubernetes 上场了,先来了解一下 K8s 的基本概念,后面再介绍实践,由浅入深步步为营。
关于 K8s 的基本概念我们将会围绕如下七点展开:
Docker 的管理痛点
如果想要将 Docker 应用于庞大的业务实现,是存在困难的编排、管理和调度问题。
于是,我们迫切需要一套管理系统,对 Docker 及容器进行更高级更灵活的管理。
Kubernetes 应运而生!Kubernetes,名词源于希腊语,意为「舵手」或「飞行员」。
google 在 2014 年开源了 Kubernetes 项目,建立在 Google 在大规模运行生产工作负载方面拥有十几年的经验的基础上,结合了社区中最好的想法和实践。
K8s 是 Kubernetes 的缩写,用 8 替代了 「ubernete」,下文我们将使用简称。
什么是 K8s ?
K8s 是一个可移植的、可扩展的开源平台,用于管理容器化的工作负载和服务,可促进声明式配置和自动化。
K8s 拥有一个庞大且快速增长的生态系统。K8s 的服务、支持和工具广泛可用。
通过 K8s 我们可以:
K8s 有如下特点:
云架构 & 云原生
①云和 K8s 是什么关系
云就是使用容器构建的一套服务集群网络,云由很多的大量容器构成。K8s 就是用来管理云中的容器。
②常见几类云架构
常见几类云架构如上图所示:
如果觉得不好理解,推荐阅读这篇文章:如何通俗解释 IaaS、PaaS、SaaS 的区别:
https://www.zhihu.com/question/21641778/answer/62523535
可以预见:未来服务开发都是 Serverless,企业都构建了自己的私有云环境,或者是使用公有云环境。
③云原生
为了让应用程序(项目,服务软件)都运行在云上的解决方案,这样的方案叫做云原生。
云原生有如下特点:
K8s 架构原理
①K8s 架构
概括来说 K8s 架构就是一个 Master 对应一群 Node 节点。下面我们来逐一介绍 K8s 架构图中的 Master 和 Node。
Master 节点结构如下:
Node 节点结构如下:
在介绍完 K8s 架构后,我们又引入了很多技术名词。不要着急,先有整体概念,再各个击破。请耐心阅读下文,相信你一定会有不一样的收获。
K8s 核心组件
①K8s 组件
K8s 是用来管理容器,但是不直接操作容器,最小操作单元是 Pod (间接管理容器):
②Pod 是什么?
解释如下:
Pod 有自己的 IP 地址、主机名,相当于一台独立沙箱环境。
③Pod 到底用来干什么?
通常情况下,在服务部署时候,使用 Pod 来管理一组相关的服务。一个 Pod 中要么部署一个服务,要么部署一组有关系的服务。
一组相关的服务是指:在链式调用的调用连路上的服务。
④Web 服务集群如何实现?
实现服务集群:只需要复制多方 Pod 的副本即可,这也是 K8s 管理的先进之处,K8s 如果继续扩容,只需要控制 Pod 的数量即可,缩容道理类似。
⑤Pod 底层网络,数据存储是如何进行的?
具体如下:
⑥ReplicaSet 副本控制器
控制 Pod 副本「服务集群」的数量,永远与预期设定的数量保持一致即可。
当有 Pod 服务宕机时候,副本控制器将会立马重新创建一个新的 Pod,永远保证副本为设置数量。
副本控制器:标签选择器-选择维护一组相关的服务(它自己的服务)
selector: App = web Release = stable
在新版的 K8s 中,建议使用 ReplicaSet 作为副本控制器,ReplicationController 不再使用了。
⑦Deployment 部署对象
Deployment 部署对象如下:
ReplicaSet 副本控制器控制 Pod 副本的数量。但是,项目的需求在不断迭代、不断的更新,项目版本将会不停的的发版。版本的变化,如何做到服务更新?
部署模型:
⑧MySQL 使用容器化部署,存在什么样的问题?
问题如下:
对于 K8s 来说,不能使用 Deployment 部署有状态服务。
通常情况下,Deployment 被用来部署无状态服务,那么对于有状态服务的部署,使用 StatefulSet 进行有状态服务的部署。
什么是有状态服务?
什么是无状态服务?
⑨StatefulSet
为了解决有状态服务使用容器化部署的一个问题:
StatefulSet 保证 Pod 重新建立后,Hostname 不会发生变化,Pod 就可以通过 Hostname 来关联数据。
K8s 的服务注册与发现
①Pod 的结构是怎样的?
结构如下:
②Pod 网络
具体如下:
Pod 内部容器访问是 Localhost,Pod 之间的通信属于远程访问。
③Pod 是如何对外提供服务访问的?
Pod 是虚拟的资源对象(进程),没有对应实体(物理机,物理网卡)与之对应,无法直接对外提供服务访问。
那么该如何解决这个问题呢?Pod 如果想要对外提供服务,必须绑定物理机端口。
也就是说在物理机上开启端口,让这个端口和 Pod 的端口进行映射,这样就可以通过物理机进行数据包的转发。
概括来说:先通过物理机 IP+Port 进行访问,再进行数据包转发。
④一组相关的 Pod 副本,如何实现访问负载均衡?
我们先明确一个概念,Pod 是一个进程,是有生命周期的。宕机、版本更新,都会创建新的 Pod。
这时候 IP 地址会发生变化,Hostname 会发生变化,使用 Nginx 做负载均衡就不太合适了。
所以我们需要依赖 Service 的能力。
⑤Service 如何实现负载均衡?
简单来说,Service 资源对象包括如下三部分:
⑥Service VIP 更深入原理探讨
具体如下:
⑦Service 对象是如何和 Pod 进行关联的?
具体如下:
selector: app=x 选择一组订单的服务 pod ,创建一个 service; 通过 endpoints 存放一组 pod ip;
Service 通过标签选择器选择一组相关的副本,然后创建一个 Service。
⑧Pod 宕机、发布新的版本的时候,Service 如何发现 Pod 已经发生了变化?
每个 Pod 中都有 Kube-Proxy,监听所有 Pod。如果发现 Pod 有变化,就动态更新(etcd 中存储)对应的 IP 映射关系。
关键问题
①企业使用 K8s 主要用来做什么?
有如下三个方面:
②K8s 服务的负载均衡是如何实现的?
Pod 中的容器很可能因为各种原因发生故障而死掉。Deployment 等 Controller 会通过动态创建和销毁 Pod 来保证应用整体的健壮性。
换句话说,Pod 是脆弱的,但应用是健壮的。每个 Pod 都有自己的 IP 地址。
当 Controller 用新 Pod 替代发生故障的 Pod 时,新 Pod 会分配到新的 IP 地址。
这样就产生了一个问题:如果一组 Pod 对外提供服务(比如 HTTP),它们的 IP 很有可能发生变化,那么客户端如何找到并访问这个服务呢?
K8s 给出的解决方案是 Service。Kubernetes Service 从逻辑上代表了一组 Pod,具体是哪些 Pod 则是由 Label 来挑选。
Service 有自己 IP,而且这个 IP 是不变的。客户端只需要访问 Service 的 IP,K8s 则负责建立和维护 Service 与 Pod 的映射关系。
无论后端 Pod 如何变化,对客户端不会有任何影响,因为 Service 没有变。
③无状态服务一般使用什么方式进行部署?
Deployment 为 Pod 和 ReplicaSet 提供了一个 声明式定义方法,通常被用来部署无状态服务。
Deployment 的主要作用:定义 Deployment 来创建 Pod 和 ReplicaSet 滚动升级和回滚应用扩容和索容暂停和继续。
Deployment不仅仅可以滚动更新,而且可以进行回滚,如果发现升级到 V2 版本后,服务不可用,可以迅速回滚到 V1 版本。
作者:jartto
编辑:陶家龙
征稿:有投稿、寻求报道意向技术人请联络 editor@51cto.com
出处:http://jartto.wang/2020/07/15/start-k8s/
【51CTO原创稿件,合作站点转载请注明原文作者和出处为51CTO.com】