Kubernetes创建Service访问Pod

1.创建Service

         Kubernetes Service从逻辑上代表了一组Pod,具体是哪些Pod则是由label来挑选的。Service有自己的IP,而且这个IP是不变的。客户端只需要访问Service的IP,Kubernetes则负责建立和维护Service与Pod的映射关系。无论后端Pod如何变化,对客户端不会有任何影响,因为Service没有变。

        首先创建Pod,vi httpd.yml文件如下:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: httpd
spec:
  replicas: 2
  selector:
    matchLabels:
      app: httpd
  template:
    metadata:
      labels:
        app: httpd
    spec:
      containers:
      - name: httpd
        image: httpd
        ports:
        - containerPort: 80

        我们启动了两个Pod,运行httpd镜像,label是app: httpd,Service将会用这个label来挑选Pod,kubectl get pod -o wid如下图所示:

         Pod分配了各自的IP,这些IP只能被Kubernetes Cluster中的容器和节点访问

 接下来创建Service,vi httpd-svc.yml配置如下图所示:

apiVersion: v1
kind: Service
metadata:
  name: httpd-svc
spec:
  selector:
    app: httpd
  ports:
  - protocol: TCP
    port: 8080
    targetPort: 80
  • v1是Service的apiVersion。
  • 指明当前资源的类型为Service。
  • Service的名字为httpd-svc。
  • selector指明挑选那些label为app: httpd的Pod作为Service的后端。
  • 将Service的8080端口映射到Pod的80端口,使用TCP协议。

执行kubectl apply -f httpd-svc.yml创建Service

httpd-svc分配到一个CLUSTER-IP 10.97.198.28。可以通过该IP访问后端的httpd Pod,如下图所示

通过kubectl describe可以查看httpd-svc与Pod的对应关系 

2.Cluster IP底层实现

        Cluster IP是一个虚拟IP,是由Kubernetes节点上的iptables规则管理的。

        可以通过iptables-save命令打印出当前节点的iptables规则,因为输出较多,这里只截取与httpd-svc Cluster IP 10.99.229.179相关的信息,如图所示

这两条规则含义如下:

  • 如果Cluster内的Pod(源地址来自10.244.0.0/16)要访问httpd-svc,则允许。
  • 其他源地址访问httpd-svc,跳转到规则KUBE-SVC-IYRDZZKXS5EOQ6Q6。KUBE-SVC-IYRDZZKXS5EOQ6Q6。

规则如图所示:

  • 1/2的概率跳转到KUBE-SEP-5NAIINGHGNF6YGV7规则
  • 剩下的概率跳转到KUBE-SEP-6UQ5JXNOGEE55I3K规则

 跳转规则如下:

即将请求分别转发到后端的两个Pod。通过上面的分析,我们得到结论:iptables将访问Service的流量转发到后端Pod,而且使用类似轮询的负载均衡策略。 

3.外网如何访问Service

        除了Cluster内部可以访问Service,很多情况下我们也希望应用的Service能够暴露给Cluster外部。Kubernetes提供了多种类型的Service,默认是ClusterIP。

  • ClusterIP:Service通过Cluster内部的IP对外提供服务,只有Cluster内的节点和Pod可访问,这是默认的Service类型,前面实验中的Service都是 ClusterIP。
  • NodePort:Service通过Cluster节点的静态端口对外提供服务。Cluster外部可以通过<NodeIP>:<NodePort>访问Service。
  • LoadBalancer:Service利用cloud provider特有的load balancer对外提供服务,cloud provider负责将load balancer的流量导向Service。目前支持的cloud provider有GCP、AWS、Azur等。

下面我们来实践NodePort,Service httpd-svc的配置文件修改如下

apiVersion: v1
kind: Service
metadata:
  name: httpd-svc
spec:
  type: NodePort
  selector:
    app: httpd
  ports:
  - protocol: TCP
    port: 8080
targetPort: 80

重新创建的httpd-svc,如下图所示:

Kubernetes依然会为httpd-svc分配一个ClusterIP,不同的是:

  • EXTERNAL-IP为nodes,表示可通过Cluster每个节点自身的IP访问Service。
  • PORT(S)为8080:31276。8080是ClusterIP监听的端口,31276则是节点上监听的端口。Kubernetes会从30000~32767中分配一个可用的端口,每个节点都会监听此端口并将请求转发给Service。

下面测试NodePod是否正常工作:

 

 与ClusterIP一样,NodePort也是借助了iptables。与ClusterIP相比,每个节点的iptables中都增加了下面两条规则:

访问31276会应用规则KUBE-SVC-IYRDZZKXS5EOQ6Q6

NodePort默认的是随机选择,不过我们可以用nodePort指定某个 特定端口。

  • nodePort是节点上监听的端口。
  • port是ClusterIP上监听的端口。
  • targetPort是Pod监听的端口。

 

  • 0
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 1
    评论
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值