应用在k8s上运行的几种网络模式
应用部署在k8s上,首先想到的是应用k8s的默认service模式配置。
应用通过service向集群内部(ClusterIP)和集群外部(NodePort)暴露服务。k8s中的其他 应用通过kube-dns提供的dns解析功能,访问servicename:port即可访问service后面的pod的服务。这需要两个应用服务之间的交互不需要记录对方的hostname或者IP,例如,假如应用服务通过socket连接到另一个应用服务,并通过记录他的IP或者Hostname,以便下次连接时作为验证对方。这样的话会出现servicename:port与podname:port或者podIP:port不符。
k8s hostnetwork配置
解决servicename:port与podname:port或者podIP:port不符的问题,可以把被验证的应用使用hostnetwork。
应用与宿主机共享网络空间,也就是k8s节点的IP,端口占用与宿主机一样。这样应用的IP就是宿主机的IP,与另一个应用的连接也不经过service IP这一层。另一个应用仍然采用kubernetes的pod网络模型,为使使用hostnetwork的应用能对其他应用的service name进行DNS解析,需要设置参数hostNetwork: true和dnsPolicy: ClusterFirstWithHostNet。
该配置的缺点:应用的网络与宿主机一样,需保证应用需要监听的网络端口在宿主机上没有被占用。并且无法使用容器漂移,动态伸缩特性。
k8s headless service配置
解决servicename:port与podname:port或者podIP:port不符的问题,还有一种方法,就是把被验证的应用配置使用headless service。headless service即是把service type为ClusterIP的service配置spec.clusterIP为None,这样的话就不会为其分配serviceIP,kube-dns解析servicename:port就会变成podIP:port。在把servicename配置和pod的hostname一样,这样的kube-dns解析servicename:port就与podhostname:port一样。达到了获得实际podIP的目的。相比hostnetwork配置,这个配置没有它所具有的缺点。
k8s statefulset headless service配置
上面提到headless service可以解决servicename:port与podname:port或者podIP:port不符的问题。这是针对一个应用pod在service后面,另一个应用pod在service的前面。现在假设同一个service后面的pod之间需要获悉对方的hostname或者podIP进行通信,怎么办?例如,storm的worker组件之间需要通过hostname通信,我们想要能快速伸缩worker组件,因此把所有的worker放到同一个service后面。
一种解决办法就是使用statefulset加headless service配置,这种配置kube-dns可以解析
podname.servicename.namespacename.svc.cluster.local对应到podIP。在同一个statefulset的pod的podname都是podname-0,podname-1,podname-2等数字递增的命名。对于podname-0可以解析
podname-1.servicename.namespacename.svc.cluster.local到podname-1的podIP。
在podname-0中使用命令
nslookup podname-1
会解析podname-1.namespacename.svc.cluster.local。因此需要我们修改/etc/resolv.conf
文件
在search 后面加上 servicename.namespacename.svc.cluster.local,这样就达到了解析到
podname-1.servicename.namespacename.svc.cluster.local的目的。
具体做法就是在statefulset的pod配置中加入lifecycle的postStart配置
lifecycle:
postStart:
exec:
command:
- /bin/sh
- -c
- >
if [ -z "$(grep servicename /etc/resolv.conf)" ]; then
sed "s/^search \([^ ]\+\)/search servicename.\1 \1/" /etc/resolv.conf > /etc/resolv.conf.new;
cat /etc/resolv.conf.new > /etc/resolv.conf;
rm /etc/resolv.conf.new;
fi;
至此,headless service后面的statefulset的pod之间可以相互通信了。
本文转自CSDN-应用在k8s上运行的几种网络模式
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
啥叫K8s?啥是k8s?
•Kubernetes介绍 1.背景介 绍 云计算飞速发展 - IaaS - PaaS - SaaS Docker技术突飞猛进 - 一次构建,到处运行 - 容器的快速轻量 - 完整的生态环境 2.什么是kubernetes 首先,他是一个全新的基于容器技术的分布式架构领先方案。Kubernetes(k8s)是Google开源的容器集群管理系统(谷歌内部:Borg)。在Docker技术的基础上,为容器化的应用提供部署运行、资源调度、服务发现和动态伸缩等一系列完整功能,提高了大规模容器集群管理的便捷性。 Kubernetes是一个完备的分布式系统支撑平台,具有完备的集群管理能力,多扩多层次的安全防护和准入机制、多租户应用支撑能力、透明的服务注册和发现机制、內建智能负载均衡器、强大的故障发现和自我修复能力、服务滚动升级和在线扩容能力、可扩展的资源自动调度机制以及多粒度的资源配额管理能力。同时Kubernetes提供完善的管理工具,涵盖了包括开发、部署测试、运维监控在内的各个环节。 Kubernetes中,Service是分布式集群架构的核心,一个Service对象拥有如下关键特征: 拥有一个...
- 下一篇
基于k8s部署的应用(服务)如何访问
当我们使用k8s部署了一套应用时(比如一个blog系统),要怎么访问它便成了我们最直接的问题,这里 的访问应该同时包括了对外(tomcat)和对内(mysql)服务。 要弄清楚这个问题,首先我们需要了解kubernetes网络模型设计的基础原则: 每个pod都拥有一个独立的ip地址,而且假定所有的pod都在一个直接连通的、扁平的网络空间中。 回到题目的问题,我们这里分两步分讨论: 1. 集群内部访问 1.1 通过pod的ip访问 通过这种方式访问是不可靠的,因为当pod重启后,它的ip会重新分配 1.1.1 因为pod中所有容器共享一个网络堆栈(pod的ip地址是docker0分配的),所以同一个pod中的容器可以通过localhost来互相访问 1.1.2 不同pod的容器访问可以使用endpoint方式:pod的ip+容器的端口 1.2 通过服务访问 通过创建service,可以为一组具有相同功能的容器应用提供一个统一的入口地址,这个地址不会因为pod的重启而发生改变,所以是可靠的。 访问方式:服务的clusterIP(这个是系统分配的全局唯一ip)+containerPort(应...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- Docker使用Oracle官方镜像安装(12C,18C,19C)
- SpringBoot2整合MyBatis,连接MySql数据库做增删改查操作
- CentOS8编译安装MySQL8.0.19
- CentOS6,7,8上安装Nginx,支持https2.0的开启
- SpringBoot2整合Redis,开启缓存,提高访问速度
- CentOS7编译安装Cmake3.16.3,解决mysql等软件编译问题
- CentOS7编译安装Gcc9.2.0,解决mysql等软件编译问题
- Docker快速安装Oracle11G,搭建oracle11g学习环境
- MySQL8.0.19开启GTID主从同步CentOS8
- SpringBoot2全家桶,快速入门学习开发网站教程