系列

容器化技术与微服务结合—docker（一）
容器化技术与微服务结合—Kubernetes基本介绍（二）
容器化技术与微服务结合—Pod详解（三）

设想

如果按照现有操作系统、微服务集群、软件来做比喻

容器便是某个应用进程
Kubernetes则是操作系统
那么，容器镜像看来应该就是各种软件安装包
Pod便是微服务集群，统一管理里面的微服务（其实就是一个group组的概念，进程组）

那么为什么需要Pod，我们按照互联网业务方面想想，为什么在数据结构上往往有更多的父子关系，一父多子？是不是更加方便管理和运维。

Pod这种组的概念，让具体某些进程（应用或者服务）更加亲密，更加方便管理。

例子

我们现在想搭建内网业务集群，开始划分网段VPC（相当于Namespace），然后定义一些网段名称，比如：1. A网段有三个ip子集，用于管理业务（Pod-A）； 2. B网段用于存储管理，有2个高可用ip子集（Pod-B）
订单场景：我们想给所有的子订单定义范围和类型。我们设定父子关系，父订单上打标签：1. A类父订单表示线上支付，拥有几万个子订单（Pod-A）； 2. B类父订单标识线下交易，拥有几十万的子订单（Pod-B）
等等等等

在这里插入图片描述
Pod可以让进程间变得更加亲密，方便管理。

微服务层面

当容器（微服务应用）应该是捆绑耦合提供服务的时候，可以将他们完全绑定在一个pod，利用localhost机制通信，对外提供相应的服务
在这里插入图片描述

微服务业务场景下，针对k8s内部部署，最重要的就是通信问题，而Pod通信又分为三种：

pod内部容器之间通信

这种情况很简单，微服务都部署在一起，localhost通信即可，但是一旦跨地域跨节点就比较麻烦了，你的机器得有多大才可以部署一个pod下所有微服务

pod 与 pod 容器之间

两个pod在一台主机上面
两个pod分布在不同主机之上

针对第一种情况，就比较简单了，就是docker默认的docker网桥互连容器。

第二种情况需要更为复杂的网络模型了，k8s官方推荐的是使用flannel组建一个大二层扁平网络，pod的ip分配由flannel统一分配，通讯过程也是走flannel的网桥。

docker --daemon --bip=172.17.18.1/24

注意其中的“–bip=172.17.18.1/24”这个参数，它限制了所在节点容器获得的IP范围。

每个node上面都会创建一个flannel0虚拟网卡，用于跨node之间通讯。所以容器直接可以直接使用pod id进行通讯。

也就是说，你要自己维护ip池，设计ip规划。头疼啊，相当于造一个vpc出来

pod 访问service服务

这个就和外面调用的没啥区别了。。。。。参考上一张service的概念

实例

在这里插入图片描述
如图，我们有两个微服务，分别部署在不同的pod中，在Customer Service中，我们打算从Account Service调用API方法。这是声明式REST客户端@FeignClient声明。 所有具有Account Service的Pod在服务名称和默认服务端口2222下均可用。此类设置是Kubernetes上服务配置的结果。

@FeignClient(name = "account-service", url = "http://account-service:2222")
public interface AccountClient {
@RequestMapping(method = RequestMethod.GET, value = "/accounts/customer/{customerId}")
List<Account> getAccounts(@PathVariable("customerId") String customerId);

}

Pod的实现机制

共享网络

在这里插入图片描述

共享存储

在这里插入图片描述

部署举例

我现在要发布一个应用，这个应用是 JAVA 写的，有一个 WAR 包需要把它放到 Tomcat 的 web APP 目录下面，这样就可以把它启动起来了。可是像这样一个 WAR 包或 Tomcat 这样一个容器的话，怎么去做，怎么去发布？这里面有几种做法。

第一种方式：可以把 WAR 包和 Tomcat，打包放进一个镜像里面。但是这样带来一个问题，就是现在这个镜像实际上揉进了两个东西。那么接下来，无论是我要更新 WAR 包还是说我要更新Tomcat，都要重新做一个新的镜像，这是比较麻烦的；
第二种方式：就是镜像里面只打包 Tomcat。它就是一个 Tomcat，但是需要使用数据卷的方式，比如说 hostPath，从宿主机上把WAR 包挂载进我们 Tomcat 容器中，挂到我的 web APP 目录下面，这样把这个容器启用起来之后，里面就能用了。

但是这时会发现一个问题：这种做法一定需要维护一套分布式存储系统。因为这个容器可能第一次启动是在宿主机 A 上面，第二次重新启动就可能跑到 B 上去了，容器它是一个可迁移的东西，它的状态是不保持的。所以必须维护一套分布式存储系统，使容器不管是在 A 还是在 B 上，都可以找到这个 WAR 包，找到这个数据。

参考Pod，我们可以将他们利用共享存储的方式进行部署，如下
在这里插入图片描述

Pod的辅助小秘-Sidecar

通过定义一些特殊的容器，来执行一些业务的辅助性工作，如日志手机、脚本执行、应用监控等，从而和主业务进行解耦。方便重用，并具有独立性

