学习视频:Kubernetes基本概念和应用_哔哩哔哩_bilibili
零 . 架构概览
![](https://img-blog.csdnimg.cn/e294e28cf3d64e259809f5d2f72e0cb1.png)
- master节点:管理调度集群资源,一般为多节点构成,可以是物理机,也可以是虚拟机。
- worker节点:资源的提供者,一般为多节点构成,可以是物理机,也可以是虚拟机。
- pod:绿色部分,相当于云平台的虚拟机
- 容器container:cpu和内存、资源的隔离单位,多节点部署,主容器+辅助容器。它共享pod的存储资源和网络栈。
- k8s平台:解决集群资源调度的问题,将空闲的pod合理的分配到worker节点上面去。监控集群,如有节点或pod挂了,重新协调和启动pod,保证应用高可用,称为治愈。保证集群的网络,保证pod服务之间可以互通互联。
master节点组件构成
![](https://img-blog.csdnimg.cn/cc10833e32b64f54abc41218e7e8fcc0.png)
- master节点:k8s集群的大脑,分布式数据库etcd,k8s集群集中的状态存储:节点,pod,发布,配置等都存储在里面。高可用部署的话,至少需要部署3个节点。
- 所有的操作都是通过调用apiserver来实现的,可以认为是etcd的代理。
- scheduler:负责调度决策的组件,比如:pod应该分配到那些worker里面去。
- controller manager:保证集群状态最终一致的组件。通过apiserver 监控集群的状态,确保实际状态与预期状态一致。
worker节点组件构成
![](https://img-blog.csdnimg.cn/b58dd7398fcb436db1c4ea908b38bf27.png)
- kubelet :worker节点的资源管理者,相当于agent角色。监听apiserver的事件,执行master下发的任务,汇报情况给APIserver等,是worker节点的小脑。
- container runtime:结点容器资源的管理者。kubelet不直接参与动作,而是委托给container runtime。比如:启动或关闭容器,收集容器状态。在启动容器的时候,如果本地没有镜像缓存,会从docker hub 去拉取相应的镜像,缓存到本地。
- kube-proxy:管理k8s中的服务网络的(servernetwork),当需要把服务暴露给外网的时候,需要kube-proxy代理作为转发。
- pod:瞬息的,不固定的,ip可能会变(可变+不可变)。
K8S发布pod流程样例
![](https://img-blog.csdnimg.cn/fd61cf06c4b44e5ea412bcb0c256e712.png)
流程解读如下:
1、使用kubectl命令行工具向apiserver发送一个创建一个新的replicaset 的请求。apiserver会将该资源请求先存储到etcd中。
2、controller manager 监听replicaset的 创建或修改相关的事件。接收到上一步的创建pod的一个通知。
3、controller manager比较当前集群状态和预期集群的状态,当发现不一致时,调用第一步中的创建pod的模板,在apiserver中创建预期的pod。
4、scheduler监听到apiserver创建新pod的请求,运行调度算法,选择空闲的work节点。然后通过apiserver更新创建pod的定义。把这些pod指定到具体要发布到哪些work节点上。、
注意,此时:controller manager、scheduler 只是通过apiserver更新了希望创建的集群状态,pod并没有真正创建。
5、一旦pod被分配到某个worker节点,apiserver就会通知相应节点上面的kubelet,kubelet接到通知以后,就会指示他的节点上的container runtime 去运行对应的容器。
6、container runtime就会开始下载镜像,启动容器。同时kubelet开始监控容器的运行。
K8S总体架构
![](https://img-blog.csdnimg.cn/39d020d7822b483288db9e071b37cb68.png)
小结各个组件的作用
![](https://img-blog.csdnimg.cn/518df18ebd29498ab21c9455f12c82db.png)
虚拟机抽象-pod
![](https://img-blog.csdnimg.cn/97349990f07f41d1a8073b53b089503f.png)
- 容器 = 应用 + 操作系统,是一种资源隔离抽象;
- pod 是容器的包装,是一种虚拟机抽象;
- k8s 是管理pod虚拟机的数据中心抽象;
https://kubernetes.io/docs/concepts/workloads/pods/pod/
- 一般是一个pod对应一个容器,但也有一对多的情况,一个主,一个辅助。
![](https://img-blog.csdnimg.cn/img_convert/dcda87ddd472623bfd07116bffdce974.png)
https://hub.docker.com/r/spring2go/spring-petclinic/tags
发布pod:按照要求书写发布规范。
![](https://img-blog.csdnimg.cn/img_convert/af61f54335edc253913aedb7d768c025.png)
Pod | Kubernetes
如何访问pod?
![](https://img-blog.csdnimg.cn/img_convert/ff2631be95638cee732de70c1c04963e.png)
针对测试环境:
端口转发功能开启外部访问:
kubectl port-forword petclinic 8080:8080 (主机端口:pod端口)
nodeport service
![](https://img-blog.csdnimg.cn/img_convert/436279424b6f303496a80ca81be22f59.png)
通过在数据中心的网络边界部署反向代理(proxy service)将内网资源暴露出去,使得公网可访问。
反向代理2大作用:
反向路由 + 负载均衡
![](https://img-blog.csdnimg.cn/img_convert/94007231a4f7d01d02cfcecad94a3016.png)
label:大标签机制,键值对
selector:路由选择机制,pod一致性。
service:负载均衡
![](https://img-blog.csdnimg.cn/img_convert/a527e229e0e78e3c3c710e5f872e6a8f.png)
![](https://img-blog.csdnimg.cn/img_convert/f461f69509f190e258e28631afbed0ed.png)
![](https://img-blog.csdnimg.cn/img_convert/da8e06fc48463361364cad46bb2c1863.png)
![](https://img-blog.csdnimg.cn/img_convert/a93776276e3a370d5e23d6555d60eb3c.png)
添加一个:labels: 不然无法访问。
![](https://img-blog.csdnimg.cn/img_convert/c8186570a7fef83f083459731bd7381e.png)
K8S反向代理-service
传统反向代理
![](https://img-blog.csdnimg.cn/31aa635715b749aba5108f34a00686aa.png)
配置反向代理将web应用暴露出去。
反向代理作用:4层/7层
1、反向路由:将web请求反向路由到内部的应用地址。里面有个地址映射,比如:将域名映射到内部应用的IP,可直接在代理服务器配置。
2、负载均衡
nodeport service -k8s的反向代理
![](https://img-blog.csdnimg.cn/b04bd8bfb41644bb8a51078b296fe8ee.png)
作用:
1、反向路由
2、负载均衡
解释:
1、k8s中service是一个抽象概念。在k8s中,service将流量反向路由到后端的pod是通过selector和labels机制实现的。labels是一种打标签机制,selector是一种路由选择机制。selector上的标签和labels上的标签跨域匹配上,那么selector就将流量路由到匹配的pod上。该机制对比传统的nginx更加灵活,,能力更强。
![](https://img-blog.csdnimg.cn/6a0abf7d7fbd48a7bafff4d9d0d11b53.png)
service发布规范样例:
![](https://img-blog.csdnimg.cn/08356244361345049d5d705d677238e9.png)
nodeport 范围:30000~32767
![](https://img-blog.csdnimg.cn/f73763c4241442a3b514f7bfccd29549.png)
通过service实现蓝绿发布
![](https://img-blog.csdnimg.cn/b0f81d9c0cf64a8db082517a54d92b84.png)
![](https://img-blog.csdnimg.cn/38e831b3d68248c58918b47111ac0c58.png)
Replicaset
![](https://img-blog.csdnimg.cn/2c36f6df2fc74701822cc9514b0c84c1.png)
随机路由,默认路由到3个pod中的随机一个。
Replicaset负责pod的高可用,具有自愈能力。若集中中的一个或一些pod删除了或不工作了,Replicaset会负责重新创建新的pod。
发布规范案例:
![](https://img-blog.csdnimg.cn/9c4e4080654d4942bf814989ca442588.png)
replicas:指定副本数量
滚动发布原理和Deployment
滚动发布- rolling update:
定义:一种高级的发布策略,按照批次依次替换老版本,逐步升级到新版本。发布过程中,应用不中断,用户体验平滑。
流程:逐步替换
每批次发布数量可以大于1,每个批次发布数量也可以各不相同。
![](https://img-blog.csdnimg.cn/4888cfd26b114a5180e00a3d6e1db20a.png)
蓝绿发布vs滚动发布
![](https://img-blog.csdnimg.cn/d8969b30f739477799bd214e38a4ff94.png)
K8S发布抽象Deployment
![](https://img-blog.csdnimg.cn/757b18b52fd940eb8b29a6e7d8990e97.png)
Deployment 对replicaset再次包装。
Deployment滚动发布流程
![](https://img-blog.csdnimg.cn/0a006f60ad6e44c2aa1a2de2eccb0412.png)
发布流程样例:
![](https://img-blog.csdnimg.cn/53b3f57a42c1467394b648a0813aba63.png)
K8S内部反向代理-clusterip-service
内部服务之间如何相互访问?
![](https://img-blog.csdnimg.cn/48cc529aec4f486c9d0857f0f17ba826.png)
解决方法:引入一个反向代理抽象,反向代理不仅可以部署在外部与内部边界,也可在内部pod之间部署。
![](https://img-blog.csdnimg.cn/14feee3877c94030a157e4f785d8c920.png)
原理:
mysql-pod.yml
![](https://img-blog.csdnimg.cn/e48c1e86166141c3abc46d8f99fd529e.png)
mysql-service.yml
![](https://img-blog.csdnimg.cn/5547981ed3ff424b955acb4790abb4fa.png)
petclinic-deployment.yml
![](https://img-blog.csdnimg.cn/f2f44e9e2f814bbbb4969dab2495fcd0.png)
petclinic-service.yml
![](https://img-blog.csdnimg.cn/8545fe4c5faa4e718bb5b17f13a3df62.png)
部署:
由于依赖关系原因,先部署mysql。
kubectl apply -f mysql-pod.yml
kubectl apply -f mysql-service.yml
kubectl apply -f petclinic-deployment.yml
kubectl apply -f petclinic-service.yml
![](https://img-blog.csdnimg.cn/0a583951b8bd4edfbc5ea60ce2743268.png)
总结:
![](https://img-blog.csdnimg.cn/a38149a3ce874443878e01a211c6f832.png)
K8S的namespace和kube-dns
域名--->IP ?
![](https://img-blog.csdnimg.cn/e5619d7a456a4ef791a7ee3afdbef2a2.png)
namespace的概念:
名字空间之间是逻辑隔离的,名字空间可自定义。
![](https://img-blog.csdnimg.cn/693933476fca47df999a910d9952cfc9.png)
系统名字空间组件:
get all -n kube-system
![](https://img-blog.csdnimg.cn/c0be0d689d804e968fbb0924cac5c9b4.png)
域名--->IP ?![](https://img-blog.csdnimg.cn/596cab78769d48bf93479aff5488f3f4.png)
K8S的配置抽象configmap原理
ConfigMap是一个用于存储应用程序配置数据的Kubernetes对象。它允许将应用程序配置数据与容器镜像分开存储,这样可以更容易地管理和升级应用程序,而不必重新构建和重建容器镜像。
ConfigMap的实现原理是通过将配置文件数据存储在Kubernetes的etcd中,并将该数据挂载到容器的特定路径中。这样,在容器启动时,它会读取挂载的ConfigMap数据,并将其作为容器内的配置文件使用。
ConfigMap支持多种类型的数据,包括简单的键值对、INI文件和JSON/YAML格式的文本文件。配置数据可以直接在Kubernetes集群中创建,也可以从外部文件或环境变量中导入。
当ConfigMap中的配置数据发生更改时,Kubernetes会通知相关的容器,以便它们可以重新加载新的配置数据。这使得应用程序的配置更加灵活和可扩展,可以随时进行修改和升级,而无需重新构建和重建容器镜像。
![](https://img-blog.csdnimg.cn/a63b3163f1d040959c47bc1b1473a30f.png)
发布时,configmap的配置以环境变量的形式,注入到pod中。
![](https://img-blog.csdnimg.cn/fd8e7344938942c180fe0520e12afc2a.png)
将配置定义到一个公用的configmap中, 发布后cinfigmap的配置会注入到后台这些pod中,很好的解决了冗余和维护困难的问题。
演示部署架构
![](https://img-blog.csdnimg.cn/ecd8c3c8ef0b411da33f7c0a46e2a780.png)
pod的配置不用直接写到里面,而是从configmap来获取。
ENV-->configmap
![](https://img-blog.csdnimg.cn/9a22612810e64f83ad5a7911d7730be6.png)
deployment文件变化:
envfrom直接指向configmap,name为configmap的name。
K8S机密配置抽象secret
![](https://img-blog.csdnimg.cn/a82bde1c229b4ecc8f1019e067a1c159.png)
提供比较安全的存储敏感数据的方式。
![](https://img-blog.csdnimg.cn/81af5ca0dd534b0eb0135feaeb124a06.png)
![](https://img-blog.csdnimg.cn/e2cadb6eef2f4237b1a8dfd2b1666602.png)