您的位置：首页 > 理论基础 > 计算机网络

K8S学习002--Pod概念与网络通讯方式

2020-03-31 18:36 381 查看

文章目录

  • 二：网络通讯方式

    • 前言

    一：pod概念

    • Pod是kubernetes中你可以创建和部署的最小也是最简的单位。Pod代表着集群中运行的进程。
    • Pod中封装着应用的容器（数量大于等于1，docker最常用，也可使用其他的），存储、独立的网络IP，管理容器如何运行的策略选项。Pod代表着部署的一个单位：kubernetes中应用的一个实例，可能由一个或者多个容器组合在一起共享资源。

    1.1：pod的种类

    • 自主式pod
    • 控制器管理的pod

    1.2：pod网络

    • 每个Pod都会被分配一个唯一的IP地址。Pod中的所有容器共享网络空间，包括IP地址和端口。Pod内部的容器可以使用localhost互相通信。Pod中的容器与外界通信时，必须分配共享网络资源（例如使用宿主机的端口映射）。

    1.3：pod存储

    • 可以为一个Pod指定多个共享的Volume。Pod中的所有容器都可以访问共享的volume。Volume也可以用来持久化Pod中的存储资源，以防容器重启后文件丢失。

    1.4：使用pod

    • 你很少会直接在kubernetes中创建单个Pod。因为Pod的生命周期是短暂的，用后即焚的实体。当Pod被创建后（不论是由你直接创建还是被其他Controller），都会被Kubernetes调度到集群的Node上。直到Pod的进程终止、被删掉、因为缺少资源而被驱逐、或者Node故障之前这个Pod都会一直保持在那个Node上。
    • Pod不会自愈。如果Pod运行的Node故障，或者是调度器本身故障，这个Pod就会被删除。同样的，如果Pod所在Node缺少资源或者Pod处于维护状态，Pod也会被驱逐。Kubernetes使用更高级的称为Controller的抽象层，来管理Pod实例。虽然可以直接使用Pod，但是在Kubernetes中通常是使用Controller来管理Pod的。

    1.5：pod控制器类型

    • Kubernetes中内建了很多controller（控制器），这些相当于一个状态机，用来控制Pod的具体状态和行为

    • 有如下几种类型：RC（ReplicationController），RS（ReplicaSet），Deployment，HPA（HorizontalPodAutoScale）,StatefullSet，DaemonSet，Job，Cronjob

    • RC：

      ReplicationController用来确保容器应用的副本数始终保持在用户定义的副本数，即如果有容器异常退出，会自动创建新的Pod来替代；而如果异常多出来的容器也会自动回收。
    • 在新版本的 Kubernetes中建议使用 ReplicaSet来取代 ReplicationControlle

  • RS：

      ReplicaSet跟 ReplicationController没有本质的不同，只是名字不一样，但是ReplicaSet支持集合式的selector

  • Deployment：

      虽然 ReplicaSet可以独立使用，但一般还是建议使用 Deployment来自动管理ReplicaSet，这样就无需担心跟其他机制的不兼容问题（比如 ReplicaSet不支持rolling-update（回滚更新）但 Deployment支持）
    • Deployment为Pod和 ReplicaSet提供了一个声明式定义（ declarative）方法，用来替代以前的ReplicationController来方便的管理应用。典型的应用场景包括
    • 定义 Deployment来创建Pod和 ReplicaSet
    • 滚动升级和回滚应用
    • 扩容和缩容
    • 暂停和继续 Deployment

  • HPA

      Horizontal Pod Autoscaling仅适用于 Deployment和 ReplicaSet，在V1版本中仅支持根据Pod的CPU利用率扩所容，在 V1alpha版本中，支持根据内存和用户自定义的 metric扩缩容

  • StatefullSet

      StatefulSet是为了解决有状态服务的问题（对应 Deployments和 ReplicaSets是为无状态服务而设计），其应用场景包括
    • 稳定的持久化存储，即Pod重新调度后还是能访问到相同的持久化数据，基于PVC来实现
    • 稳定的网络标志，即Pod重新调度后其 PodName和 HostName不变，基于 Headless Service（即没有 Cluster IP的 Service）来实现
    • 有序部署，有序扩展，即Pod是有顺序的，在部署或者扩展的时候要依据定义的顺序依次依次进行（即从0到N1，在下一个Pod运行之前所有之前的Pod必须都是 Running和 Ready状态），基于 init containers来实现
    • 有序收缩，有序删除（即从N-1到0）

  • DaemonSet

      DaemonSet确保全部（或者一些）Node上运行一个Pod的副本。当有Node加入集群时，也会为他们新增一个Pod。当有Node从集群移除时，这些Pod也会被回收。删除 DaemonSet将会删除它创建的所有Pod
    • 使用 DaemonSet的一些典型用法： 运行集群存储 daemon，例如在每个Node上运行 glusterd、ceph
    • 在每个Node上运行日志收集 daemon，例如 fluentd、 logstash
    • 在每个Node上运行监控 daemon，例如 Prometheus Node Exporter

  • Job,Cronjob

      Job负责批处理任务，即仅执行一次的任务，它保证批处理任务的一个或多个Pod成功结束
    • CronJob管理基于时间的Job，即： 在给定时间点只运行一次
    • 周期性地在给定时间点运行

    1.6：服务发现

    • Kubernetes中为了实现服务实例间的负载均衡和不同服务间的服务发现，创造了Serivce对象，同时又为从集群外部访问集群创建了Ingress对象。
    • Kubernetes 
      Service
      定义了这样一种抽象：一个 
      Pod
      的逻辑分组，一种可以访问它们的策略 —— 通常称为微服务。（通过一些标签与pod建立联系，且service有自己的IP地址和端口）
    • client客户端通过访问service的IP地址和端口和RR（轮询算法）来访问到下面的pod。

    二：网络通讯方式

    • Kubernetes的网络模型假定了所有Pod都在一个可以直接连通的扁平的网络空间中，这在GCE（ Google Compute Engine）里面是现成的网络模型， Kubernetes假定这个网络已经存在。
    • 而在私有云里搭建 Kubernetes集群，就不能假定这个网络已经存在了。我们需要自己实现这个网络假设，将不同节点上的 Docker容器之间的互相访问先打通，然后运行 Kubernetes

    2.1：网络通讯模式

    • 同一个Pod内的多个容器之间：lo（通过localhost回环地址）
    • 各Pod之间的通讯：overlay Network （覆盖网络）
    • Pod与 Service之间的通讯：各节点的 Iptables规则

    2.2：K8S中网络层次说明

    2.3：网络解决方案，通过Flannel访问

    • Flannel是CoreOS团队针对 Kubernetes设计的一个网络规划服务，简单来说，它的功能是让集群中的不同节点主机创建的 Docker容器都具有全集群唯一的虚拟IP地址。而且它还能在这些IP地址之间建立一个覆盖网络（overlay Network），通过这个覆盖网络，将数据包原封不动地传递到目标容器内
    • ETCD在这里的作用：为Flannel提供说明 存储管理 Flannel可分配的IP地址段资源
    • 监控ETCD中每个Pod的实际地址，并在内存中建立维护Pod节点路由表

    2.4：网络通讯方式总结

    • 同一个Pod内部通讯 同一个Pod共享同一个网络命名空间，共享同一个 Linux协议栈
  • pod1和pod2通讯–在同一台机器：
      Pod1与Pod2不在同一台主机，Pod的地址是与 docker0在同一个网段的，但doke0网段与宿主机网卡是两个完全不同的IP网段，并且不同Node之间的通信只能通过宿主机的物理网卡进行。将Pod的IP和所在Node的IP关联起来，通过这个关联让Pod可以互相访问
  • pod1和pod2通讯–不在同一台机器：
      Pod1与Pod2在同一台机器，由 Docker0网桥直接转发请求至Pod2，不需要经过 Flanne1
  • Pod至 Service的网络
      目前基于性能考虑，全部为 iptables（现在版本都是通过LVS）维护和转发
  • Pod到外网
      Pod向外网发送请求，查找路由表，转发数据包到宿主机的网卡，宿主网卡完成路由选择后， iptables执行 Masquerade，把源IP更改为宿主网卡的IP，然后向外网服务器发送请求
  • 外网访问Pod
      外网访问Pod通过Service
    • 点赞
    • 收藏
    • 分享
    • 文章举报
    深海有座未亡的城！ 发布了155 篇原创文章 · 获赞 82 · 访问量 3万+ 私信 关注
    • 内容来自用户分享和网络整理，不保证内容的准确性，如有侵权内容，可联系管理员处理 点击这里给我发消息
    标签： 
    相关文章推荐
    新的分享
    章节导航