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

2021-01-13 本文已影响0人程序员欣宸

欢迎访问我的GitHub

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

概览

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

本文内容

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

在这里插入图片描述

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

关于patch

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

patch的四种类型

kubernetes的patch一共有四种：

json patch：在请求中指定操作类型，例如：add、replace，再指定json内容进行操作z，请参考：https://tools.ietf.org/html/rfc6902
merge patch：合并操作，可以提交整个资源的信息，与现有信息进行合并后生效，也可以提交部分信息用于替换，请参考：https://tools.ietf.org/html/rfc7386
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)：

在这里插入图片描述

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

在这里插入图片描述

第四种是apply patch：主要是指kubernetes 1.14版本开始的server-side apply，由APIServer 做 diff 和 merge 操作，很多原本易碎的现象都得到了解决(例如controller和kubectl都在更新)，另外要格外注意的是：1.14版本默认是不开启server-side apply特性的，具体的开启操作在下面会详细讲解；

以上是对kubernetes四种patch的简介，讲得很浅，如果您想深入了解每种patch，建议参阅官方资料，接下来咱们聚焦java客户端对这些patch能力的实现；

源码下载

如果您不想编码，可以在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协议

这个git项目中有多个文件夹，本章的应用在kubernetesclient文件夹下，如下图红框所示：

在这里插入图片描述

实战步骤概述

接下来会创建一个springboot工程(该工程是kubernetesclient的子工程)，针对四种patch咱们都有对应的操作；
每种patch都会准备对应的json文件，提前将这些文件的内容保存在字符串变量中，在程序里用kubernetes客户端的patch专用API，将此json字符串发送出去，流程简图如下：

在这里插入图片描述
编码完成后，就来动手验证功能，具体操作如下：

部署名为patch的deployment，这里面是咱们编码的SpringBoot工程，提供多个web接口；
浏览器访问/patch/deploy接口，就会创建名为test123的deployment，这个deployment里面是个nginx，接下来的patch操作都是针对这个名为test123的deployment；
浏览器访问test123的nginx服务，确保部署成功了；
浏览器访问/patch/json接口，该接口会修改test123的一个属性：terminationGracePeriodSeconds
浏览器访问/patch/fullmerge接口，该接口会提交全量merge请求，修改内容很少，仅增加了一个label属性；
接下来是对比merge patch和strategic merge patch区别，分别访问/patch/partmerge和/patch/strategic这两个接口，其实它们操作的是同一段patch内容(一个新的container)，结果merge patch会替换原有的continer，而strategic merge patch不会动原有的container，而是新增container，导致test123这个deployment下面的pod从一个变为两个；
最后是apply yaml patch，访问接口/patch/apply，会将nginx容器的标签从1.18.0改为1.19.1，咱们只要在浏览器访问test123里面的nginx服务就能确定是否修改生效了；

准备工作

准备工作包括创建工程、编写辅助功能代码、初始化代码等：

打开《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>

编写一个辅助类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;
    }
}

接下来新建本篇文章的核心类PatchExample.java，首先这个类中有main方法，整个应用从这里启动：

public static void main(String[] args) {
        SpringApplication.run(PatchExample.class, args);
    }

接下来有两个常量定义，分别是kubernetes环境里用来测试的deployment名称，以及namespace名称：

static String DEPLOYMENT_NAME = "test123";

static String NAMESPACE = "default";

然后定义几个字符串变量，执行patch操作时用到的json内容都保存到这些字符串变量中：

static String deployStr, jsonStr, mergeStr, strategicStr, applyYamlStr;

在resources文件夹中放入json文件，稍后的初始化代码会将这些文件读取到字符串变量中，如下图，这些json文件的内容稍后会详细说明：

在这里插入图片描述

编写初始化代码(通过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();
    }

以上就是准备工作；

创建服务

首先要开发一个部署的接口，通过调用此接口可以在kubernetes环境部署一个deployment：
部署服务的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);
    }

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":{

  }
}

如此一来，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

首先来看json patch要提交的内容，即json.json文件的内容，这些内容在应用启动时被保存到变量jsonStr，如下所示，非常简单，修改了terminationGracePeriodSeconds属性的值，原来是30，这个属性在停止pod的时候用到，是等待pod的主进程的最长时间：

[
  {
    "op":"replace",
    "path":"/spec/template/spec/terminationGracePeriodSeconds",
    "value":27
  }
]

接下来就是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（全量）

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

在这里插入图片描述

代码依然很简单：

@RequestMapping(value = "/patch/fullmerge", method = RequestMethod.GET)
    public String fullmerge() throws Exception {
        return patch(V1Patch.PATCH_FORMAT_JSON_MERGE_PATCH, mergeStr);
    }

merge patch（增量）

