江苏建设招标网站,多语言建设外贸网站,海口网站关键词优化,财经网站建设方案最近跟朋友聊到了k8s
我#xff1a; “环境给了就只管用呗#xff0c;副本自动管理地妥妥的#xff0c;有啥可以复盘的#xff1f;“
朋友#xff1a; “容器的通讯与服务暴露还是有点东西的”
我#xff1a; “嗯#xff5e;#xff5e;#xff08;抿嘴点…最近跟朋友聊到了k8s
我 “环境给了就只管用呗副本自动管理地妥妥的有啥可以复盘的“
朋友 “容器的通讯与服务暴露还是有点东西的”
我 “嗯抿嘴点头k8s端口名称众多关系错综复杂,若要正确使用就需要理清它们复杂程度不亚于看懂明星们的前任关系图 :)”
那就安排 前言本篇通过一个demo证实了各端口之间的关系与所起的作用其过程涉及了容器之间的互相访问与前端反向代理最终将服务暴露给用户这一E2E过程。 一. 首先了解下k8s service的4种类别
1.ClusterIP为k8s内部的其他Pod提供静态的访问服务因为Pod的ip就像孩子的脸说变就变会导致其他pod不能稳定访问到该Pod。
2.NodePort允许用户从集群从外部访问内部Pod作用类似DNAT. 但是建议前端用Nginx反向代理不要用它进行暴露服务。
3.LoadBalancer 接入公有云实现负载均衡时使用它对接的组件不在K8s内注意与下图中的LoadBalancer:Ingress-Nginx-Controller 区分开。后者是部署在k8s内部的为内部容器提供反向代理。Ingress-Nginx-Controller 有机会再单独展开
4.ExternalName允许从容器内借助内部与外部的FQDN实现访问外部资源它不依赖ClusterIP。使用场景k8s内的应用需要访问外部重型的数据库服务之类本次画幅有限不做展开 二这个demo表面看起来是这样的
Pod间进行通讯且数据持久化保存。 还有这样前端页面实现负载均衡 三. 资源看起来是这样的 四. 背后的资源与端口是这样组织的请点开放大观摩 端口、服务关系确实比较多几句话难以表述清楚但是有几个点值得指出
1.k8s的资源里有各种port(containerPort,targetPort,Port,NodePort)图中标注了它们的位置与关系。同时澄清了一些问题例如内部服务发现并不依赖NodePortconteinerPort证明了都是依赖于标签选择器。
2.service中的ClusterIP扮演了内部访问的重要角色它与Port即容器端口为其他Pod提供服务暴露。
3.容器之间的路由由Kube-proxy维护保存在IPVS/IPtables两者从效果上一致只有大规模部署时的性能差别本实验用的IPVS仅作展示。
4.同一个Pod内是可以有多个容器的它们共用同一个PodIP它们的containerPort分别一一对应到targetPort端口号完全相同。但是前者是delpoyment级别的定义后者是service级别的定义。
5.ingress-nginx-controller是k8s自己发布的LB组件兼容性最好。管理员通过配置它的规则让它自动转译为内部nginx容器中的具体配置可进容器查看到。本例演示的是单域名单服务反向代理。多子域名多服务的负载均衡画不下了见谅有机会再单独复盘这部分再局部放大看看。
6.internalTrafficPolicy与externalTrafficPolicy比较容易演示但是画不下了。需要注意的是如果为local则服务pod接收到的IP地址是Flannel的地址而非客户端Pod地址。
7.手动给各个pod内塞了静态页面并留下文字标记方便curl侦测最终是哪个Pod在服务。
8.使用了了PVPVC让数据持久化即使mysql容器销毁数据也不会丢失需要展开的话再说。
9.想到啥再说吧写多了太难读图还是更清楚一些。 --- To Be Continued ---
