参考链接：
https://blog.csdn.net/zkkzpp258/article/details/86541362
https://blog.csdn.net/Bubbler_726/article/details/85596418
https://blog.csdn.net/wx_15323880413/article/details/100516698
云计算与Kubernetes(k8s)
目录
-
发展经历
-
云计算交互标准（云服务分类)
- 公有云、私有云、混合云
-
云计算交互标准（云服务分类)
- Kubernetes特点
-
组件说明
-
K8S核心架构原理 （重点！！）
- Master Node的组件（重点！！）
- Worker Node的组件（重点！！）
- 其他组件
- 各组件间工作流程（重点！！）
-
K8S核心架构原理 （重点！！）
-
Kubernetes核心概念
- Deployment
- Pod
- Service
- Kubernetes中的资源
- Kubernetes集群搭建
发展经历
云计算交互标准（云服务分类）：
比如：
- Infrastructure as a Service( IaaS 基础设施服务) 例如：阿里云、AWS
- Platform as a Service( PaaS 平台服务) 例如：新浪云
- Softwate as a Service( SaaS 软件设施服务) 例如：office365
区别：
请设想你是一个餐饮业者，打算做披萨生意。
方案1：IaaS：
他人提供厨房、炉子、煤气，你使用这些基础设施，来烤你的披萨。
IaaS 是云服务的最底层，主要提供一些基础资源。它与 PaaS 的区别是，用户需要自己控制底层，实现基础设施的使用逻辑。
方案2：PaaS
除了基础设施，他人还提供披萨饼皮。
你只要把自己的配料洒在饼皮上，让他帮你烤出来就行了。也就是说，你要做的就是设计披萨的味道（海鲜披萨或者鸡肉披萨），他人提供平台服务，让你把自己的设计实现。
PaaS 提供软件部署平台（runtime），抽象掉了硬件和操作系统细节，可以无缝地扩展（scaling）。开发者只需要关注自己的业务逻辑，不需要关注底层。
方案3：SaaS
他人直接做好了披萨，不用你的介入，到手的就是一个成品。你要做的就是把它卖出去，最多再包装一下，印上你自己的 Logo。
SaaS 是软件的开发、管理、部署都交给第三方，不需要关心技术问题，可以拿来即用。
所以，对于自己的工作量(下图蓝色)：IaaS>PaaS>SaaS
公有云、私有云、混合云
公有云：
什么是公有云呢？设想一个场面，如果你制作了一个网站（代理+应用服务器+数据库），一般来说，都是只可以在本机装个tomcat,mysql等等进行调试，你使用的ip就是localhost，这种Web，一般称之为单机的服务。如果你想让别人也访问你的网页，当然是要把机器接入到Internet上。但是目前你完全不具备购买一台Web服务器的能力，这时候怎么办呢？没关系，你可以购买一台虚拟的云服务器。这台云服务器本身已经具备了一个公网的ip，如果你把服务部署在这台服务器上，那么它的localhost就是这个公网的ip了，你和你的朋友可以在随时随地访问了。因此，公有云的概念简单理解就是申请一台接入Internet的云主机，你可以对其随便搞（装系统、装应用、开关机），你只需要购买一个使用的类似租赁的费用，而并不需要购买它。
这里，你申请的“机器”，可能是一台虚拟机，也可能是一些容器，对于这些容器，一般称它们为“实例”。当代的互联网公司，在进行服务部署的时候，往往会选择部署实例而非虚拟机，至于为什么，可以参考虚拟机和容器的区别的文章。选用实例，是因为实例的部署是秒级的（虚拟机是分钟级别的），而且实例是APP层面的封装，更小更轻便，是对硬件的更有效地利用。
私有云：
私有云是为了解决安全问题的一种云计算方案。虽然公有云很方便，但是毕竟是把数据和资源都交给其它人了，这对于企业管理来说，是一个很大的隐患。毕竟，很多数据是无价的，很多企业把用户数据作为他们的灵魂支柱。因此，当今的企业常常不希望把数据和资源部署到公有云上，他们往往会自己出资搭建机房，这时的解决方案，就是私有云方案。私有云比起公有云，更加安全，但是，成本也更高。
混合云：
混合云是在成本和安全方面的一种折中方案。顾名思义，就是公有云和私有云的结合。数据依然是存到本地的机器上，但是一旦出现大规模的访问或者计算时，就会把这部分计算的需求转移到公有云平台上，实现不同场景的切换。与此同时，在混合云方案中，私有云还常常把公有云作为灾难恢复和灾难转移的平台。混合云在使用起来具有更高的灵活性，是企业在考虑成本效益下的首选方案。
如前文所述，混合云客户一般已经具备了私有云，希望通过对接公有云解决几方面的典型需求：
-
跨国：某大型公司在美国销售电子类产品，需要在美国连接该企业的销售系统，通过本地私有云加AWS公有云实现；
-
灾备：将一部分系统或者数据定期备份到公有云上；
-
性能和高可用：利用公有云的CDN、全局负载均衡等能力提供更好可用性和性能；
-
爆发：客户业务需要短时爆发（bursting），满足业务需求同时节省成本。
混合云供应商主要包含：公有云提供商提供混合云能力、私有云供应商提供混合云能力、混合云创新企业等。
历程
MESOS Apache下的分布式资源管理框架 在2019.5，最大使用者Twitter放弃MESOS，转型Kubernetes。
Docker Swarm Docker母公司为Docker开发的分布式资源管理框架 在2019.7，阿里云宣布，将Docker Swarm从阿里云的选择列表中剔除。
Kubernetes Google公司 10年容器化基础架构 采用Go语言对自己的borg系统进程翻写 ----> Kubernetes
Kubernetes特点
K8S官网： https://kubernetes.io/zh-cn/docs/home/
K8S是Kubernetes的全称，源于希腊语，意为“舵手”或“飞行员”，官方称其是： 用于自动部署、扩展和管理“容器化(containerized) 应用程序”的开源系统。
总结来说： K8S是负责自动化运维管理多个Docker程序的集群
核心特性：
- 服务发现与负载均衡：无需修改你的应用程序即可使用陌生的服务发现机制
- 存储编排：自动挂载所选存储系统，包括本地存储
- Secret和配置管理：部署更新Secrets和应用程序的配置时不必重新构建容器镜像，且不必将软件堆栈配置中的秘密信息暴露出来
- 批量执行：除了服务之外，Kubernetes还可以管理你的批处理和CI工作负载，在期望时替换掉失效的容器
- 水平扩缩：使用一个简单的命令、一个UI或基于CPU使用情况自动对应用程序进行扩缩
- 自动化上线和回滚：Kubernetes会分步骤的针对应用或其配置的更改上线，同时监视应用程序运行状况以确保你不会同时终止所有实例。
- 自动装箱：根据资源需求和其他约束自动放置容器，同时避免影响可用性
- 自我修复：重新启动失败的容器，在节点死亡时替换并重新调度容器，杀死不响应用户定义的健康检查的容器。
组件说明
K8S核心架构原理
K8S是属于主从设备模型(Master-Slave架构)，即有Master节点负责核心的调度、管理和运维，Slave节点则执行用户的程序。但是在K8S中，主节点一般被称为Master Node 或者 Head Node，而从节点则被称为Worker Node 或者 Node
注意： Master Node和Worker Node是分别安装了K8S的 Master和Worker组件的实体服务器，每个Node都对应了一台实体服务器（虽然Master Node可以和其中一个Worker Node安装在同一台服务器，但是建议Master Node单独部署），所有Master Node和Worker Node组成了K8S集群，同一个集群可能存在多个Master Node和Worker Node。
Master Node的组件：
- Api Server : K8S的请求入口。 API Server负责接收K8S所有请求(来自UI界面或者CLI命令行工具)，然后API Server根据用户的具体请求，通知其他组件。
- Scheduler : K8S所有Worker Node 的调度器。 当用户要部署服务时，Scheduler会选择最合适的Worker Node 来部署。
- Controller Manager ： K8S所有Worker Node的监控器。 Controller Manager有很多具体的Controller，如：Node Controller、Service Controller、Volume Controller等。Controller负责监控和调整在Worker Node上部署的服务的状态，比如用户要求A服务部署2个副本，那么当其中一个服务挂了的时候，Controller会马上调整，让Scheduler再选择一个Worker Node重新部署服务。
- etcd ： K8S的存储服务。 CoreOS公司用Go语言编写的开源键值对数据库，官网定义为一个可信赖的分布式键值存储服务。 etcd存储了K8S的关键配置和用户配置，K8S中仅API Server才具备读写权限操作etcd，其他组件必须通过API Server的接口才能读写数据。
Worker Node的组件：
- Kubelet ：Worker Node的监视器，以及与Master Node的通讯器。 Kubelet是Master Node安插在Worker Node上的“眼线”，它会定期向Master Node汇报自己Node上运行的服务的状态，并接收来自Master Node的指示采取调整措施。负责控制所有容器的启动停止，保证节点工作正常。
- Kube-Proxy : K8S的网络代理。 Kube-Proxy负责Node在K8S的网络通讯、以及对外部网络流量的负载均衡。
- Container Runtime ： Worker Node的运行环境。 即安装了容器化所需的软件环境确保容器化程序能够跑起来，比如Docker Engine运行环境
其他组件
- CoreDNS：可以为集群中的SVC创建一个域名IP的对应关系解析
- Dashboard：给K8S集群提供一个B/S结构的访问体系
- Ingress Controller：官方的Kubernetes只能实现四层代理，Ingress 可以实现七层代理。
- Federation：提供一个可以跨集群中心多K8S统一管理的功能。
- Prometheus：提供K8S集群的监控能力。
- ELK：提供K8S集群日志统一分析介入平台。
各组件间工作流程
例如：我们在master节点执行命令，要master部署一个nignx应用
kubectl create deployment nginx --image=nginx
- 这条命令首先发到master节点的网关API Server，这是master的唯一入口
- API Server将命令请求交给Controller Manager控制
- Controller Manager进行应用部署解析
- Controller Manager会生成一次部署信息，并通过API Server将信息存入etcd存储中
- Scheduler调度器通过API Server从etcd存储中，拿到要部署的应用，开始调度看哪个节点有资源适合部署
- Scheduler把计算出来的调度信息通过API Server存储到etcd中
- 每一个node节点的监控组件kubelet，随时和master保持联系（给API Server发送请求不断获取最新的数据），拿到master节点存储在etcd中的部署信息
- 假设node2节点的kubelet拿到部署信息，显示他自己节点要部署nginx应用
- kubelet就会run一个应用在node2服务器上，并随时给master节点汇报当前应用的状态信息
- node和master也是通过master的API Server组件联系的
- 每一个机器上的kube-proxy能知道集群的所有网络，只要node访问别人或者别人访问node，node上的kube-proxy网络代理自动计算进行流量转发
Kubernetes核心概念
Kubernetes有很多核心概念，我们先看下几个核心的概念。
Deployment
Deployment负责创建和更新应用程序的实例。 创建Deployment后，Kubernetes Master 将应用程序实例调度到集群中的各个节点上。如果托管实例的节点关闭或被删除，Deployment控制器会将该实例替换为群集中另一个节点上的实例。这提供了一种自我修复机制来解决机器故障维护问题。
Pod
Pod相当于逻辑主机的概念，负责托管应用实例。包括一个或多个应用程序容器（如 Docker），以及这些容器的一些共享资源（共享存储、网络、运行信息等）。
Service
Service是一个抽象层，它定义了一组Pod的逻辑集，并为这些Pod支持外部流量暴露、负载均衡和服务发现。
尽管每个Pod 都有一个唯一的IP地址，但是如果没有Service，这些IP不会暴露在群集外部。Service允许您的应用程序接收流量。Service也可以用在ServiceSpec标记type的方式暴露，type类型如下：
- ClusterIP(默认)：在集群的内部IP上公开Service。这种类型使得Service只能从集群内访问。
- NodePort：使用NAT在集群中每个选定Node的相同端口上公开Service。使用 <NodeIP>: <NodePort> 从集群外部访问Service。是ClusterIP的超集。
- LoadBalancer: 在当前云中创建一个外部负载均衡器(如果支持的话)，并为Service分配一个固定的外部 IP。是NodePort的超集。
- ExternalName：通过返回带有该名称的CNAME记录，使用任意名称（由spec中的externalName指 定）公开Service。不使用代理。
Kubernetes中的资源
k8s中所有的内容都抽象为资源， 资源实例化之后，叫做对象，上面说的那些核心概念都是k8s中的资源。
k8s中有哪些资源:
- 工作负载型资源(workload)： Pod，ReplicaSet，Deployment，StatefulSet，DaemonSet等等
- 服务发现及负载均衡型资源(ServiceDiscovery LoadBalance): Service，Ingress等等
- 配置与存储型资源： Volume(存储卷)，CSI(容器存储接口,可以扩展各种各样的第三方存储卷)
- 特殊类型的存储卷：ConfigMap(当配置中心来使用的资源类型)，Secret(保存敏感数据)， DownwardAPI(把外部环境中的信息输出给容器)
以上这些资源都是配置在名称空间级别
- 集群级资源：Namespace，Node，Role，ClusterRole，RoleBinding(角色绑定)， ClusterRoleBinding(集群角色绑定)
- 元数据型资源：HPA(Pod水平扩展)，PodTemplate(Pod模板,用于让控制器创建Pod时使用的模板)， LimitRange(用来定义硬件资源限制的)
网络通讯模式
Kubernetes 的网络模型假定了所有Pod都在一个可以直接连接的扁平的网络空间中，这在GCE（Google Compute Engine）里是现成的网络模型。Kubernetes 假定这个网络已经存在。而在私有云里搭建Kubernetes 集群，就不能假定这个网络已经存在了。 我们需要自己实现这个网络假设，将不同节点的Docker 容器之间的相互访问先打通，然后运行Kubernetes。
Pod网络通讯类型
- 同一个Pod内多个容器之间：pause服务，通过loaclhost即可访问
- 各Pod之间的通讯：Overlay Network
- Pod 与 Service 之间的通讯：各节点的Iptables规则，最新版本中加入了LVS
网络解决方案 Kubernetes+Flannel （常用）
Flannel 是 CoreOS 团队针对 Kubernetes 设计的一个网络规划服务，简单的说，它的功能是让集群中的不同节点主机创建的Docker容器都具有全集群唯一的虚拟Ip地址。而且它还能在这些IP地址直接建立一个覆盖网络(Overlay Network) ，通过这个覆盖网络，将数据包原封不动地传递到目标容器内。
文章来源：https://www.toymoban.com/news/detail-667844.html
ETCD 之 Flannel 提供说明
- ETCD存储管理Flannel可分配的 IP 地址段资源
- 监控 ETCD 中每个Pod的实际地址，并在内存中建立维护Pod节点路由表
不同情况下网络通讯方式
文章来源地址https://www.toymoban.com/news/detail-667844.html
到了这里，关于云计算与Kubernetes(k8s)的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！
