k8s中pod、service、ingress之间的关系
前言当应用服务需要通过域名访问时,会经过pod–>service–>ingress的部署流程,实现所需要的功能Pod直接访问Pod资源,存在的缺陷1.Pod会随时被Deployment这样的控制器删除重建,访问Pod的结果就会变得不可预知2.Pod的地址是在Pod启动后才被分配,在启动之前并不知道Pod的IP地址3.应用往往都是由多个运行相同镜像的一组Pod组成,一个个Pod的访问变得
·
前言
当应用服务需要通过域名访问时,会经过pod–>service–>ingress的部署流程,实现所需要的功能
Pod
- 直接访问Pod资源,存在的缺陷
1.Pod会随时被Deployment这样的控制器删除重建,访问Pod的结果就会变得不可预知
2.Pod的地址是在Pod启动后才被分配,在启动之前并不知道Pod的IP地址
3.应用往往都是由多个运行相同镜像的一组Pod组成,一个个Pod的访问变得不现实
Service
k8s中Service对象是用来解决上述Pod访问的问题
- 注
Service有一个固定IP地址,Service将访问该地址的流量转发给Pod,具体转发给那些Pod通过Label来选择,而且Service可以给这些Pod做负载均衡
Ingress
通常情况下,service和pod的ip仅可以在集群内部访问;集群外部的请求需要通过负载均衡转发到service在Node上暴露的NodePort上,然后再由kube-proxy通过边缘路由器(edge router)将其转发给相关的Pod或者丢弃,而Ingress就是为进入集群的请求提供路由规则的集合
ingress可以给service提供集群外部访问的url、负载均衡、ssl终止、http路由等。为了配置这些ingress规则,集群管理员需要部署一个ingress controller,它监听ingress和service的变化,根据规则配置负载均衡并提供访问入口
- 组成部分
1.nginx: 实现负载均衡到pod的集合
2.ingress controller: 从集群api获取service对应pod的ip到nginx配置文件中
3.ingress: 为nginx创建虚拟主机
结语
… …
更多推荐
已为社区贡献25条内容
所有评论(0)