关于kubernetes:K8S-容器和Pod组件

比照软件装置和运行；

一、场景

作为研发人员，通常本人电脑的零碎环境都是非常复杂，在集体的习惯上，是依照下图的模块治理电脑的零碎环境；

对于「基础设施」、「主机操作系统」、「系统软件」来说，通常只做配置批改；

对于自行装置的软件环境来说，集体通常这样分类：「应用软件」、「研发软件」、「继续集成」、「虚拟机环境」；

• 应用软件：次要指罕用的办公软件，比方文档编写，画图设计，通信产品等；
• 研发软件：比方根底开发环境，各种中间件环境，数据存储查问等；
• 继续集成：支流的就是 Jenkins、Docker、Kubernetes 等组件，整体比较复杂，不好治理；
• 虚拟机环境：研发必备的 Linux 操作系统，用来部署一些规范的组件集群；

不论是这些软件环境还是虚拟机零碎的搭建，根本都是通过下载软件安装包，而后在本地部署和定期更新以及运行，基于这个场景再去了解容器和 Pod 组件，会轻松许多；

二、容器

1、容器镜像

参考下面零碎环境的治理，软件包和装置部署的原理；

Docker 容器镜像是一个轻量级的、独立的、可执行的软件包，它蕴含了运行应用程序所需的所有: 代码、运行时、零碎工具、零碎库和设置，带有创立 Docker 容器的阐明；

能够通过 Dockerfile 脚本自定义镜像，也能够应用云端仓库中其他人公开公布的，生产环境通常采纳公有仓库治理镜像；

容器镜像所承载的是封装了应用程序及其所有软件依赖的二进制数据，容器镜像是可执行的软件包，能够独自运行；通常会创立利用的容器镜像并将其推送到某仓库，而后在 Pod 中援用它；

2、容器

容器将应用程序从底层的主机设施中解耦，这使得在不同的云或 OS 环境中部署更加容易；

容器的实质就是一个视图隔离、可限度资源、独立文件系统的过程汇合；

以常见的 Linux 研发环境来剖析，能够限度容器的资源分配，比方内存大小、CPU 应用，隔离过程之间的通信，设置独立的文件系统等；

Kubernetes 集群中的每个节点都会运行容器，这些容器形成调配给该节点的 Pod，单个 Pod 中的容器会在独特调度下，于同一地位运行在雷同的节点上；

从整体上能够把 K8S 了解为「操作系统」，镜像了解为「软件安装包」，容器了解为「利用过程」；

3、实际案例

制作镜像，首先将代码工程 auto-client 和auto-serve打包，而后构建镜像文件，放在本地环境中；

• 制作【auto-client】镜像

构建命令

docker build -t auto-client:latest .

Dockerfile 脚本

# 根底镜像
FROM openjdk:8

# 维护者
MAINTAINER cicadasmile

# 长久化目录
VOLUME /data/docker/logs

# 增加应用服务 JAR 包
ADD auto-client.jar application.jar

# 配置参数
ENTRYPOINT ["java","-Dspring.profiles.active=dev","-Djava.security.egd=file:/dev/./urandom","-jar","/application.jar"]

• 制作【auto-serve】镜像

构建命令

docker build -t auto-serve:latest .

Dockerfile 脚本

# 根底镜像
FROM openjdk:8

# 维护者
MAINTAINER cicadasmile

# 长久化目录
VOLUME /data/docker/logs

# 增加应用服务 JAR 包
ADD auto-serve.jar application.jar

# 配置参数
ENTRYPOINT ["java","-Dspring.profiles.active=dev","-Djava.security.egd=file:/dev/./urandom","-jar","/application.jar"]

三、Pod 组件

1、基本概念

Pod 是能够在 K8S 中创立和治理的、最小的可部署的计算单元；

Pod 是一组（一个或多个）容器，这些容器共享存储、网络、以及怎么运行这些容器的申明，Pod 中的内容总是并置的并且一起调度，在共享的上下文中运行；

2、Pod 治理

【Pod 创立】

通常不会间接创立 Pod，而是应用诸如 Deployment 或 Job 这类工作负载资源来创立 Pod；是绝对临时性的、用后即抛的一次性实体；

【单容器 Pod】

每个 Pod 都意在运行给定应用程序的单个实例，能够应用多个 Pod 对应用程序横向扩大，即一个实例一个 Pod 对应，Pod 看作单个容器的包装器由 K8S 间接治理，是常见的部署形式；

【多容器 Pod】

分布式系统中可能存在由多个严密耦合且须要共享资源的共处容器组成的应用程序，比拟典型的是「生产生产」场景，Pod 将这些容器和存储资源打包为一个可治理的实体；

Pod 中的容器被主动安顿到集群中的同一物理机或虚拟机上，并能够一起进行调度，容器之间能够共享网络和存储资源和依赖、彼此通信、协调何时以及何种形式终止本身；

容器之间本来是被隔离开的，而 Pod 在设计上能够冲破这种隔离，进而实现资源共享；

• 存储共享

在 Pod 层面设置共享的 Volume，该 Pod 中所有容器都能够拜访该共享 Volume，这也是 Pod 组件的存储形式，Volume 还容许 Pod 中持久数据保留下来，即便其中的容器须要重新启动；

• 网络共享

同一个 Pod 内，所有容器共享一个 IP 地址和端口空间，并且能够通过 localhost 发现对方；

3、实际案例

3.1 Pod 脚本

在此前的案例中，都是单容器 Pod，这里演示多容器 Pod，将【auto-client】和【auto-serve】放在同一个「auto-pod」中运行；