这里从研发角度来看，更倾向于非业务性组件，辅助业务进行快速调用和迭代。

举个例子，sidecar可以作为代理来去分发。比如某些集群需要访问外面的一些集群信息，但是不想去修改代码，存储外部集群的ip池子。这个时候我们可以创建一个小的sidecar，所有服务访问统一的sidecar即可（类似于lb）

Pod的yaml配置

我们可以看一下详细的yaml配置：

# yaml格式的pod定义文件完整内容：
apiVersion: v1        #必选，版本号，例如v1
kind: Pod       #必选，Pod
metadata:       #必选，元数据
  name: string        #必选，Pod名称
  namespace: string     #必选，Pod所属的命名空间
  labels:       #自定义标签
    - name: string      #自定义标签名字
  annotations:        #自定义注释列表
    - name: string
spec:         #必选，Pod中容器的详细定义
  containers:       #必选，Pod中容器列表
  - name: string      #必选，容器名称
    image: string     #必选，容器的镜像名称
    imagePullPolicy: [Always | Never | IfNotPresent]  #获取镜像的策略 Alawys表示下载镜像 IfnotPresent表示优先使用本地镜像，否则下载镜像，Nerver表示仅使用本地镜像
    command: [string]     #容器的启动命令列表，如不指定，使用打包时使用的启动命令
    args: [string]      #容器的启动命令参数列表
    workingDir: string      #容器的工作目录
    volumeMounts:     #挂载到容器内部的存储卷配置
    - name: string      #引用pod定义的共享存储卷的名称，需用volumes[]部分定义的的卷名
      mountPath: string     #存储卷在容器内mount的绝对路径，应少于512字符
      readOnly: boolean     #是否为只读模式
    ports:        #需要暴露的端口库号列表
    - name: string      #端口号名称
      containerPort: int    #容器需要监听的端口号
      hostPort: int     #容器所在主机需要监听的端口号，默认与Container相同
      protocol: string      #端口协议，支持TCP和UDP，默认TCP
    env:        #容器运行前需设置的环境变量列表
    - name: string      #环境变量名称
      value: string     #环境变量的值
    resources:        #资源限制和请求的设置
      limits:       #资源限制的设置
        cpu: string     #Cpu的限制，单位为core数，将用于docker run --cpu-shares参数
        memory: string      #内存限制，单位可以为Mib/Gib，将用于docker run --memory参数
      requests:       #资源请求的设置
        cpu: string     #Cpu请求，容器启动的初始可用数量
        memory: string      #内存清楚，容器启动的初始可用数量
    livenessProbe:      #对Pod内个容器健康检查的设置，当探测无响应几次后将自动重启该容器，检查方法有exec、httpGet和tcpSocket，对一个容器只需设置其中一种方法即可
      exec:       #对Pod容器内检查方式设置为exec方式
        command: [string]   #exec方式需要制定的命令或脚本
      httpGet:        #对Pod内个容器健康检查方法设置为HttpGet，需要制定Path、port
        path: string
        port: number
        host: string
        scheme: string
        HttpHeaders:
        - name: string
          value: string
      tcpSocket:      #对Pod内个容器健康检查方式设置为tcpSocket方式
         port: number
       initialDelaySeconds: 0   #容器启动完成后首次探测的时间，单位为秒
       timeoutSeconds: 0    #对容器健康检查探测等待响应的超时时间，单位秒，默认1秒
       periodSeconds: 0     #对容器监控检查的定期探测时间设置，单位秒，默认10秒一次
       successThreshold: 0
       failureThreshold: 0
       securityContext:
         privileged: false
    restartPolicy: [Always | Never | OnFailure] #Pod的重启策略，Always表示一旦不管以何种方式终止运行，kubelet都将重启，OnFailure表示只有Pod以非0退出码退出才重启，Nerver表示不再重启该Pod
    nodeSelector: obeject   #设置NodeSelector表示将该Pod调度到包含这个label的node上，以key：value的格式指定
    imagePullSecrets:     #Pull镜像时使用的secret名称，以key：secretkey格式指定
    - name: string
    hostNetwork: false      #是否使用主机网络模式，默认为false，如果设置为true，表示使用宿主机网络
    volumes:        #在该pod上定义共享存储卷列表
    - name: string      #共享存储卷名称 （volumes类型有很多种）
      emptyDir: {}      #类型为emtyDir的存储卷，与Pod同生命周期的一个临时目录。为空值
      hostPath: string      #类型为hostPath的存储卷，表示挂载Pod所在宿主机的目录
        path: string      #Pod所在宿主机的目录，将被用于同期中mount的目录
      secret:       #类型为secret的存储卷，挂载集群与定义的secre对象到容器内部
        scretname: string  
        items:     
        - key: string
          path: string
      configMap:      #类型为configMap的存储卷，挂载预定义的configMap对象到容器内部
        name: string
        items:
        - key: string
          path: string

参考

基于Kubernetes和Springboot构建微服务
 基于Kubernetes和Docker构建微服务之路

codemperor

发布了38 篇原创文章 · 获赞 23 · 访问量 1万+

私信关注

容器化技术与微服务结合---Pod详解（三）

目录

系列

设想

例子