Kubernetes官方java客户端之七：patch操做

时间  2021-01-13
标签 html java node nginx git 程序员 github web redis spring 栏目 Java 繁體版
原文   原文链接

欢迎访问个人GitHub

https://github.com/zq2599/blog_demoshtml

内容：全部原创文章分类汇总及配套源码，涉及Java、Docker、Kubernetes、DevOPS等；java

概览

  1. 本文是《Kubernetes官方java客户端》系列的第七篇，如下提到的java客户端都是指client-jar.jar；
  2. 本文主要内容是经过java客户端发起patch请求，用来修改已有资源;
  3. 接下来会对kubernetes的patch作一些介绍，因为我们这里的重点仍是java客户端的patch操做，所以不会对patch的原理和概念展开太多，仅作最基本的说明能便可；

本文内容

这是篇万字长文，因此一开始就要明确本文的核心内容：开发一个SpringBoot应用并部署在kubernetes环境，这个应用经过kubernetes的java客户端向API Server发请求，请求内容包括：建立名为test123的deployment、对这个deployment进行patch操做，以下图：node

在这里插入图片描述

接下来先了解一些kubernetes的patch相关的基本知识；nginx

关于patch

  1. 是对各类资源的增删改查是kubernetes的基本操做；
  2. 对于修改操做，分为Replace和Patch两种；
  3. Replace好理解，就是用指定资源替换现有资源，replace有个特色，就是optimistic lock约束（相似与转帐操做，先读再计算再写入）；
  4. Patch用来对资源作局部更新，没有optimistic lock约束，老是最后的请求会生效，所以若是您只打算修改局部信息，例如某个属性，只要指定属性去作patch便可（若是用Replace，就只能先取得整个资源，在本地修改指定属性，再用Replace总体替换）；
  5. 更详细的信息请参考下图，来自官方文档，地址：https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.18/
    在这里插入图片描述

patch的四种类型

kubernetes的patch一共有四种：git

  1. json patch：在请求中指定操做类型，例如：add、replace，再指定json内容进行操做z，请参考：https://tools.ietf.org/html/rfc6902
  2. merge patch：合并操做，能够提交整个资源的信息，与现有信息进行合并后生效，也能够提交部分信息用于替换，请参考：https://tools.ietf.org/html/rfc7386
  3. strategic merge patch：json patch和merge patch都遵照rfc标准，可是strategic merge patch倒是kubernetes独有的，官方中文文档中称为策略性合并，也是merge的一种，可是真正执行时kubernetes会作合并仍是替换是和具体的资源定义相关的（具体策略由 Kubernetes 源代码中字段标记中的 patchStrategy 键的值指定），以Pod的Container为例，下面是其源码，红框中显示其Container节点的patchStrategy属性是merge，也就是说若是您提交了一份strategic merge patch，里面的内容是关于Pod的Container的，那么原有的Container不会被替换，而是合并(例如之前只有nginx，提交的strategic merge patch是redis，那么最终pod下会有两个container：nginx和redis)：

在这里插入图片描述

  1. 经过源码查看资源的patchStrategy属性是很麻烦的事情，所以也能够经过Kubernetes API 文档来查看，以下图，地址是：https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.18/#podspec-v1-core

在这里插入图片描述

  1. 第四种是apply patch：主要是指kubernetes 1.14版本开始的server-side apply，由APIServer 作 diff 和 merge 操做，不少本来易碎的现象都获得了解决(例如controller和kubectl都在更新)，另外要格外注意的是：1.14版本默认是不开启server-side apply特性的，具体的开启操做在下面会详细讲解；
  • 以上是对kubernetes四种patch的简介，讲得很浅，若是您想深刻了解每种patch，建议参阅官方资料，接下来我们聚焦java客户端对这些patch能力的实现；

