技术笔记分享

Service作为Pod的代理,将访问Service的请求转发给Pod,这里我们还需要再依赖与deployments控制器,然后将Service映射到deployments控制器上,才能对Pod进行代理转发(这一功能集于kube-proxy组件实现,kube-proxy组件一直监听apiserver的资源变动,特别是service资源变动,当kube-proxy监听到有关本机的变动,则对应生成iptables或则ipvs规则进行转发)

创建Service

创建service以下演示两种方式

查看创建的Service

如下可以看到我们创建的两个service,并且都采用clusterip方式,各自分配了一个service集群IP

查看Service的详细信息

通过service的clusterip访问至代理的pod

通过域名访问Service

假如我们的Service IP发生了变化,或者Service发生了Down机,更或则Service也需要多台进行负载呢?这个时候就需要使用域名来访问到Pod,域名不会发生改变。

用域名访问Service需要添加CoreDNS将本机可以解析到Service层面,因为本机并没有使用k8s的网络插件进行配置,我们在pod中可以直接使用域名进行访问service,而在集群的宿主机中则需要添加CoreDNS来进行解析。

在Pod中直接访问Service域名进行调度

在宿主机中添加CoreDNS进行访问Service域名进行调度

删除Service和重建

删除service之后将无法通过serviceip进行访问,删除service不影响Pod的运行

Service nodeport 端口映射

通过这种方法不仅可以实现通过域名访问,还可以集群内的任何一台机器的映射端口

每创建一个service都会在对应的Node上创建对应的iptables规则

以上配置完成后,整个访问浏览应该如下图所示

undefined

发表评论

邮箱地址不会被公开。 必填项已用*标注