精华内容
下载资源
问答
  • 我们在前面学习了Kubernetes、Docker的理论,本节将通过一个完整的实验,从部署一个Pod开始,一步一步地部署那些Kubernetes的组件,来剖析Kubernetes在网络层是如何实现及工作的 这里使用虚拟机来完成实验。如果要...

    我们在前面学习了Kubernetes、Docker的理论,本节将通过一个完整的实验,从部署一个Pod开始,一步一步地部署那些Kubernetes的组件,来剖析Kubernetes在网络层是如何实现及工作的

       这里使用虚拟机来完成实验。如果要部署在物理机器上或者云服务商的环境中,则涉及的网络模型很可能稍微有所不同。不过,从网络角度来看,Kubernetes的机制是类似且一致的。

         好了,来看看我们的实验环境:

    clipboard

     

    如上图所示,Kubernetes的网络模型要求每个Node上的容器都可以相互访问。默认的Docker网络模型提供了一个IP地址段是172.17.0.0/16的docker0网桥。每个容器都会在这个子网内获得IP地址,并且将docker0网桥的IP地址(172.17.42.1)作为其默认网关。需要注意的是,Docker宿主机外面的网络不需要知道任何关于这个172.17.0.0/16的信息或者知道如何连接到其内部,因为Docker的宿主机针对容器发出的数据,在物理网卡地址后面都做了IP伪装MASQUERADE(隐含NAT)。也就是说,在网络上看到的任何容器数据流都来源于那台Docker节点的物理IP地址。这里所说的网络都指连接这些主机的物理网络。
     

        这个模型便于使用,但是并不完美,需要依赖端口映射的机制。

        在Kubernetes的网络模型中,每台主机上的docker0网桥都是可以被路由到的。也就是说,在部署了一个Pod时,在同一个集群内,各主机都可以访问其他主机上的Pod IP,并不需要在主机上做端口映射。综上所述,我们可以在网络层将Kubernetes的节点看作一个路由器。如果将实验环境改画成一个网络图,那么它看起来如下图所示:

    为了支持Kubernetes网络模型,我们采取了直接路由的方式来实现,在每个Node上都配置相应的静态路由项,例如在node1这个Node上配置了两个路由项:

    route add -net 10.1.20.0 netmask 255.255.255.0 gw 20.0.40.5
    route add -net 10.1.30.0 netmask 255.255.255.0 gw 20.0.40.56

    node2:

    route add -net 10.1.10.0 netmask 255.255.255.0 gw 20.0.40.54
    route add -net 10.1.30.0 netmask 255.255.255.0 gw 20.0.40.56

    node3:

    route add -net 10.1.10.0 netmask 255.255.255.0 gw 20.0.40.54
    route add -net 10.1.20.0 netmask 255.255.255.0 gw 20.0.40.55

        这意味着,每一个新部署的容器都将使用这个Node(docker0的网桥IP)作为它的默认网关。而这些Node(类似路由器)都有其他docker0的路由信息,这样它们就能够相互连通了。
    接下来通过一些实际的案例,来看看Kubernetes在不同的场景下其网络部分到底做了什么。

    第1步:部署一个RC/Pod

     部署的RC/Pod描述文件如下(frontend-controller.yaml):

    apiVersion: v1
    kind: ReplicationController
    metadata:
      name: frontend
      labels:
        name: frontend
    spec:
      replicas: 1
      selector:
        name: frontend
      template:
        metadata:
          labels:
            name: frontend
        spec:
          containers:
          - name: tomcat
            image: tomcat
            env:
            - name: GET_HOSTS_FROM
              value: env
            ports:
            - containerPort: 18080
              hostPort: 18080

    为了便于观察,我们假定在一个空的Kubernetes集群上运行,提前清理了所有Replication Controller、Pod和其他Service.(可以不清除掉哈)

    检查一下此时某个Node上的网络接口有哪些。

    Node1的状态是:

    [root@k8s-node1 ~]# ifconfig 
    datapath: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1376
            inet6 fe80::3012:c2ff:fe6c:37e4  prefixlen 64  scopeid 0x20<link>
            ether 32:12:c2:6c:37:e4  txqueuelen 1000  (Ethernet)
            RX packets 5148  bytes 145336 (141.9 KiB)
            RX errors 0  dropped 0  overruns 0  frame 0
            TX packets 8  bytes 648 (648.0 B)
            TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
     
    docker0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
            inet 172.17.0.1  netmask 255.255.0.0  broadcast 172.17.255.255
            ether 02:42:fa:49:9c:b9  txqueuelen 0  (Ethernet)
            RX packets 0  bytes 0 (0.0 B)
            RX errors 0  dropped 0  overruns 0  frame 0
            TX packets 0  bytes 0 (0.0 B)
            TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
     
    ens192: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
            inet 20.0.40.54  netmask 255.255.255.0  broadcast 20.0.40.255
            inet6 fe80::d2a8:dff9:79af:81ad  prefixlen 64  scopeid 0x20<link>
            ether 00:50:56:94:06:d7  txqueuelen 1000  (Ethernet)
            RX packets 27940383  bytes 9781889476 (9.1 GiB)
            RX errors 0  dropped 159  overruns 0  frame 0
            TX packets 17282068  bytes 5207858422 (4.8 GiB)
            TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
     
    lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
            inet 127.0.0.1  netmask 255.0.0.0
            inet6 ::1  prefixlen 128  scopeid 0x10<host>
            loop  txqueuelen 1  (Local Loopback)
            RX packets 1774557  bytes 228015453 (217.4 MiB)
            RX errors 0  dropped 0  overruns 0  frame 0
            TX packets 1774557  bytes 228015453 (217.4 MiB)
            TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
     
    vethwe-bridge: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1376
            inet6 fe80::6468:58ff:fe34:ace9  prefixlen 64  scopeid 0x20<link>
            ether 66:68:58:34:ac:e9  txqueuelen 0  (Ethernet)
            RX packets 5218  bytes 231248 (225.8 KiB)
            RX errors 0  dropped 0  overruns 0  frame 0
            TX packets 164  bytes 45548 (44.4 KiB)
            TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
     
    vethwe-datapath: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1376
            inet6 fe80::200f:f1ff:fe14:9a20  prefixlen 64  scopeid 0x20<link>
            ether 22:0f:f1:14:9a:20  txqueuelen 0  (Ethernet)
            RX packets 1774557  bytes 228015453 (217.4 MiB)
            RX errors 0  dropped 0  overruns 0  frame 0
            TX packets 1774557  bytes 228015453 (217.4 MiB)
            TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
     
    vethwepl3ff9d10: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1376
            inet6 fe80::983e:53ff:fe53:f9ea  prefixlen 64  scopeid 0x20<link>
            ether 9a:3e:53:53:f9:ea  txqueuelen 0  (Ethernet)
            RX packets 75549  bytes 10251363 (9.7 MiB)
            RX errors 0  dropped 0  overruns 0  frame 0
            TX packets 61748  bytes 14056132 (13.4 MiB)
            TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
     
    vethweplac9b1dd: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1376
            inet6 fe80::4402:85ff:fe12:4b06  prefixlen 64  scopeid 0x20<link>
            ether 46:02:85:12:4b:06  txqueuelen 0  (Ethernet)
            RX packets 75549  bytes 10251363 (9.7 MiB)
            RX errors 0  dropped 0  overruns 0  frame 0
            TX packets 61748  bytes 14056132 (13.4 MiB)
            TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
     
    vxlan-6784: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 65470
            inet6 fe80::8c83:3eff:febe:3cc8  prefixlen 64  scopeid 0x20<link>
            ether 8e:83:3e:be:3c:c8  txqueuelen 1000  (Ethernet)
            RX packets 885161  bytes 1210978136 (1.1 GiB)
            RX errors 0  dropped 0  overruns 0  frame 0
            TX packets 880280  bytes 1210873748 (1.1 GiB)
            TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
     
    weave: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1376
            inet 10.43.128.0  netmask 255.240.0.0  broadcast 10.47.255.255
            inet6 fe80::fccd:a6ff:fed5:d30b  prefixlen 64  scopeid 0x20<link>
            ether fe:cd:a6:d5:d3:0b  txqueuelen 1000  (Ethernet)
            RX packets 75549  bytes 10251363 (9.7 MiB)
            RX errors 0  dropped 0  overruns 0  frame 0
            TX packets 61748  bytes 14056132 (13.4 MiB)
            TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

    可以看出,有一个docker0网桥和一个本地地址的网络端口。现在部署一下我们在前面准备的RC/Pod配置文件,看看发生了什么:

    kubectl create -f frontend-controller.yaml

    可以看到一些有趣的事情。Kubernetes为这个Pod找了一个主机Node3来运行它。另外,这个Pod获得了一个在Node3的docker0网桥上的IP地址。我们登录Node3查看正在运行的容器:

        在Node3上现在运行了两个容器,在我们的RC/Pod定义文件中仅仅包含了一个,那么这第2个是从哪里来的呢?第2个看起来运行的是一个叫作/pause:3.1的镜像,而且这个容器已经有端口映射到它上面了,为什么是这样呢?让我们深入容器内部看一下具体原因。使用Docker的inspect命令来查看容器的详细信息,特别要关注容器的网络模型:

         有趣的结果是,在查看完每个容器的网络模型后,我们可以看到这样的配置:我们检查的第1个容器是运行了“pause:3.1”镜像的容器,它使用了Docker默认的网络模型 bridge;而我们检查的第2个容器,也就是在RC/Pod中定义运行的tomcat容器,使用了非默认的网络配置和映射容器的模型,指定了映射目标容器为“pause:3.1”。

        一起来仔细思考这个过程,为什么Kubernetes要这么做呢?

          首先,一个Pod内的所有容器都需要共用同一个IP地址,这就意味着一定要使用网络的容器映射模式。然而,为什么不能只启动第1个Pod中的容器,而将第2个Pod中的容器关联到第1个容器呢?我们认为Kubernetes是从两方面来考虑这个问题的:首先,如果在Pod内有多个容器的话,则可能很难连接这些容器;其次,后面的容器还要依赖第1个被关联的容器,如果第2个容器关联到第1个容器,且第1个容器死掉的话,第2个容器也将死掉。启动一个基础容器,然后将Pod内的所有容器都连接到它上面会更容易一些。因为我们只需要为基础的这个Google_containers/pause容器执行端口映射规则,这也简化了端口映射的过程

    所以我们启动Pod后的网络模型类似下图:

      

    在这种情况下,实际Pod的IP数据流的网络目标都是这个google_containers/pause容器。上图有点儿取巧地显示了是google_containers/pause容器将端口18080的流量转发给了相关的容器.而pause容器只是看起来转发了网络流量,但它并没有真的这么做。实际上,应用容器直接监听了这些端口,和google_containers/pause容器共享了同一个网络堆栈。这就是为什么在Pod内部实际容器的端口映射都显示到pause容器上了。我们可以使用docker port命令来检验一下。

     

    综上所述,google_containers/pause容器实际上只是负责接管这个Pod的Endpoint,并没有做更多的事情。那么Node呢?它需要将数据流传给pause容器吗?

    iptables-save

    如果您是一个空的kubernetes来做这个实验:你会发现上的这些规则,并没有被应用到我们刚刚定义的Pod上。当然,Kubernetes会给每一个Kubernetes节点都提供一些默认的服务,上面的规则就是Kubernetes的默认服务所需要的。关键是,我们没有看到任何IP伪装的规则,并且没有任何指向Pod 10.36.0.1内部的端口映射

    第二步:发布一个服务

       我们已经了解了Kubernetes如何处理最基本的元素即Pod的连接问题,接下来看一下它是如何处理Service的。Service允许我们在多个Pod之间抽象一些服务,而且服务可以通过提供在同一个Service的多个Pod之间的负载均衡机制来支持水平扩展。我再次将环境初始化,删除刚创建的rc或pod来确保集群是空的:

    kubectl stop rc frontend

       然后准备一个名为frontend的Service配置文件:

    apiVersion: v1
    kind: Service
    metadata:
      name: frontend
      labels:
        name: frontend
    spec:
      ports:
      - port: 80
    #    nodePort: 38080
      selector:
        name: frontend
    #  type:
     #   NodePort

    接着在Kubernetes集群中定义这个服务:

    kubecatl applf -f frontend-service.yaml
    kubecatl get svc

        在服务正确创建后,可以看到Kubernetes集群已经为这个服务分配了一个虚拟IP地址10.110.75.165,这个IP地址是在Kubernetes的Portal Network中分配的。而这个Portal Network的地址范围是我们在Kubmaster上启动API服务进程时,使用--service-cluster-ip-range=xx命令行参数指定的:

    cat /etc/kubernetes/apiserver

         这个IP段可以是任何段,只要不和docker0或者物理网络的子网冲突就可以。选择任意其他网段的原因是这个网段将不会在物理网络和docker0网络上进行路由。这个PortalNetwork对每一个Node都有局部的特殊性,实际上它存在的意义是让容器的流量都指向默认网关(也就是docker0网桥)。

        在继续实验前,先登录到Node1上看一下在我们定义服务后发生了什么变化。首先检查一下iptables或Netfilter的规则:

    (ps:书上的图片,由于我没有清空kubernetes,没有做成桥接,就拿书上的图片来解决了)

    第1行是挂在PREROUTING链上的端口重定向规则,所有进入的流量如果满足20.1.244.75: 80,则都会被重定向到端口33761。第2行是挂在OUTPUT链上的目标地址NAT,做了和上述第1行规则类似的工作,但针对的是当前主机生成的外出流量。所有主机生成的流量都需要使用这个DNAT规则来处理。简而言之,这两个规则使用了不同的方式做了类似的事情,就是将所有从节点生成的发送给20.1.244.75:80的流量重定向到本地的59528端口。

    至此,目标为Service IP地址和端口的任何流量都将被重定向到本地的59528端口。

    这个端口连到哪里去了呢?

        这就到了kube-proxy发挥作用的地方了。这个kube-proxy服务给每一个新创建的服务都关联了一个随机的端口号,并且监听那个特定的端口,为服务创建相关的负载均衡对象。在我们的实验中,随机生成的端口刚好是33761。通过监控Node1上的Kubernetes-Service的日志,在创建服务时可以看到下面的记录:

         现在我们知道,所有流量都被导入kube-proxy中了。我们现在需要它完成一些负载均衡的工作,创建Replication Controller并观察结果,下面是Replication Controller的配置文件

    apiVersion: v1
    kind: ReplicationController
    metadata:
      name: frontend
      labels:
         name: frontend
    spec:
      replicas: 3
      selector:
        name: frontend
      template:
        metadata:
          labels:
            name: frontend
        spec:
          containers:
          - name: nginx
            image: nginx
            imagePullPolicy: IfNotPresent
            env:
            - name: GET_HOST_FROM
              value: env
            ports:    
            - containerPort: 80
              hostPort: 38080

       在集群发布上述配置文件后,等待并观察,确保所有Pod都运行起来了:

    kubectl create -f frontend-controller.yaml

     现在所有的Pod都运行起来了,Service将会把客户端请求负载分发到包含“name=frontend”标签的所有Pod上。

         Kubernetes的kube-proxy看起来只是一个夹层,但实际上它只是在Node上运行的一个服务。上述重定向规则的结果就是针对目标地址为服务IP的流量,将Kubernetes的kube-proxy变成了一个中间的夹层。

        为了查看具体的重定向动作,我们会使用tcpdump来进行网络抓包操作。

        首先,安装tcpdump:

    yum install -y tcpdump

       安装完成后,登录Node1,运行tcpdump命令:

    tcpdump -nn -q -i ens192   port 80

     需要捕获物理服务器以太网接口的数据包,Node1机器上的以太网接口名字叫作ens192。

         再打开第1个窗口运行第2个tcpdump程序,不过我们需要一些额外的信息去运行它,即挂接在docker0桥上的虚拟网卡Veth的名称。我们看到只有一个frontend容器在Node1主机上运行,所以可以使用简单的“ip addr”命令来查看最后一个的Veth网络接口:

    复制这个接口的名字。在第二个窗口运行tcpdump 

    好了,我们已经在同时捕获两个接口的网络包了。这时再启动第3个窗口,运行一个“docker exec "命令来连接到我们的frontend容器内部(你可以先执行docker ps来获得这个容器的ID):

    docker exec -it xxxxxx bash

     一旦进入容器内部,我们就可以通过Pod的IP地址来访问了,使用curl 来尝试访问

    curl 20.1.244.75

    我们在抓包的两个窗口内看到: 

    这些信息说明了什么问题呢?让我们用下图,用实线标出第一个窗口中网络抓包信息的含义(物理网卡上的流量),并用虚线标出第二个窗口的抓包信息含义(docker0上的网络流量)

    可以看到,虚线绕过了node03 的kube-proxy,这么做是因为Node03上的   kube-proxy并没有参与此次的网络交互, 

    总而言之,Kubernetes的kube-proxy作为一个全功能的代理服务器管理了两个独立的TCP连接:一个是从容器到kube-proxy:另一个是从kube-proxy到负载均衡的目标Pod。

    展开全文
  • Service和pod关系?

    2019-10-08 14:43:00
    1、为什么使用Service? 1)防止Pod失联。...4)Service的底层实现主要使用iptablesIPVS这两种网络模式。 2、Service文件配置定义 apiVersion: v1 kind: Service metadata: labels: app: n...

    1、为什么使用Service?
    1)防止Pod失联。
    2)定义一组Pod的访问策略。
    3)支持clusterIP,Nodeport以及LoadBalance三种类型。
    4)Service的底层实现主要使用iptables和IPVS这两种网络模式。

    2、Service文件配置定义
    apiVersion: v1
    kind: Service
    metadata:
      labels:
        app: nginx
      name: nginx-service
    spec:
      type: NodePort    #外部访问
      clusterIP: 10.108.77.3   #内部访问
      ports:
      - nodePort: 32518     #固定nodeport的端口号
        port: 80
        protocol: TCP         #后端的协议
        targetPort: 80         #到后端的端口
      selector:                   #寻找后端的pod
        app: nginx  

    3、查看现有的Service信息
    [root@master01 demo3]# kubectl get svc
    NAME                  TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)        AGE
    kubernetes            ClusterIP   10.96.0.1        <none>        443/TCP        53d
    nginx-harbor-server   NodePort    10.106.214.106   <none>        80:31806/TCP   29h
    nginx-service         NodePort    10.108.77.3      <none>        80:32518/TCP   31h

    [root@master01 demo3]# kubectl get ep      #查看Service后端服务器信息
    NAME                  ENDPOINTS                                                             AGE
    kubernetes            192.168.187.141:6443                                             53d
    nginx-harbor-server   10.244.1.38:80,10.244.1.40:80,10.244.2.32:80   29h
    nginx-service         10.244.1.37:80,10.244.2.33:80,10.244.2.34:80       31h

    [root@master01 demo3]# kubectl get pod -l app=nginx -o wide   #根据标签查主机ID、IP地址等信息
    NAME                               READY   STATUS    RESTARTS   AGE   IP            NODE     NOMINATED NODE   READINESS GATES
    nginx-deployment-9b644dcd5-dbdbr   1/1     Running   2          31h   10.244.2.34   node02   <none>           <none>
    nginx-deployment-9b644dcd5-kxrgf   1/1     Running   3          31h   10.244.1.37   node01   <none>           <none>
    nginx-deployment-9b644dcd5-rcp88   1/1     Running   3          31h   10.244.2.33   node02   <none>           <none>

    [root@master01 demo3]# kubectl describe svc nginx-service   #详细查看service的信息
    Name:                     nginx-service
    Namespace:                default
    Labels:                   app=nginx
    Annotations:              <none>
    Selector:                 app=nginx
    Type:                     NodePort
    IP:                       10.108.77.3
    Port:                     <unset>  80/TCP
    TargetPort:               80/TCP
    NodePort:                 <unset>  32518/TCP
    Endpoints:                10.244.1.37:80,10.244.2.33:80,10.244.2.34:80
    Session Affinity:         None
    External Traffic Policy:  Cluster
    Events:                   <none>


    4、Pod与Service的关系?
    1)Server通过label-selector与Pod相互连。
    2)通过server实现Pod的负载均衡(TCP、UDP 4层)

    Service对外提供服务类型:
    1)ClusterIP:默认值,分配一个集群内部可以访问的虚拟IP(内部VIP),用于集群内部之间调用,默认的类型。
    2)NodePort:在每个Node上启用一个端口来暴露服务,供集群外部访问。
    用户--》域名--》Node IP:port--》podIP
    3)LoadBalancer:在每个Node上启用一个端口来暴露服务,除此外,还会请求底层云平台上的负载均衡,将每个node作为后端的服务器添加进去。
    用户--》域名--》SLB---》Node IP:port--》podIP


    5、Service代理模式:
    1)iptables:默认
    [root@node01 ~]# ps -ef|grep kube-proxy      #网络代理
    root      2268  2251  0 14:07 ?        00:00:08 /usr/local/bin/kube-proxy --config=/var/lib/kube-proxy/config.conf --hostname-override=node01
    root     46693 21733  0 19:20 pts/0    00:00:00 grep --color=auto kube-proxy

    [root@node01 kubernetes]# iptables-save|grep KUBE-SVC-GKN7Y2BSGW4NJTYL
    :KUBE-SVC-GKN7Y2BSGW4NJTYL - [0:0]
    -A KUBE-NODEPORTS -p tcp -m comment --comment "default/nginx-service:" -m tcp --dport 32518 -j KUBE-SVC-GKN7Y2BSGW4NJTYL
    -A KUBE-SERVICES -d 10.108.77.3/32 -p tcp -m comment --comment "default/nginx-service: cluster IP" -m tcp --dport 80 -j KUBE-SVC-GKN7Y2BSGW4NJTYL
    -A KUBE-SVC-GKN7Y2BSGW4NJTYL -m statistic --mode random --probability 0.33332999982 -j KUBE-SEP-2DGLPGXWBWWNXDYH
    -A KUBE-SVC-GKN7Y2BSGW4NJTYL -m statistic --mode random --probability 0.50000000000 -j KUBE-SEP-4KRMMUFVU5N5AUS2
    -A KUBE-SVC-GKN7Y2BSGW4NJTYL -j KUBE-SEP-3ULGC5KCIWJAGE3V

    [root@node01 kubernetes]# iptables-save|grep KUBE-SEP-2DGLPGXWBWWNXDYH
    :KUBE-SEP-2DGLPGXWBWWNXDYH - [0:0]
    -A KUBE-SEP-2DGLPGXWBWWNXDYH -s 10.244.1.37/32 -j KUBE-MARK-MASQ
    -A KUBE-SEP-2DGLPGXWBWWNXDYH -p tcp -m tcp -j DNAT --to-destination 10.244.1.37:80
    -A KUBE-SVC-GKN7Y2BSGW4NJTYL -m statistic --mode random --probability 0.33332999982 -j KUBE-SEP-2DGLPGXWBWWNXDYH

    iptables与ipvs的比较?
    1)创建的很多的iptables规则。(更新,非增量式更新)
    2)iptables规则是从上之下的逐条匹配。(匹配延迟大)
    3) ipvs工作在系统内核,iptables是在用户系统层面。
    4)ipvs调度算法丰富,rr,wrr,lc,wlc,ip hash


    6、LVS就是基于ipvs内核调度模块实现的负载均衡。
    [root@node01 kubernetes]# ipvsadm -ln
    IP Virtual Server version 1.2.1 (size=4096)
    Prot LocalAddress:Port Scheduler Flags
      -> RemoteAddress:Port           Forward Weight ActiveConn InActConn


    #修改ConfigMap的kube-system/kube-proxy中的config.conf,把 mode: "" 改为mode: “ipvs" 保存退出即可
    [root@k8smaster centos]# kubectl edit cm kube-proxy -n kube-system
    configmap/kube-proxy edited
    ###删除之前的proxy pod
    [root@k8smaster centos]# kubectl get pod -n kube-system |grep kube-proxy |awk '{system("kubectl delete pod "$1" -n kube-system")}'
    pod "kube-proxy-2m5jh" deleted
    pod "kube-proxy-nfzfl" deleted
    pod "kube-proxy-shxdt" deleted
    #查看proxy运行状态
    [root@k8smaster centos]# kubectl get pod -n kube-system | grep kube-proxy
    kube-proxy-54qnw                              1/1     Running   0          24s
    kube-proxy-bzssq                              1/1     Running   0          14s
    kube-proxy-cvlcm                              1/1     Running   0          37s
    #查看日志,如果有 `Using ipvs Proxier.` 说明kube-proxy的ipvs 开启成功!
    [root@k8smaster centos]# kubectl logs kube-proxy-54qnw -n kube-system
    I0518 20:24:09.319160       1 server_others.go:176] Using ipvs Proxier.
    W0518 20:24:09.319751       1 proxier.go:386] IPVS scheduler not specified, use rr by default
    I0518 20:24:09.320035       1 server.go:562] Version: v1.14.2
    I0518 20:24:09.334372       1 conntrack.go:52] Setting nf_conntrack_max to 131072
    I0518 20:24:09.334853       1 config.go:102] Starting endpoints config controller
    I0518 20:24:09.334916       1 controller_utils.go:1027] Waiting for caches to sync for endpoints config controller
    I0518 20:24:09.334945       1 config.go:202] Starting service config controller
    I0518 20:24:09.334976       1 controller_utils.go:1027] Waiting for caches to sync for service config controller
    I0518 20:24:09.435153       1 controller_utils.go:1034] Caches are synced for service config controller
    I0518 20:24:09.435271       1 controller_utils.go:1034] Caches are synced for endpoints config controller

    展开全文
  • Docker给我们带来了不同的网络模式,...我们在前面学习了Kubernetes、Docker的理论,本节将通过一个完整的实验,从部署一个Pod开始,一步一步地部署那些Kubernetes的组件,来剖析Kubernetes在网络层是如何实现及工...

           Docker给我们带来了不同的网络模式,Kubernetes也以一种不同的方式来解决这些网络模式的挑战,但其方式有些难以理解,特别是对于刚开始接触Kubernetes的网络的开发者来说。我们在前面学习了Kubernetes、Docker的理论,本节将通过一个完整的实验,从部署一个Pod开始,一步一步地部署那些Kubernetes的组件,来剖析Kubernetes在网络层是如何实现及工作的。
          这里使用虚拟机来完成实验。如果要部署在物理机器上或者云服务商的环境中,则涉及的网络模型很可能稍微有所不同。不过,从网络角度来看,Kubernetes的机制是类似且一致的。

         好了,来看看我们的实验环境:

            

         Kubernetes的网络模型要求每个Node上的容器都可以相互访问。
         默认的Docker网络模型提供了一个IP地址段是172.17.0.0/16的docker0网桥。每个容器都会在这个子网内获得IP地址,并且将docker0网桥的IP地址(172.17.42.1)作为其默认网关。需要注意的是,Docker宿主机外面的网络不需要知道任何关于这个172.17.0.0/16的信息或者知道如何连接到其内部,因为Docker的宿主机针对容器发出的数据,在物理网卡地址后面都做了IP伪装MASQUERADE(隐含NAT)。也就是说,在网络上看到的任何容器数据流都来源于那台Docker节点的物理IP地址。这里所说的网络都指连接这些主机的物理网络。

          这个模型便于使用,但是并不完美,需要依赖端口映射的机制。

         在Kubernetes的网络模型中,每台主机上的docker0网桥都是可以被路由到的。也就是说,在部署了一个Pod时,在同一个集群内,各主机都可以访问其他主机上的Pod IP,并不需要在主机上做端口映射。综上所述,我们可以在网络层将Kubernetes的节点看作一个路由器。如果将实验环境改画成一个网络图,那么它看起来如下图所示:

     

    为了支持Kubernetes网络模型,我们采取了直接路由的方式来实现,在每个Node上都配置相应的静态路由项,例如在node1这个Node上配置了两个路由项:

    route add -net 10.1.20.0 netmask 255.255.255.0 gw 20.0.40.55
    route add -net 10.1.30.0 netmask 255.255.255.0 gw 20.0.40.56

    node2:

    route add -net 10.1.10.0 netmask 255.255.255.0 gw 20.0.40.54
    route add -net 10.1.30.0 netmask 255.255.255.0 gw 20.0.40.56

    node3:

    route add -net 10.1.10.0 netmask 255.255.255.0 gw 20.0.40.54
    route add -net 10.1.20.0 netmask 255.255.255.0 gw 20.0.40.55
    

        这意味着,每一个新部署的容器都将使用这个Node(docker0的网桥IP)作为它的默认网关。而这些Node(类似路由器)都有其他docker0的路由信息,这样它们就能够相互连通了。
    接下来通过一些实际的案例,来看看Kubernetes在不同的场景下其网络部分到底做了什么。

    第1步:部署一个RC/Pod

     

     部署的RC/Pod描述文件如下(frontend-controller.yaml):

    apiVersion: v1
    kind: ReplicationController
    metadata:
      name: frontend
      labels:
        name: frontend
    spec:
      replicas: 1
      selector:
        name: frontend
      template:
        metadata:
          labels:
            name: frontend
        spec:
          containers:
          - name: tomcat
            image: tomcat
            env:
            - name: GET_HOSTS_FROM
              value: env
            ports:
            - containerPort: 18080
              hostPort: 18080

       为了便于观察,我们假定在一个空的Kubernetes集群上运行,提前清理了所有Replication Controller、Pod和其他Service.(可以不清除掉蛤)

    检查一下此时某个Node上的网络接口有哪些。

    Node1的状态是:

    [root@k8s-node1 ~]# ifconfig 
    datapath: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1376
            inet6 fe80::3012:c2ff:fe6c:37e4  prefixlen 64  scopeid 0x20<link>
            ether 32:12:c2:6c:37:e4  txqueuelen 1000  (Ethernet)
            RX packets 5148  bytes 145336 (141.9 KiB)
            RX errors 0  dropped 0  overruns 0  frame 0
            TX packets 8  bytes 648 (648.0 B)
            TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
    
    docker0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
            inet 172.17.0.1  netmask 255.255.0.0  broadcast 172.17.255.255
            ether 02:42:fa:49:9c:b9  txqueuelen 0  (Ethernet)
            RX packets 0  bytes 0 (0.0 B)
            RX errors 0  dropped 0  overruns 0  frame 0
            TX packets 0  bytes 0 (0.0 B)
            TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
    
    ens192: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
            inet 20.0.40.54  netmask 255.255.255.0  broadcast 20.0.40.255
            inet6 fe80::d2a8:dff9:79af:81ad  prefixlen 64  scopeid 0x20<link>
            ether 00:50:56:94:06:d7  txqueuelen 1000  (Ethernet)
            RX packets 27940383  bytes 9781889476 (9.1 GiB)
            RX errors 0  dropped 159  overruns 0  frame 0
            TX packets 17282068  bytes 5207858422 (4.8 GiB)
            TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
    
    lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
            inet 127.0.0.1  netmask 255.0.0.0
            inet6 ::1  prefixlen 128  scopeid 0x10<host>
            loop  txqueuelen 1  (Local Loopback)
            RX packets 1774557  bytes 228015453 (217.4 MiB)
            RX errors 0  dropped 0  overruns 0  frame 0
            TX packets 1774557  bytes 228015453 (217.4 MiB)
            TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
    
    vethwe-bridge: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1376
            inet6 fe80::6468:58ff:fe34:ace9  prefixlen 64  scopeid 0x20<link>
            ether 66:68:58:34:ac:e9  txqueuelen 0  (Ethernet)
            RX packets 5218  bytes 231248 (225.8 KiB)
            RX errors 0  dropped 0  overruns 0  frame 0
            TX packets 164  bytes 45548 (44.4 KiB)
            TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
    
    vethwe-datapath: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1376
            inet6 fe80::200f:f1ff:fe14:9a20  prefixlen 64  scopeid 0x20<link>
            ether 22:0f:f1:14:9a:20  txqueuelen 0  (Ethernet)
            RX packets 1774557  bytes 228015453 (217.4 MiB)
            RX errors 0  dropped 0  overruns 0  frame 0
            TX packets 1774557  bytes 228015453 (217.4 MiB)
            TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
    
    vethwepl3ff9d10: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1376
            inet6 fe80::983e:53ff:fe53:f9ea  prefixlen 64  scopeid 0x20<link>
            ether 9a:3e:53:53:f9:ea  txqueuelen 0  (Ethernet)
            RX packets 75549  bytes 10251363 (9.7 MiB)
            RX errors 0  dropped 0  overruns 0  frame 0
            TX packets 61748  bytes 14056132 (13.4 MiB)
            TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
    
    vethweplac9b1dd: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1376
            inet6 fe80::4402:85ff:fe12:4b06  prefixlen 64  scopeid 0x20<link>
            ether 46:02:85:12:4b:06  txqueuelen 0  (Ethernet)
            RX packets 75549  bytes 10251363 (9.7 MiB)
            RX errors 0  dropped 0  overruns 0  frame 0
            TX packets 61748  bytes 14056132 (13.4 MiB)
            TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
    
    vxlan-6784: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 65470
            inet6 fe80::8c83:3eff:febe:3cc8  prefixlen 64  scopeid 0x20<link>
            ether 8e:83:3e:be:3c:c8  txqueuelen 1000  (Ethernet)
            RX packets 885161  bytes 1210978136 (1.1 GiB)
            RX errors 0  dropped 0  overruns 0  frame 0
            TX packets 880280  bytes 1210873748 (1.1 GiB)
            TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
    
    weave: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1376
            inet 10.43.128.0  netmask 255.240.0.0  broadcast 10.47.255.255
            inet6 fe80::fccd:a6ff:fed5:d30b  prefixlen 64  scopeid 0x20<link>
            ether fe:cd:a6:d5:d3:0b  txqueuelen 1000  (Ethernet)
            RX packets 75549  bytes 10251363 (9.7 MiB)
            RX errors 0  dropped 0  overruns 0  frame 0
            TX packets 61748  bytes 14056132 (13.4 MiB)
            TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
    

    可以看出,有一个docker0网桥和一个本地地址的网络端口。现在部署一下我们在前面准备的RC/Pod配置文件,看看发生了什么:

    可以看到一些有趣的事情。Kubernetes为这个Pod找了一个主机Node3来运行它。另外,这个Pod获得了一个在Node3的docker0网桥上的IP地址。我们登录Node3查看正在运行的容器:

        在Node3上现在运行了两个容器,在我们的RC/Pod定义文件中仅仅包含了一个,那么这第2个是从哪里来的呢?第2个看起来运行的是一个叫作/pause:3.1的镜像,而且这个容器已经有端口映射到它上面了,为什么是这样呢?让我们深入容器内部看一下具体原因。使用Docker的inspect命令来查看容器的详细信息,特别要关注容器的网络模型:

         有趣的结果是,在查看完每个容器的网络模型后,我们可以看到这样的配置:我们检查的第1个容器是运行了“pause:3.1”镜像的容器,它使用了Docker默认的网络模型 bridge;而我们检查的第2个容器,也就是在RC/Pod中定义运行的tomcat容器,使用了非默认的网络配置和映射容器的模型,指定了映射目标容器为“pause:3.1”。

        一起来仔细思考这个过程,为什么Kubernetes要这么做呢?

          首先,一个Pod内的所有容器都需要共用同一个IP地址,这就意味着一定要使用网络的容器映射模式。然而,为什么不能只启动第1个Pod中的容器,而将第2个Pod中的容器关联到第1个容器呢?我们认为Kubernetes是从两方面来考虑这个问题的:首先,如果在Pod内有多个容器的话,则可能很难连接这些容器;其次,后面的容器还要依赖第1个被关联的容器,如果第2个容器关联到第1个容器,且第1个容器死掉的话,第2个容器也将死掉。启动一个基础容器,然后将Pod内的所有容器都连接到它上面会更容易一些。因为我们只需要为基础的这个Google_containers/pause容器执行端口映射规则,这也简化了端口映射的过程。

    所以我们启动Pod后的网络模型类似下图:

      

    在这种情况下,实际Pod的IP数据流的网络目标都是这个google_containers/pause容器。上图有点儿取巧地显示了是google_containers/pause容器将端口18080的流量转发给了相关的容器.而pause容器只是看起来转发了网络流量,但它并没有真的这么做。实际上,应用容器直接监听了这些端口,和google_containers/pause容器共享了同一个网络堆栈。这就是为什么在Pod内部实际容器的端口映射都显示到pause容器上了。我们可以使用docker port命令来检验一下。

     

    综上所述,google_containers/pause容器实际上只是负责接管这个Pod的Endpoint,并没有做更多的事情。那么Node呢?它需要将数据流传给pause容器吗?

    iptables-save

    如果您是一个空的kubernetes来做这个实验:你会发现上的这些规则,并没有被应用到我们刚刚定义的Pod上。当然,Kubernetes会给每一个Kubernetes节点都提供一些默认的服务,上面的规则就是Kubernetes的默认服务所需要的。关键是,我们没有看到任何IP伪装的规则,并且没有任何指向Pod 10.36.0.1内部的端口映射。

    第二步:发布一个服务

       我们已经了解了Kubernetes如何处理最基本的元素即Pod的连接问题,接下来看一下它是如何处理Service的。Service允许我们在多个Pod之间抽象一些服务,而且服务可以通过提供在同一个Service的多个Pod之间的负载均衡机制来支持水平扩展。我再次将环境初始化,删除刚创建的rc或pod来确保集群是空的:

       然后准备一个名为frontend的Service配置文件:

    apiVersion: v1
    kind: Service
    metadata:
      name: frontend
      labels:
        name: frontend
    spec:
      ports:
      - port: 80
    #    nodePort: 38080
      selector:
        name: frontend
    #  type:
     #   NodePort
    

    接着在Kubernetes集群中定义这个服务:

        

    kubecatl applf -f frontend-service.yaml
    kubecatl get svc

        在服务正确创建后,可以看到Kubernetes集群已经为这个服务分配了一个虚拟IP地址10.110.75.165,这个IP地址是在Kubernetes的Portal Network中分配的。而这个Portal Network的地址范围是我们在Kubmaster上启动API服务进程时,使用--service-cluster-ip-range=xx命令行参数指定的:

         这个IP段可以是任何段,只要不和docker0或者物理网络的子网冲突就可以。选择任意其他网段的原因是这个网段将不会在物理网络和docker0网络上进行路由。这个PortalNetwork对每一个Node都有局部的特殊性,实际上它存在的意义是让容器的流量都指向默认网关(也就是docker0网桥)。

        在继续实验前,先登录到Node1上看一下在我们定义服务后发生了什么变化。首先检查一下iptables或Netfilter的规则:

    (ps:书上的图片,由于我没有清空kubernetes,没有做成桥接,就拿书上的图片来解决了)

    第1行是挂在PREROUTING链上的端口重定向规则,所有进入的流量如果满足20.1.244.75: 80,则都会被重定向到端口33761。第2行是挂在OUTPUT链上的目标地址NAT,做了和上述第1行规则类似的工作,但针对的是当前主机生成的外出流量。所有主机生成的流量都需要使用这个DNAT规则来处理。简而言之,这两个规则使用了不同的方式做了类似的事情,就是将所有从节点生成的发送给20.1.244.75:80的流量重定向到本地的33761端口。

    至此,目标为Service IP地址和端口的任何流量都将被重定向到本地的33761端口。

    这个端口连到哪里去了呢?

        这就到了kube-proxy发挥作用的地方了。这个kube-proxy服务给每一个新创建的服务都关联了一个随机的端口号,并且监听那个特定的端口,为服务创建相关的负载均衡对象。在我们的实验中,随机生成的端口刚好是33761。通过监控Node1上的Kubernetes-Service的日志,在创建服务时可以看到下面的记录:

         现在我们知道,所有流量都被导入kube-proxy中了。我们现在需要它完成一些负载均衡的工作,创建Replication Controller并观察结果,下面是Replication Controller的配置文件

    apiVersion: v1
    kind: ReplicationController
    metadata:
      name: frontend
      labels:
         name: frontend
    spec:
      replicas: 3
      selector:
        name: frontend
      template:
        metadata:
          labels:
            name: frontend
        spec:
          containers:
          - name: nginx
            image: nginx
            imagePullPolicy: IfNotPresent
            env:
            - name: GET_HOST_FROM
              value: env
            ports:    
            - containerPort: 80
              hostPort: 38080

         在集群发布上述配置文件后,等待并观察,确保所有Pod都运行起来了:

     

        现在所有的Pod都运行起来了,Service将会把客户端请求负载分发到包含“name=frontend”标签的所有Pod上。

         Kubernetes的kube-proxy看起来只是一个夹层,但实际上它只是在Node上运行的一个服务。上述重定向规则的结果就是针对目标地址为服务IP的流量,将Kubernetes的kube-proxy变成了一个中间的夹层。

        为了查看具体的重定向动作,我们会使用tcpdump来进行网络抓包操作。

        首先,安装tcpdump:

       

    yum install -y tcpdump

       安装完成后,登录Node1,运行tcpdump命令:

    tcpdump -nn -q -i   port 80

     需要捕获物理服务器以太网接口的数据包,Node1机器上的以太网接口名字叫作ens192。

     

         再打开第1个窗口运行第2个tcpdump程序,不过我们需要一些额外的信息去运行它,即挂接在docker0桥上的虚拟网卡Veth的名称。我们看到只有一个frontend容器在Node1主机上运行,所以可以使用简单的“ip addr”命令来查看最后一个的Veth网络接口:

    好了,我们已经在同时捕获两个接口的网络包了。这时再启动第3个窗口,运行一个“docker exec "命令来连接到我们的frontend容器内部(你可以先执行docker ps来获得这个容器的ID):

    这些信息说明了什么问题呢?

         总而言之,Kubernetes的kube-proxy作为一个全功能的代理服务器管理了两个独立的TCP连接:一个是从容器到kube-proxy:另一个是从kube-proxy到负载均衡的目标Pod。

     

    小结:

         本节内容到此结束,谢谢大家的浏览,多多点关注蛤。

    展开全文
  • 问题:安装配置k8s calico网络后, pods之间网络互通,但在测试pod上通过nslookup 获取指定service的域名解析时异常 解决思路: 查看calico日志 calico报错Readiness probe failed: calico/node is not ready: ...

    问题:安装配置k8s calico网络后, pods之间网络互通,但在测试pod上通过nslookup 获取指定service的域名解析时异常

    解决思路:
    查看calico日志

    calico报错Readiness probe failed: calico/node is not ready: BIRD is not ready: BGP not established
    

    安装配置calicoctl工具查看calico-node状态
    安装配置过程如下(master 节点和node节点都安装):

    wget https://github.com/projectcalico/calicoctl/releases/download/v3.10.0/calicoctl -O /usr/bin/calicoctl
    chmod +x /usr/bin/calicoctl
    #配置calicoctl.cfg(通过kubeadm安装的k8s集群,只需在master 节点配置即可)
    mkdir -p /etc/calico
    vi /etc/calico/calicoctl.cfg
    apiVersion: projectcalico.org/v3
    kind: CalicoAPIConfig
    metadata:
    spec:
      datastoreType: "kubernetes"
      kubeconfig: "/root/.kube/config"
    

    获取calico-node状态

    calicoctl node status
    

    结果显示node节点的calico-node状态为start, info显示为Passive
    在woker节点查看calico-node状态, 则获取的master节点的ip地址并非master节点的实际IP地址
    修改calico的yaml文件,添加

     # Specify interface
                - name: IP_AUTODETECTION_METHOD
                  value: "interface=ens33" #以实际网卡名称为准
    

    添加结果如下:
    在这里插入图片描述
    执行以下命令更新calico

    kubectl apply -f calico-3.9.2.yaml
    

    完成更新后查看calico-node状态确认是否变为up状态, info是否为Established状态

    确认正常后,pod到service之间的ip不能ping通,域名解析正常,wget获取页面信息正常
    在这里插入图片描述
    参考:
    https://github.com/projectcalico/calico/issues/2561

    展开全文
  • 最近一个环境出现pod尚在not ready状态时就...本文将从认识kuberneres service 到kubernetes service 使用场景再到kubernetes service底层实现原理,最后通过示例方式展示如何从servicepod网络链路一步步定位分析。
  • 分别排查pod,service,ingress是否正常 1 验证api的pod可以收到请求 kubectl get pods -n openstack -o wide --show-labels|grep scheduler-das scheduler-dashboard-api-6455678546-tspsq 1/1 Running 0 3m13s 1...
  • k8s的部署架构 kubernetes中有两类资源,分别是masternodes,masternodes上跑的服务如下图, kube-apiserver | kubelet kube-controller-manager | kube-scheduler | ...
  • servicepod关联

    2019-06-26 17:20:48
    仅仅是创建了pod,要为其创建rc(ReplicationController),他才会有固定的副本,然后为其创建service,集群内部才能访问该pod,使用 NodePort 或者 LoadBalancer 类型的 Service,外部网络也可以访问该pod;...
  • 隔离pod网络

    2019-11-06 09:57:03
    隔离pod网络 需求:限制pod可以与其他哪些pod进行通信来确保pod之间的网络安全,或者限制pod对外的访问流量 是否可以进行此种配置取决于集群中使用的容器网络插件,如果网络插件支持,可以通过NetworkPolicy资源...
  • #pod-network-cidr是pod网络 --pod-network-cidr=3.3.3.1/16 #查看pod网络信息 kubectl get pods -o wide #service-cidr是svc网络, --service-cidr=2.2.2.1/16 #暴露一个pod的端口再查看svc信息 kubectl...
  • Deployment等Controller会通过动态创建销毁Pod来保证应用整体的健壮性。众所周知,每个pod都拥有自己的IP地址,当新的Controller用新的Pod替代发生故障的Pod时,我们会发现,新的IP地址可能跟故障的Pod...
  • Kubernetes网络三部曲之一~Pod网络

    千次阅读 多人点赞 2019-09-21 11:24:52
    K8s是一个强大的平台,但它的网络比较复杂,涉及很多概念,例如Pod网络,Service网络,Cluster IPs,NodePort,LoadBalancerIngress等等,这么多概念足以让新手望而生畏。但是,只有深入理解K8s网络,才能为理解...
  • Service 可以充当服务发现机制,使我们能轻松地上游 Pod 通信,而无需知道各个 Pod 的确切 IP 地址。 在某些情况下,我们想检索并连接到特定 Service 所有 Pod 的 IP 地址。当 Pod 是有状态的(例如已部署的数据库...
  • deploy控制RS,RS控制Pod,这一整套,向外提供稳定可靠的Service。 1、Pod: Pod是一个逻辑概念,它是Kubernetes资源调度的单元,一般会把一组功能强相关的容器逻辑上称之为一个pod,Pod就是所说的实例。作为一个...
  • servicepod怎么关联的

    千次阅读 2018-03-08 17:24:34
    仅仅是创建了pod,要为其创建rc(ReplicationController),他才会有固定的副本,然后为其创建service,集群内部才能访问该pod,使用 NodePort 或者 LoadBalancer 类型的 Service,外部网络也可以访问该pod;...
  • secret类型、创建、Pod使用以及ServiceAccount关联Secret,网络隔离考题引出
  • k8s(Kubernetes)中Pod,Deployment,ReplicaSet,Service之间关系分析 Pod最小的单元 Pod封装了一个或多个应用程序的容器(比如nginx等),存储资源,唯一的网络IP以及管理容器的一些选项 Pod标示的是一个部署单元,...
  • 十分钟了解k8s servicepod转发机制

    万次阅读 2020-07-23 20:40:36
    core-dns会给service分配一个内部的虚拟ip(节点上根本查询不到这个ip,ping是不通的,具体是怎么访问到的继续往下看),因此内部服务可以通过这个ip或者是serviceName来访问到pod的服务。 service提供的常用type: ...
  • 所有命令都验证过,有更好的方式,欢迎留言~~~ CKA习题真题汇总 CKA考试经验:报考考纲 CKA :2019年12月英文原题分值 CKA考试习题:K8S基础概念--API 对象 ... CKA考试习题:网络管理-Pod网络、...
  • Pod概念、 Pod控制类型( ReplicationController&ReplicaSet&Deplovment HPA(HorizontalPodAutoScale) StatefullSet DaemonSet Job,Cronjob)、 网络通讯模式、 网络解决方案 Kubernetes + Flannel、 不同情况下...
  • 作者:Mattias te Wierik翻译:Bach(才云)校对:...Service 可以充当服务发现机制,使我们能轻松地上游 Pod 通信,而无需知道各个 Pod 的确切 IP 地址。在某些情况下,我们想检索并连接到特定 Service 所有 Po...
  • Pod 无法通过 Service IP 访问自身 同样的镜像 在自己环境可以跑起来,放到朋友rancher搭建的环境里就出现了pod的cluster ip+ port可以访问,但是通过service ip+port就无法访问的情况。 后来通过修改svc 模式 ...
  • 问题现象创建一个nginx pod,并配置了service访问,service后端指向pod。进入pod中使用service ip 或者service 域名,无法访问。一开始以为是环境配...
  • Kubernetes网络之Service网络(2)K8S服务网络实现原理Service网络概念模型DNS方案(Not Adopted)Service RegistryK8S服务发现原理服务发现之K8S方案vs Eureka+Ribbon方案 上一篇:Kubernetes网络之Pod网络(1) K8S...
  • 比如,如何提供一个服务给别人,我是应该用Pod还是用Deployment来运行我的应用等,在接下来的文章中,希望能够解答你的这些疑惑。 Kubernetes可以看做云原生时代的操作系统,统一管理下层的基础设施,如计算资源、...
  • 所谓Pod网络,就是能够保证K8s集群中的所有Pods(包括同一节点上的,也包括不同节点上的Pods),逻辑上看起来都在同一个平面网络内,能够相互做IP寻址通信的网络,下图是Pod网络的简化概念模型:
  • deploy控制RS,RS控制Pod,这一整套,向外提供稳定可靠的Service。 RS用来管理正常运行Pod数量(https://blog.csdn.net/u013288190/article/details/109500148) 二、Container 容器,是实体,有资源。 三、...
  • k8s解析--Pod、Deployment、Service

    千次阅读 2020-07-13 10:39:46
    一、概念介绍(原文地址) 1.Pod ...Pod 内的多个容器共享网络和文件系统,可以通过进程间通信和文件共享这种简单高效的方式组合完成服务 一个pod的yaml文件 apiVersion: v1 #版本号 kind: Pod #Po
  • 现有暴漏模式 在 kubernetes 的网络模型中,基于官方默认的 CNI 网络插件 Flannel,这种 Overlay Network(覆盖网络)可以轻松的实现 pod网络的互通。...1、办公室网络 k8s pod 网络不通。开发在电脑完成...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 23,176
精华内容 9,270
关键字:

pod和service网络