1 Pod概念

1.1 Pod分类

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

1.2 Pod的基本概念

一个Pod可以拉取多个镜像,跑多个容器,但是注意同一个Pod的端口不要相同,不然可能会出现无限重启的情况。

一个Pod中的多个容器,他们共用Pause,既共用网络,也共用存储卷

1.3 控制器管理的Pod

1.3.1 ReplicationController,RC(复制控制器)

适用于长期伺服型的业务类型

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

1.3.2 ReplicaSet,RS(副本集)

适用于长期伺服型的业务类型

RS是新一代的RC,提供同样的高可用能力,只是能支持更多种类的匹配模式,支持集合式的selector。副本集对象一般不单独使用,而是作为Deployment的理想状态参数使用。

1.3.3 Deployment(部署)

适用于长期伺服型的业务类型

Deployment表示对K8S集群的一次更新操作。可以创建、更新、滚动升级一个新的服务。滚动升级,实际上就是创建新的RS,将RS副本数增加到设定的值,然后将旧的RS减小到0,滚动更新同时包括回滚。

虽然RS可以独立使用,但一般还是使用Deployment来管理,这样就无需担心跟其他机制不兼容的问题(比如 RS不支持rolling-update,但Deployment支持)

1.3.4 Horizontal Pod Autoscaling (平滑扩展)

支持Replication controllerDeploymentReplica Set,在v1版本中仅支持根据PodCPU利用率扩缩容,在v1alpha版本中,支持根据内存和用户自定义的metrics扩缩容

1.3.5 StatefulSet(有状态服务)

StatefulSet是为了解决有状态服务的问题(对应DeploymentsReplicaSets是为无状态服务而设计)

  • 稳定的持久化存储,即Pod重新调度后还是能访问到相同的持久化数据,基于PVC实现。

  • 稳定的网络标志,即Pod重新调度后其PodNameHostName不变,基于Headless Service(即没有Cluster IPService)实现

  • 有序部署,有序扩展,即Pod是有序的,在部署或扩展时要依据定义的顺序依次进行(即从0N-1,在下一个Pod运行之前所有之前的Pod必须都是Running或者Ready状态),基于init containers 来实现

    举个栗子,部署的应用,应该先启mysql,在启apach,在启nginx。如果顺序不对,例如mysql还没启动,就启动了apach,就会报错,报找不到数据;没有启动nginx,就启动了apach,会报找不到代理的路径。

  • 有序收缩,有序删除(即从N-10

  • 有序的自动滚动更新

其与PetSet有什么关联嘛?

1.3.6 DaemonSet(后台支撑服务)

DaemonSet确保全部(或者一些,可以给某个Node打污点)Node上运行一个(有且只有一个)Pod的副本。当有Node加入集群时,也会为他们新增一个Pod。当有Node从集群移除时,这些Pod也会被回收。删除DeamonSet将会删除它创建的所有它所创建的Pod

使用DaemonSet的一些典型案例:

  • 运行集群存储daemon,例如每个Node上运行glusterdceph
  • 在每个Node上运行日志收集daemon,例如fluentdlogstash
  • 在每个Node上运行监控daemon,例如Prometheus Node Exporter

思考,如果每个Node都要运行好几个类似的程序怎么办?

解法1:将其整合成一个Pod的不同服务

解法2:多个DaemonSet

1.3.6 Job

负责批处理任务,即仅执行一次的任务,它保证批处理任务的一个或多个Pod成功结束

1.3.7 Cron Job

管理基于时间的Job, 即:

  • 在给定时间点只运行一次
  • 周期性地在给定时间点运行
1.3.8 Service(服务发现)

Service用来访问具有同一组标签的Pod,访问Service的的Ip+端口即可轮询访问到其所绑定的Pod

每个Service会对应一个集群内部有效的虚拟IP,集群内部通过虚拟IP访问一个服务。在K8s集群中微服务的负载均衡是由Kube-proxy实现的。Kube-proxy是K8s集群内部的负载均衡器。

后续要访问Service可以通过Node-port或者Service LoadBalancer或者IngressIngress Controller

2 网络通讯方式

2.1 网络插件解决网络连通问题

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

所以构建集群需要先解决扁平化的网络空间。

如何解决?Flannel、Calico、Weave……

2.2 如何访问

  • 同一个Pod内的多个容器:IO,直接localhost+端口即可访问

  • 各个Pod之间的通讯:Overlay Network

    • Pod在相同网段(同一台机器)

      Docker0网桥直接进行转发

    • Pod在不用网段(不同机器)

      Pod的地址是与Docker0在同一个网段的,但Docker0网段与宿主机网段是两个完全不同的IP网段,并且不同Node之间的通信只能通过宿主机的物理网卡进行。将PodIP和所在NodeIP关联起来,通过这个关联让Pod可以相互访问

  • PodService之间的通讯

    各个节点的Iptables规则,新一些的版本加入了LVS转换,效率更高

  • Pod到外网:Pod向外网发送请求,查找路由表,转发数据包到宿主机网卡,宿主网卡完成路由选择后,Iptables执行Masquerade,把源IP更改为宿主网卡的IP,然后向外网服务器发送请求

  • 外网访问PodServiceIngress

2.3 Flannel

FlannelCoreOS团队针对Kubernetes设计的一个网络规划服务,简单来说,它的功能是让集群中的不用节点主机创建的Docker容器具有全集群唯一的虚拟IP地址。而且它还能在这些IP地址之间建立一个覆盖网络(Overlay Network),通过这个覆盖网络,将数据包原封不动的传递到目标容器内。

img

2.4 ETCD与Flannel关联

etcd存储管理Flanner可分配的IP地址段资源

监控etcd中每个Pod的实际地址,并在内存中建立维护Pod节点路由表

etcdKubernetes集群中多处被调用,非常非常重要。

Logo

K8S/Kubernetes社区为您提供最前沿的新闻资讯和知识内容

更多推荐