并且这里为两个容器调配 CPU 和内存资源，requests是要为容器指定资源需要，limits是要为容器指定资源限度；

apiVersion: v1
kind: Pod
metadata:
  name: auto-pod
spec:
  containers:
    - name: auto-client
      image: auto-client
      imagePullPolicy: Never
      ports:
        - containerPort: 8079
      resources:
        requests:
          cpu: "250m"
          memory: "64Mi"
        limits:
          cpu: "500m"
          memory: "128Mi"
    - name: auto-serve
      image: auto-serve
      imagePullPolicy: Never
      ports:
        - containerPort: 8082
      resources:
        requests:
          cpu: "250m"
          memory: "64Mi"
        limits:
          cpu: "500m"
          memory: "128Mi"

3.2 Pod 命令

• 创立 Pod

kubectl create -f pod.yaml

• 查看指定 Pod

kubectl get pod/auto-pod -o wide
NAME       READY   STATUS    RESTARTS   AGE    IP           NODE             NOMINATED NODE   READINESS GATES
auto-pod   2/2     Running   0          9m2s   10.1.0.123   docker-desktop   <none>           <none>

• 查看指定 Pod 形容

kubectl describe pod/auto-pod

# 此处只展现局部信息
Name:         auto-pod
Namespace:    default
Node:         docker-desktop/192.168.65.11
Status:       Running
IP:           10.1.0.123
Containers:
  auto-client:
    Container ID:   docker://Container-ID
    Image:          auto-client
    Image ID:       docker://sha256:Image-ID
    Port:           8079/TCP
    Limits:
      cpu:     500m
      memory:  128Mi
    Requests:
      cpu:        250m
      memory:     64Mi
  auto-serve:
    Container ID:   docker://Container-ID
    Image:          auto-serve
    Image ID:       docker://sha256:Image-ID
    Port:           8082/TCP
    Limits:
      cpu:     500m
      memory:  128Mi
    Requests:
      cpu:        250m
      memory:     64Mi
Events:
  Type    Reason     Age   From               Message
  ----    ------     ----  ----               -------
  Normal  Scheduled  38s   default-scheduler  Successfully assigned default/auto-pod to docker-desktop
  Normal  Pulled     37s   kubelet            Container image "auto-client" already present on machine
  Normal  Created    37s   kubelet            Created container auto-client
  Normal  Started    37s   kubelet            Started container auto-client
  Normal  Pulled     37s   kubelet            Container image "auto-serve" already present on machine
  Normal  Created    37s   kubelet            Created container auto-serve
  Normal  Started    37s   kubelet            Started container auto-serve

• 删除 Pod

kubectl delete -f pod.yaml

3.3 服务日志

在「auto-client」服务中，提供一个简略的定时工作，每 10 秒拜访一次「auto-serve」的接口，打印申请的响应后果；

@Component
public class HttpJob {private static final Logger LOG = LoggerFactory.getLogger(HttpJob.class.getName()) ;

    private static final String SERVER_URL = "http://localhost:8082/serve";

    /**
     * 每 10 秒执行一次
     */
    @Scheduled(fixedDelay = 10000)
    public void systemDate (){
        try{SimpleClientHttpRequestFactory factory = new SimpleClientHttpRequestFactory();
            factory.setReadTimeout(3000);
            factory.setConnectTimeout(6000);
            RestTemplate restTemplate = new RestTemplate(factory);
            Map<String,String> paramMap = new HashMap<>() ;
            String result = restTemplate.getForObject(SERVER_URL,String.class,paramMap);
            LOG.info("server-resp::::"+result);
        } catch (Exception e){e.printStackTrace();
        }
    }
}

在「auto-serve」服务中，提供一个简略的 Get 申请接口；

@RestController
public class ServeWeb {private static final Logger logger = LoggerFactory.getLogger(ServeWeb.class) ;

    @Value("${server.port:}")
    private Integer servePort ;

    @GetMapping("/serve")
    public String serve (){logger.info("serve:{}",servePort);
        return "serve:"+servePort ;
    }
}

查看两个容器的运行日志，发现「auto-client」和「auto-serve」能够失常通信，以此来验证同一个 Pod 内网络共享；

4、状态与重启

4.1 重启策略

能够在 Pod 中通过 restartPolicy 属性设置重启策略，罕用的取值是 Always 以升高利用的中断工夫，实用于 Pod 中的所有容器；

• Always：默认值，容器生效时，kubelet 主动重启该容器。
• OnFailure：容器进行运行且退出码不为 0 时，kubelet 主动重启该容器。
• Never：不管容器是什么状态，kubelet 都不重启该容器。

4.2 生命周期

• Pending：Pod 被 Kubernetes 零碎承受，但有一个或者多个容器未创立，此阶段包含期待 Pod 被调度的工夫和通过网络下载镜像的工夫。
• Running：Pod 曾经绑定到了某个节点，Pod 中所有的容器都已被创立，至多有一个容器在运行，或者正处于启动或重启状态。
• Succeeded：Pod 中的所有容器都已胜利终止，并且不会再重启。
• Failed：Pod 中的所有容器都已终止，并且至多有一个容器是因为失败被终止。
• Unknown：因为某些起因无奈获得 Pod 的状态，通常是因为与 Pod 所在主机通信失败。

Pod 遵循预约义的生命周期，起始于 Pending 阶段，如果至多其中有一个次要容器失常启动，则进入 Running 阶段，之后取决于 Pod 中是否有容器以失败状态完结而进入 Succeeded 或者 Failed 阶段。

四、参考源码

文档仓库：https://gitee.com/cicadasmile/butte-java-note

脚本仓库：https://gitee.com/cicadasmile/butte-auto-parent