源码下载

  1. 若是您不想编码，能够在GitHub下载全部源码，地址和连接信息以下表所示(https://github.com/zq2599/blog_demos)：
名称 连接 备注
项目主页 https://github.com/zq2599/blog_demos 该项目在GitHub上的主页
git仓库地址(https) https://github.com/zq2599/blog_demos.git 该项目源码的仓库地址，https协议
git仓库地址(ssh) git@github.com:zq2599/blog_demos.git 该项目源码的仓库地址，ssh协议
  1. 这个git项目中有多个文件夹，本章的应用在kubernetesclient文件夹下，以下图红框所示：

在这里插入图片描述

实战步骤概述

  • 接下来会建立一个springboot工程(该工程是kubernetesclient的子工程)，针对四种patch我们都有对应的操做；
  • 每种patch都会准备对应的json文件，提早将这些文件的内容保存在字符串变量中，在程序里用kubernetes客户端的patch专用API，将此json字符串发送出去，流程简图以下：
    在这里插入图片描述
  • 编码完成后，就来动手验证功能，具体操做以下：
  1. 部署名为patch的deployment，这里面是我们编码的SpringBoot工程，提供多个web接口；
  2. 浏览器访问/patch/deploy接口，就会建立名为test123的deployment，这个deployment里面是个nginx，接下来的patch操做都是针对这个名为test123的deployment；
  3. 浏览器访问test123的nginx服务，确保部署成功了；
  4. 浏览器访问/patch/json接口，该接口会修改test123的一个属性：terminationGracePeriodSeconds
  5. 浏览器访问/patch/fullmerge接口，该接口会提交全量merge请求，修改内容不多，仅增长了一个label属性；
  6. 接下来是对比merge patch和strategic merge patch区别，分别访问/patch/partmerge和/patch/strategic这两个接口，其实它们操做的是同一段patch内容(一个新的container)，结果merge patch会替换原有的continer，而strategic merge patch不会动原有的container，而是新增container，致使test123这个deployment下面的pod从一个变为两个；
  7. 最后是apply yaml patch，访问接口/patch/apply，会将nginx容器的标签从1.18.0改成1.19.1，我们只要在浏览器访问test123里面的nginx服务就能肯定是否修改生效了；

准备工做

准备工做包括建立工程、编写辅助功能代码、初始化代码等：程序员

  1. 打开《Kubernetes官方java客户端之一：准备 》一文建立的项目kubernetesclient，新增名为patch的子工程，pom.xml内容以下：
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <parent>
        <groupId>com.bolingcavalry</groupId>
        <artifactId>kubernetesclient</artifactId>
        <version>1.0-SNAPSHOT</version>
        <relativePath>../pom.xml</relativePath>
    </parent>

    <groupId>com.bolingcavalry</groupId>
    <artifactId>patch</artifactId>
    <version>0.0.1-SNAPSHOT</version>
    <name>patch</name>
    <description>patch demo</description>
    <packaging>jar</packaging>

    <dependencies>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-web</artifactId>
            <exclusions>
                <exclusion>
                    <groupId>org.springframework.boot</groupId>
                    <artifactId>spring-boot-starter-json</artifactId>
                </exclusion>
            </exclusions>
        </dependency>

        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-actuator</artifactId>
        </dependency>

        <dependency>
            <groupId>org.projectlombok</groupId>
            <artifactId>lombok</artifactId>
            <optional>true</optional>
        </dependency>

        <dependency>
            <groupId>io.kubernetes</groupId>
            <artifactId>client-java</artifactId>
        </dependency>
    </dependencies>

    <build>
        <plugins>
            <plugin>
                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-maven-plugin</artifactId>
                <version>2.3.0.RELEASE</version>
                <!--该配置会在jar中增长layer描述文件，以及提取layer的工具-->
                <configuration>
                    <layers>
                        <enabled>true</enabled>
                    </layers>
                </configuration>
            </plugin>
        </plugins>
    </build>

</project>
  1. 编写一个辅助类ClassPathResourceReader.java，做用是读取json文件的内容做为字符串返回：
package com.bolingcavalry.patch;

import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
import java.util.stream.Collectors;
import org.springframework.core.io.ClassPathResource;

public class ClassPathResourceReader {

    private final String path;

    private String content;

    public ClassPathResourceReader(String path) {
        this.path = path;
    }

    public String getContent() {
        if (content == null) {
            try {
                ClassPathResource resource = new ClassPathResource(path);
                BufferedReader reader = new BufferedReader(new InputStreamReader(resource.getInputStream()));
                content = reader.lines().collect(Collectors.joining("\n"));
                reader.close();
            } catch (IOException ex) {
                throw new RuntimeException(ex);
            }
        }
        return content;
    }
}
  1. 接下来新建本篇文章的核心类PatchExample.java，首先这个类中有main方法，整个应用从这里启动：
public static void main(String[] args) {
        SpringApplication.run(PatchExample.class, args);
    }
  1. 接下来有两个常量定义，分别是kubernetes环境里用来测试的deployment名称，以及namespace名称：
static String DEPLOYMENT_NAME = "test123";

static String NAMESPACE = "default";
  1. 而后定义几个字符串变量，执行patch操做时用到的json内容都保存到这些字符串变量中：
static String deployStr, jsonStr, mergeStr, strategicStr, applyYamlStr;
  1. 在resources文件夹中放入json文件，稍后的初始化代码会将这些文件读取到字符串变量中，以下图，这些json文件的内容稍后会详细说明：

在这里插入图片描述

  1. 编写初始化代码(经过PostConstruct注解实现)，主要是客户端配置，还有将json文件的内容读出来，保存到刚刚准备的字符串变量中：
@PostConstruct
    private void init() throws IOException {
        // 设置api配置
        ApiClient client = Config.defaultClient();
        Configuration.setDefaultApiClient(client);
        // 设置超时时间
        Configuration.getDefaultApiClient().setConnectTimeout(30000);

        // 部署用的JSON字符串
        deployStr = new ClassPathResourceReader("deploy.json").getContent();

        // json patch用的JSON字符串
        jsonStr = new ClassPathResourceReader("json.json").getContent();

        // merge patch用的JSON字符串，和部署的JSON相比：replicas从1变成2，增长一个名为from的label，值为merge
        mergeStr = new ClassPathResourceReader("merge.json").getContent();

        // strategic merge patch用的JSON字符串
        strategicStr = new ClassPathResourceReader("strategic.json").getContent();

        // server side apply用的JSON字符串
        applyYamlStr = new ClassPathResourceReader("applyYaml.json").getContent();
    }
  • 以上就是准备工做；

建立服务

  1. 首先要开发一个部署的接口，经过调用此接口能够在kubernetes环境部署一个deployment：
  2. 部署服务的path是/patch/deploy，代码以下，可见部署deployment的代码分为三步：建立api实例、用字符串建立body实例、把body传给api便可：
/**
     * 通用patch方法
     * @param patchFormat patch类型，一共有四种
     * @param deploymentName deployment的名称
     * @param namespace namespace名称
     * @param jsonStr patch的json内容
     * @param fieldManager server side apply用到
     * @param force server side apply要设置为true
     * @return patch结果对象转成的字符串
     * @throws Exception
     */
    private String patch(String patchFormat, String deploymentName, String namespace, String jsonStr, String fieldManager, Boolean force) throws Exception {
        // 建立api对象，指定格式是patchFormat
        ApiClient patchClient = ClientBuilder
                .standard()
                .setOverridePatchFormat(patchFormat)
                .build();

        log.info("start deploy : " + patchFormat);

        // 开启debug便于调试，生产环境慎用！！！
        patchClient.setDebugging(true);

        // 建立deployment
        ExtensionsV1beta1Deployment deployment = new ExtensionsV1beta1Api(patchClient)
                .patchNamespacedDeployment(
                        deploymentName,
                        namespace,
                        new V1Patch(jsonStr),
                        null,
                        null,
                        fieldManager,
                        force
                );

        log.info("end deploy : " + patchFormat);

        return new GsonBuilder().setPrettyPrinting().create().toJson(deployment);
    }
  1. body实例用到的json字符串来自deploy.json文件，内容以下，很简单，只有nginx的1.18.0版本的pod：
{
  "kind":"Deployment",
  "apiVersion":"extensions/v1beta1",
  "metadata":{
    "name":"test123",
    "labels":{
      "run":"test123"
    }
  },
  "spec":{
    "replicas":1,
    "selector":{
      "matchLabels":{
        "run":"test123"
      }
    },
    "template":{
      "metadata":{
        "creationTimestamp":null,
        "labels":{
          "run":"test123"
        }
      },
      "spec":{
        "terminationGracePeriodSeconds":30,
        "containers":[
          {
            "name":"test123",
            "image":"nginx:1.18.0",
            "ports":[
              {
                "containerPort":80
              }
            ],
            "resources":{

            }
          }
        ]
      }
    },
    "strategy":{

    }
  },
  "status":{

  }
}
  1. 如此一来，web浏览器只要访问/patch/deploy就能建立deployment了；

发起patch请求的通用方法

  • 经过kubernetes的客户端发起不一样的patch请求，其大体步骤都是相同的，只是参数有所不一样，我这里作了个私有方法，发起几种patch请求的操做都调用此方法实现(只是入参不一样而已)，可见都是先建好ApiClient实例，将patch类型传入，再建立V1Patch实例，将patch字符串传入，最后执行ExtensionsV1beta1Api实例的patchNamespacedDeployment方法便可发送patch请求：
/**
     * 通用patch方法
     * @param patchFormat patch类型，一共有四种
     * @param deploymentName deployment的名称
     * @param namespace namespace名称
     * @param jsonStr patch的json内容
     * @param fieldManager server side apply用到
     * @param force server side apply要设置为true
     * @return patch结果对象转成的字符串
     * @throws Exception
     */
    private String patch(String patchFormat, String deploymentName, String namespace, String jsonStr, String fieldManager, Boolean force) throws Exception {
        // 建立api对象，指定格式是patchFormat
        ApiClient patchClient = ClientBuilder
                .standard()
                .setOverridePatchFormat(patchFormat)
                .build();

        log.info("start deploy : " + patchFormat);

        // 开启debug便于调试，生产环境慎用！！！
        patchClient.setDebugging(true);

        // 建立deployment
        ExtensionsV1beta1Deployment deployment = new ExtensionsV1beta1Api(patchClient)
                .patchNamespacedDeployment(
                        deploymentName,
                        namespace,
                        new V1Patch(jsonStr),
                        null,
                        null,
                        fieldManager,
                        force
                );

        log.info("end deploy : " + patchFormat);

        return new GsonBuilder().setPrettyPrinting().create().toJson(deployment);
    }
  • 上述代码中，有一行代码要格外重视，就是patchClient.setDebugging(true)这段，执行了这一行，在log日志中就会将http的请求和响应所有打印出来，是咱们调试的利器，可是日志内容过多，生产环境请慎用；
  • 上述patch方法有六个入参，其实除了patch类型和patch内容，其余参数均可以固定下来，因而再作个简化版的patch方法：
/**
     * 通用patch方法，fieldManager和force都默认为空
     * @param patchFormat patch类型，一共有四种
     * @param jsonStr patch的json内容
     * @return patch结果对象转成的字符串
     * @throws Exception
     */
    private String patch(String patchFormat, String jsonStr) throws Exception {
        return patch(patchFormat,  DEPLOYMENT_NAME, NAMESPACE, jsonStr, null, null);
    }
  • 入参patchFormat的值是四种patch类型的定义，在V1Patch.java中，其值以下所示：

在这里插入图片描述

  • 接下来能够轻松的开发各类类型patch的代码了；

执行json patch

  1. 首先来看json patch要提交的内容，即json.json文件的内容，这些内容在应用启动时被保存到变量jsonStr，以下所示，很是简单，修改了terminationGracePeriodSeconds属性的值，原来是30，这个属性在中止pod的时候用到，是等待pod的主进程的最长时间：
[
  {
    "op":"replace",
    "path":"/spec/template/spec/terminationGracePeriodSeconds",
    "value":27
  }
]
  1. 接下来就是web接口的代码，可见很是简单，仅需调用前面准备好的patch方法：
/**
     * JSON patch格式的关系
     *
     * @return
     * @throws Exception
     */
    @RequestMapping(value = "/patch/json", method = RequestMethod.GET)
    public String json() throws Exception {
        return patch(V1Patch.PATCH_FORMAT_JSON_PATCH, jsonStr);
    }

merge patch（全量）

  1. 先尝试全量的merge patch，也就是准备好完整的deployment内容，修改其中一部分后进行提交，下图是json文件merge.json的内容，其内容前面的deploy.json相比，仅增长了红框处的内容，即增长了一个label：

在这里插入图片描述

  1. 代码依然很简单：
@RequestMapping(value = "/patch/fullmerge", method = RequestMethod.GET)
    public String fullmerge() throws Exception {
        return patch(V1Patch.PATCH_FORMAT_JSON_MERGE_PATCH, mergeStr);
    }

merge patch（增量）

  1. 前面曾提到merge patch和strategic merge patch的区别：merge patch提交一个container时作的是替换，而strategic merge patch提交一个container时作的是合并，为了展现这两种patch的不一样，这里咱们就用同一个json内容，分别执行merge patch和strategic merge patch，看看结果有什么区别，这是最直观的学习方法；
  2. 这个json对应的文件是strategic.json，内容以下：
{
  "spec":{
    "template":{
      "spec":{
        "containers":[
          {
            "name":"test456",
            "image":"tomcat:7.0.105-jdk8"
          }
        ]
      }
    }
  }
}
  1. 增量merge的代码以下：
@RequestMapping(value = "/patch/partmerge", method = RequestMethod.GET)
    public String partmerge() throws Exception {
        return patch(V1Patch.PATCH_FORMAT_JSON_MERGE_PATCH, strategicStr);
    }

strategic merge patch

  • strategic merge patch用的json内容和前面的增量merge patch是同一个，代码以下：
@RequestMapping(value = "/patch/strategic", method = RequestMethod.GET)
    public String strategic() throws Exception {
        return patch(V1Patch.PATCH_FORMAT_STRATEGIC_MERGE_PATCH, strategicStr);
    }

apply yaml patch

  1. apply yaml patch与其余patch略有不一样，调用ExtensionsV1beta1Api的patchNamespacedDeployment方法发请求时，fieldManager和force字段不能像以前那样为空了：
@RequestMapping(value = "/patch/apply", method = RequestMethod.GET)
    public String apply() throws Exception {
        return patch(V1Patch.PATCH_FORMAT_APPLY_YAML,  DEPLOYMENT_NAME, NAMESPACE, applyYamlStr, "example-field-manager", true);
    }
  1. 上面的代码中，若是force字段不等于true，可能会致使patch失败，在官方文档也有说明，以下图红框：

在这里插入图片描述

  1. apply yaml patch的json字符串来自文件applyYaml.json，其内容是从deploy.json直接复制的，而后改了下图两个红框中的内容，红框1修改了nginx的版本号，用来验证patch是否生效(原有版本是1.18)，红框2是kubernetes1.16以前的一个问题，protocol字段必填，不然会报错，问题详情请参考：https://github.com/kubernetes-sigs/structured-merge-diff/issues/130

在这里插入图片描述

  1. 以上就是全部代码和patch的内容了，接下来部署到kubernetes环境实战吧

制做镜像而且部署

  1. 在patch工程目录下执行如下命令编译构建：
mvn clean package -U -DskipTests
  1. 在patch工程目录下建立Dockerfile文件，内容以下：
# 指定基础镜像，这是分阶段构建的前期阶段
FROM openjdk:8u212-jdk-stretch as builder
# 执行工做目录
WORKDIR application
# 配置参数
ARG JAR_FILE=target/*.jar
# 将编译构建获得的jar文件复制到镜像空间中
COPY ${JAR_FILE} application.jar
# 经过工具spring-boot-jarmode-layertools从application.jar中提取拆分后的构建结果
RUN java -Djarmode=layertools -jar application.jar extract

# 正式构建镜像
FROM openjdk:8u212-jdk-stretch
WORKDIR application
# 前一阶段从jar中提取除了多个文件，这里分别执行COPY命令复制到镜像空间中，每次COPY都是一个layer
COPY --from=builder application/dependencies/ ./
COPY --from=builder application/spring-boot-loader/ ./
COPY --from=builder application/snapshot-dependencies/ ./
COPY --from=builder application/application/ ./
ENTRYPOINT ["java", "org.springframework.boot.loader.JarLauncher"]
  1. 在patch工程目录下执行如下命令建立docker镜像：
docker build -t 192.168.50.43:5888/common/patch:1.0-SNAPSHOT .
  1. 若是您已经配置了docker镜像仓库私服，建议将此镜像推送到私服上去，以便kubernetes上可使用该镜像，我这边的推送命令以下，仅供参考(涉及到身份验证的话还请执行docker login登陆)：
docker push 192.168.50.43:5888/common/patch:1.0-SNAPSHOT
  1. SSH登陆kubernetes环境，新建patch.yaml文件，内容以下，image那里请按您的镜像状况自行调整：
apiVersion: v1
kind: Service
metadata:
  name: patch
  namespace : kubernetesclient
spec:
  type: NodePort
  ports:
    - port: 8080
      nodePort: 30102
  selector:
    name: patch
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  namespace : kubernetesclient
  name: patch
spec:
  replicas: 1
  template:
    metadata:
      labels:
        name: patch
    spec:
      serviceAccountName: kubernates-client-service-account
      containers:
        - name: patch
          image: 192.168.50.43:5888/common/patch:1.0-SNAPSHOT
          tty: true
          livenessProbe:
            httpGet:
              path: /actuator/health/liveness
              port: 8080
            initialDelaySeconds: 5
            failureThreshold: 10
            timeoutSeconds: 10
            periodSeconds: 5
          readinessProbe:
            httpGet:
              path: /actuator/health/readiness
              port: 8080
            initialDelaySeconds: 5
            timeoutSeconds: 10
            periodSeconds: 5
          ports:
            - containerPort: 8080
          resources:
            requests:
              memory: "512Mi"
              cpu: "100m"
            limits:
              memory: "1Gi"
              cpu: "1000m"
  1. 执行如下命令便可完成部署：
kubectl apply -f patch.yaml
  1. 用于验证patch的deployment名为test123(浏览器访问/patch/deploy就会建立)，这个deployment里面是个nginx容器，我们要给它准备一个NodePort类型的service，以便验证的是否能够经过浏览器访问，该service对应的yaml文件是nginx-service.yaml，内容以下：
apiVersion: v1
kind: Service
metadata:
  name: test123
  namespace : default
spec:
  type: NodePort
  ports:
    - port: 80
      nodePort: 30101
  selector:
    run: test123
  1. 执行如下命令便可完成部署：
kubectl apply -f nginx-service.yaml
  1. 终于，部署工做所有完成，能够验证patch了！

验证的步骤

先说一下验证的步骤：github

  1. 调用建立deployment的接口，建立名为test123的deployment，里面是个nginx-1.18版本的pod，能够经过浏览器访问到(前面的nginx-service.yaml已经部署了service)；
  2. 经过web请求执行各类patch操做；

建立deployment

  1. 假设kubernetes宿主机IP地址是192.168.50.135，因此经过浏览器访问：http://192.168.50.135:30102/patch/deploy，便可建立名为test123的deployment，以下图，建立成功后deployment的详细信息会展现在浏览器上：

在这里插入图片描述

  1. 用kubectl命令验证deployment和pod都正常：

在这里插入图片描述

  1. 浏览器访问test123这个deployment里面的nginx容器，地址是http://192.168.50.135:30101/ ，以下图红框所示，返回的header中显示，nginx的版本是1.18.0：

在这里插入图片描述

  1. 接下来开始提交patch；

验证json patch

  1. json patch修改的是原deployment的terminationGracePeriodSeconds属性，因此我们先来看看修改前是啥样的，执行命令kubectl get deployment test123 -o yaml，以下图红框，terminationGracePeriodSeconds等于30：

在这里插入图片描述

  1. 浏览器访问http://192.168.50.135:30102/patch/json，便可发起json patch请求，并将deployment的结果返回，以下图所示，terminationGracePeriodSeconds属性值已经改变：

在这里插入图片描述

  1. 再次用命令kubectl get deployment test123 -o yaml查看，以下图红框，json patch已经生效：

在这里插入图片描述

  1. 执行kubectl logs -f patch-56cd7f7f87-bpl5r -n kubernetesclient能够看到我们应用经过java客户端与kubernetes 的API Server以前的详细日志(patch-56cd7f7f87-bpl5r是patch工程对应的pod)，以下图：

在这里插入图片描述

  1. json patch验证已经完成，接着验证下一个；

验证merge patch（全量）

  1. merge patch（全量）给原有的deployment增长了一个label，先看看执行patch以前是啥样，以下图红框：
    在这里插入图片描述web

  2. 浏览器访问http://192.168.50.135:30102/patch/fullmerge ，就发起了merge请求，操做成功后再次查看，以下图红框，新增了一个label：redis

在这里插入图片描述

验证merge patch（增量）

  1. 浏览器访问http://192.168.50.135:30102/patch/partmerge
  2. 在kubernetes环境查看test123这个deployment的pod，发现原有pod被删除，新增了一个：

在这里插入图片描述

  1. 执行命令kubectl describe pod test123-5ff477967-tv729查看新pod的详情，发现已经部署nginx了，而是patch中提交的tomcat，以下图所示，看来增量merge patch实际上作是替换操做：

在这里插入图片描述

验证strategic merge patch

  1. 此时的test123这个deployment，其pod已经被刚才的merge patch操做改为了tomcat，不适合接下来的验证，所以要执行如下操做进行清理和从新部署：
  1. 上述操做完成后，test123就恢复到最初状态了，在浏览器执行http://192.168.50.135:30102/patch/strategic ，便可提交strategic merge patch
  2. 再去执行kubectl get pod命令查看，会发现pod会被删除，而后建立新pod，这个新pod的容器数量是2，以下图红框：

在这里插入图片描述

  1. 执行命令kubectl describe pod test123-59db4854f5-bstz5查看新pod的详情，下图两个红框，可见原有的strategic merge patch并无替换container，而是新增了一个：

在这里插入图片描述

  1. 此时您应该对merge patch和strategic merge patch的区别应该有了清晰的认识；

开启kubernetes的Server-side Apply(低于1.16版本才须要执行)

  1. 最后一个实战是apply yaml patch，此类型patch主要是用于Server-side Apply特性的，
  2. 该特性自kubernetes的1.14版本就有了，可是默认并未开启，直到1.16版本才默认开启，所以，若是您的kubernetes低于1.16版本，须要开启这个特性；
  3. java客户端的官方demo代码中，有一些简单描述，以下图红框：

在这里插入图片描述

  1. kubernetes的官方文档中，提到此特性在低版本能够经过开关来开启，文档地址：https://kubernetes.cn/docs/reference/command-line-tools-reference/feature-gates/
    在这里插入图片描述spring

  2. 我这里kubernetes版本是1.14，所以须要手动开启Server-side Apply，首先SSH登陆kubernetes环境；

  3. 打开文件/etc/kubernetes/manifests/kube-apiserver.yaml ，给spec.containers.command增长一个参数--feature-gates=ServerSideApply=true，以下图红框所示：

在这里插入图片描述

  1. 修改完毕后请保存，因为kubernetes一直在监听此文件，所以会当即自动生效；

验证apply yaml patch

  1. 此时的test123，因为刚刚验证过strategic merge patch，如今的pod里面有nginx和tomcat两个container；
  2. 浏览器访问http://192.168.50.135:30102/patch/apply
  3. 此时pod会重建，以下图，可见最终container仍是两个，也就是说，尽管applyYaml.json中的container只有一个nginx，但因为是在服务端merge的，服务端只会升级nginx的版本，对于已有的tomcat这个container依旧会保留：

在这里插入图片描述
4. 用浏览器访问test123提供的nginx服务，以下图红框所示，nginx版本已经升级，证实本次patch已经生效：

在这里插入图片描述

至此，经过kubernetes的java客户端执行patch操做的实战就所有完成了，从理论到环境准备，再到实际操做，涉及到太多内容，感谢您的耐心，但愿本文能助您用好java客户端这个利器，更高效的操做kubernetes环境；

你不孤单，欣宸原创一路相伴

  1. Java系列
  2. Spring系列
  3. Docker系列
  4. kubernetes系列
  5. 数据库+中间件系列
  6. DevOps系列

欢迎关注公众号：程序员欣宸

微信搜索「程序员欣宸」，我是欣宸，期待与您一同畅游Java世界...
https://github.com/zq2599/blog_demos

相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程