云社区 > 云博客 > 博客详情
云社区 > 云博客 > 博客详情

深入玩转K8S之外网如何访问业务应用

技术火炬手 发表于 2018-07-04 09:56:4707-04 09:56
技术火炬手 发表于 2018-07-04 09:56:4707-04 09:56
0
1

【摘要】 前面几篇文章学习了如何搭建K8S、如何部署应用、如何利用Label和DaemonSet来根据实际情况部署业务应用,这时候就有人问了,说都搭建完了那怎么访问我的业务应用啊,那么本篇文章就来讲述下如何访问应用,同时还有一个问题就是现在我的业务分配在多个Pod上,那么如果我某个Pod死掉岂不是业务完蛋了,当然也会有人说Pod死掉没问题啊,K8S自身机制Deployment和Controller会动...

前面几篇文章学习了如何搭建K8S、如何部署应用、如何利用Label和DaemonSet来根据实际情况部署业务应用,这时候就有人问了,说都搭建完了那怎么访问我的业务应用啊,那么本篇文章就来讲述下如何访问应用,同时还有一个问题就是现在我的业务分配在多个Pod上,那么如果我某个Pod死掉岂不是业务完蛋了,当然也会有人说Pod死掉没问题啊,K8S自身机制Deployment和Controller会动态的创建和销毁Pod来保证应用的整体稳定性,那这时候还会有问题,那就是每个Pod产生的IP都是动态的,那所以说重新启动了我对外访问的IP岂不是要变了,别急,下面我们来解决下这个问题。

 

可以通过Service来解决如上所遇到的问题,那么什么是Service呢?

 

Service是kubernetes最核心的概念,通过创建Service,可以为一组具有相同功能的容器应用提供一个统一的入口地址,并且将请求进行负载分发到后端的各个容器应用上。

 

简单来说Service就是一个把所有Pod都池化的一个组,然后对外统一固定一个IP,具体是哪些Pod可以通过之前介绍到的Label标签来进行设置。

 

在创建Service之前先看看我们在部署应用的时候创建的nginx.yml

博客01.png

刚在有提到,就是说哪些Pod被Service池化是根据Label标签来的,那么可以看到图上所标识的nginx字样,后面我们创建Service会用到。

 

下面来创建个Service看看

博客02.png

解释下这个yml文件哈,其意思就是说呢V1是api的版本,然后Kind表示当前资源类型为Service,selector选择之前Label标签为nginx的Pod作为Service池化的对象,最后说的是把Service的8080端口映射到Pod的80端口。


执行kubectl apply创建Servie nginx-svc

1
kubcetl apply –f nginx-svc.yml

 

创建完成之后nginx-svc会分配到一个cluster-ip,可以通过该ip访问后端nginx业务。

 

创建完之后可以查看service详情查看后端都包含哪些pod

1
kubectl describe service nginx-svc

 博客06.png

那它是怎么实现的呢?答案是通过iptables实现的地址转换和端口转换,可以用iptables-save查看。

 

那这时候有人说了,还是不能外网访问啊,别急下面我们来进行外网地址访问设置。在实际生产环境中,对Service的访问可能会有两种来源:Kubernetes集群内部的程序(Pod)和Kubernetes集群外部,为了满足上述的场景,Kubernetes service有以下三种类型:

 

1.ClusterIP:提供一个集群内部的虚拟IP(与Pod不在同一网段),以供集群内部的pod之间通信使用。

 

2.NodePort:在每个Node上打开一个随机端口并且每个Node的端口都是一样的,通过<NodeIP>:NodePort的方式Kubernetes集群外部的程序可以访问Service。

 

3.LoadBalancer:利用Cloud Provider特有的Load Balancer对外提供服务,Cloud Provider负责将Load Balancer的流量导向Service。

 

本篇文章我们着重讲下第二种方式,也就是NodePort方式,修改nginx-svc.yml文件,也就是刚才前面创建的Service文件,相信细心的同学会发现在之前截图的时候已经做好了NodePort,因为我的环境已经配置好了所以这样就不在截图了,配置很简单,可以网上看下截图,就是添加一个type:NodePort,然后重新创建下nginx-svc,命令的话和创建的命令一样,我们来看看创建完事的结果。

博客05.png

如果刚开始你没有设置NodePort这个type的时候在端口那只会显示一个8080端口,而设置了之后会看到多了一个端口也就是31337,那8080大家斗志是cluster-ip监听的端口,那31337就是在节点上新起的一个端口,Kubernetes会从30000~32767中分配一个可用的端口,每个节点都会监听这个端口,并转发给Service,也就是防止说一个节点挂了影响访问。可能有人会问了,说这里的Service可不可以固定?当时可以了,可以在Service nginx-svc.yml文件里面添加一个nodeport。

博客07.png

最后我们可以验证下,我这里就不截图了,太长了。

curl x.x.x.x:31337

 

那OK可能会有人说这个访问是随机的还是负载均衡的?答案是负载均衡的,依旧是采用iptables实现的,感兴趣的可以自己研究下iptables里面做的那些规则,这里就不再赘述了。本文参考了Kubernetes 官网。


本文转自Devin博客51CTO博客,如需转载,请自行联系原作者。

原文链接


【版权声明】本文为华为云社区用户转载文章,如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件至:huaweicloud.bbs@huawei.com进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容。

分享文章到微博
分享文章到朋友圈

相关文章


评论(0)


0/1000
评论

登录后可评论,请 登录注册

评论
温馨提示

您确认删除评论吗?

确定
取消
温馨提示

您确认删除评论吗?

删除操作无法恢复,请谨慎操作。

确定
取消
温馨提示

您确认删除博客吗?

确定
取消

确认删除

您确认删除博客吗?

确认删除

您确认删除评论吗?

温馨提示

登录超时或用户已下线,请重新登录!!!

确定
取消