前面曾提到merge patch和strategic merge patch的区别：merge patch提交一个container时做的是替换，而strategic merge patch提交一个container时做的是合并，为了展示这两种patch的不同，这里我们就用同一个json内容，分别执行merge patch和strategic merge patch，看看结果有什么区别，这是最直观的学习方法；
这个json对应的文件是strategic.json，内容如下：

{
  "spec":{
    "template":{
      "spec":{
        "containers":[
          {
            "name":"test456",
            "image":"tomcat:7.0.105-jdk8"
          }
        ]
      }
    }
  }
}

增量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

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);
    }

上面的代码中，如果force字段不等于true，可能会导致patch失败，在官方文档也有说明，如下图红框：

在这里插入图片描述

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

在这里插入图片描述

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

制作镜像并且部署

在patch工程目录下执行以下命令编译构建：

mvn clean package -U -DskipTests

在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"]

在patch工程目录下执行以下命令创建docker镜像：

docker build -t 192.168.50.43:5888/common/patch:1.0-SNAPSHOT .

如果您已经配置了docker镜像仓库私服，建议将此镜像推送到私服上去，以便kubernetes上可以使用该镜像，我这边的推送命令如下，仅供参考(涉及到身份验证的话还请执行docker login登录)：

docker push 192.168.50.43:5888/common/patch:1.0-SNAPSHOT

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"

执行以下命令即可完成部署：

kubectl apply -f patch.yaml

用于验证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

执行以下命令即可完成部署：

kubectl apply -f nginx-service.yaml

终于，部署工作全部完成，可以验证patch了！

验证的步骤

先说一下验证的步骤：

调用创建deployment的接口，创建名为test123的deployment，里面是个nginx-1.18版本的pod，可以通过浏览器访问到(前面的nginx-service.yaml已经部署了service)；
通过web请求执行各种patch操作；

创建deployment

假设kubernetes宿主机IP地址是192.168.50.135，所以通过浏览器访问：http://192.168.50.135:30102/patch/deploy，即可创建名为test123的deployment，如下图，创建成功后deployment的详细信息会展示在浏览器上：

在这里插入图片描述

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

在这里插入图片描述

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

在这里插入图片描述

接下来开始提交patch；

验证json patch

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

在这里插入图片描述

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

在这里插入图片描述

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

在这里插入图片描述

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

在这里插入图片描述

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

验证merge patch（全量）

merge patch（全量）给原有的deployment增加了一个label，先看看执行patch之前是啥样，如下图红框：

在这里插入图片描述
浏览器访问http://192.168.50.135:30102/patch/fullmerge ，就发起了merge请求，操作成功后再次查看，如下图红框，新增了一个label：

在这里插入图片描述

验证merge patch（增量）

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

在这里插入图片描述

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

在这里插入图片描述

验证strategic merge patch

此时的test123这个deployment，其pod已经被刚才的merge patch操作改成了tomcat，不适合接下来的验证，因此要执行以下操作进行清理和重新部署：

删除test123这个deployment：kubectl delete deployment test123
浏览器访问：http://192.168.50.135:30102/patch/deploy ，就会重新部署test123

上述操作完成后，test123就恢复到最初状态了，在浏览器执行http://192.168.50.135:30102/patch/strategic ，即可提交strategic merge patch
再去执行kubectl get pod命令查看，会发现pod会被删除，然后创建新pod，这个新pod的容器数量是2，如下图红框：

在这里插入图片描述

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

在这里插入图片描述

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

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

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

在这里插入图片描述

kubernetes的官方文档中，提到此特性在低版本可以通过开关来开启，文档地址：https://kubernetes.cn/docs/reference/command-line-tools-reference/feature-gates/

在这里插入图片描述
我这里kubernetes版本是1.14，因此需要手动开启Server-side Apply，首先SSH登录kubernetes环境；
打开文件/etc/kubernetes/manifests/kube-apiserver.yaml ，给spec.containers.command增加一个参数--feature-gates=ServerSideApply=true，如下图红框所示：

在这里插入图片描述

修改完毕后请保存，由于kubernetes一直在监听此文件，因此会立即自动生效；

验证apply yaml patch

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

在这里插入图片描述

用浏览器访问test123提供的nginx服务，如下图红框所示，nginx版本已经升级，证明本次patch已经生效：

在这里插入图片描述

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

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

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

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

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

欢迎访问我的GitHub

概览

本文内容

关于patch

patch的四种类型

源码下载

实战步骤概述

准备工作

创建服务

发起patch请求的通用方法

执行json patch

merge patch（全量）

merge patch（增量）

strategic merge patch

apply yaml patch

制作镜像并且部署

验证的步骤

创建deployment

验证json patch

验证merge patch（全量）

验证merge patch（增量）

验证strategic merge patch

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

验证apply yaml patch

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

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

猜你喜欢

热点阅读