系列

容器化技术与微服务结合—docker(一)
容器化技术与微服务结合—Kubernetes基本介绍(二)
容器化技术与微服务结合—Pod详解(三)
容器化技术与微服务结合—实操service并部署一个简单对外开放的springboot HelloWord服务(四)
容器化技术与微服务结合—结合springcloud微服务框架进行部署(含切换成阿里云docker仓库)(五)
容器化技术与微服务结合—SpringCloud框架与阿里云serverless k8s的结合(六)

设想

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

  • 容器便是某个应用进程
  • 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 容器之间

  1. 两个pod在一台主机上面

  2. 两个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构建微服务之路

Logo

开源、云原生的融合云平台

更多推荐