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

ゝ一纸荒年。 2022-11-25 11:52 199阅读 0赞

### 欢迎访问我的GitHub ###

[https://github.com/zq2599/blog\_demos][https_github.com_zq2599_blog_demos]  
内容：所有原创文章分类汇总及配套源码，涉及Java、Docker、Kubernetes、DevOPS等；

### 概览 ###

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操作，如下图：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2JvbGluZ19jYXZhbHJ5_size_16_color_FFFFFF_t_70]  
接下来先了解一些kubernetes的patch相关的基本知识；

### 关于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/  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2JvbGluZ19jYXZhbHJ5_size_16_color_FFFFFF_t_70 1]

### patch的四种类型 ###

kubernetes的patch一共有四种：

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)：  
    ![在这里插入图片描述][20200808211439809.png]
4.  通过源码查看资源的patchStrategy属性是很麻烦的事情，因此也可以通过Kubernetes API 文档来查看，如下图，地址是：https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.18/\#podspec-v1-core  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2JvbGluZ19jYXZhbHJ5_size_16_color_FFFFFF_t_70 2]
5.  第四种是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)：

<table> 
 <thead> 
  <tr> 
   <th align="left">名称</th> 
   <th align="left">链接</th> 
   <th align="left">备注</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td align="left">项目主页</td> 
   <td align="left">https://github.com/zq2599/blog_demos</td> 
   <td align="left">该项目在GitHub上的主页</td> 
  </tr> 
  <tr> 
   <td align="left">git仓库地址(https)</td> 
   <td align="left">https://github.com/zq2599/blog_demos.git</td> 
   <td align="left">该项目源码的仓库地址，https协议</td> 
  </tr> 
  <tr> 
   <td align="left">git仓库地址(ssh)</td> 
   <td align="left">git@github.com:zq2599/blog_demos.git</td> 
   <td align="left">该项目源码的仓库地址，ssh协议</td> 
  </tr> 
 </tbody> 
</table>

1.  这个git项目中有多个文件夹，本章的应用在kubernetesclient文件夹下，如下图红框所示：  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2JvbGluZ19jYXZhbHJ5_size_16_color_FFFFFF_t_70 3]

### 实战步骤概述 ###

*  接下来会创建一个springboot工程(该工程是kubernetesclient的子工程)，针对四种patch咱们都有对应的操作；
 *  每种patch都会准备对应的json文件，提前将这些文件的内容保存在字符串变量中，在程序里用kubernetes客户端的patch专用API，将此json字符串发送出去，流程简图如下：  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2JvbGluZ19jYXZhbHJ5_size_16_color_FFFFFF_t_70 4]
 *  编码完成后，就来动手验证功能，具体操作如下：

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客户端之一：准备 》][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>
                    
                    <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文件的内容稍后会详细说明：  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2JvbGluZ19jYXZhbHJ5_size_16_color_FFFFFF_t_70 5]
2.  编写初始化代码(通过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请求：

*  上述代码中，有一行代码要格外重视，就是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中，其值如下所示：  
    ![在这里插入图片描述][20200808214027949.png]
 *  接下来可以轻松的开发各种类型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：  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2JvbGluZ19jYXZhbHJ5_size_16_color_FFFFFF_t_70 6]
2.  代码依然很简单：

@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失败，在官方文档也有说明，如下图红框：  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2JvbGluZ19jYXZhbHJ5_size_16_color_FFFFFF_t_70 7]
2.  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  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2JvbGluZ19jYXZhbHJ5_size_16_color_FFFFFF_t_70 8]
3.  以上就是所有代码和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了！

### 验证的步骤 ###

先说一下验证的步骤：

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的详细信息会展示在浏览器上：  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2JvbGluZ19jYXZhbHJ5_size_16_color_FFFFFF_t_70 9]
2.  用kubectl命令验证deployment和pod都正常：  
    ![在这里插入图片描述][2020080821531542.png]
3.  浏览器访问test123这个deployment里面的nginx容器，地址是http://192.168.50.135:30101/ ，如下图红框所示，返回的header中显示，nginx的版本是1.18.0：  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2JvbGluZ19jYXZhbHJ5_size_16_color_FFFFFF_t_70 10]
4.  接下来开始提交patch；

### 验证json patch ###

1.  json patch修改的是原deployment的terminationGracePeriodSeconds属性，所以咱们先来看看修改前是啥样的，执行命令kubectl get deployment test123 -o yaml，如下图红框，terminationGracePeriodSeconds等于30：  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2JvbGluZ19jYXZhbHJ5_size_16_color_FFFFFF_t_70 11]
2.  浏览器访问http://192.168.50.135:30102/patch/json，即可发起json patch请求，并将deployment的结果返回，如下图所示，terminationGracePeriodSeconds属性值已经改变：  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2JvbGluZ19jYXZhbHJ5_size_16_color_FFFFFF_t_70 12]
3.  再次用命令kubectl get deployment test123 -o yaml查看，如下图红框，json patch已经生效：  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2JvbGluZ19jYXZhbHJ5_size_16_color_FFFFFF_t_70 13]
4.  执行kubectl logs -f patch-56cd7f7f87-bpl5r -n kubernetesclient可以看到咱们应用通过java客户端与kubernetes 的API Server之前的详细日志(patch-56cd7f7f87-bpl5r是patch工程对应的pod)，如下图：  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2JvbGluZ19jYXZhbHJ5_size_16_color_FFFFFF_t_70 14]
5.  json patch验证已经完成，接着验证下一个；

### 验证merge patch（全量） ###

1.  merge patch（全量）给原有的deployment增加了一个label，先看看执行patch之前是啥样，如下图红框：  
    ![在这里插入图片描述][2020080821554543.png]
2.  浏览器访问http://192.168.50.135:30102/patch/fullmerge ，就发起了merge请求，操作成功后再次查看，如下图红框，新增了一个label：  
    ![在这里插入图片描述][20200808215553687.png]

### 验证merge patch（增量） ###

1.  浏览器访问http://192.168.50.135:30102/patch/partmerge
2.  在kubernetes环境查看test123这个deployment的pod，发现原有pod被删除，新增了一个：  
    ![在这里插入图片描述][20200808215622442.png]
3.  执行命令kubectl describe pod test123-5ff477967-tv729查看新pod的详情，发现已经部署nginx了，而是patch中提交的tomcat，如下图所示，看来增量merge patch实际上做是替换操作：  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2JvbGluZ19jYXZhbHJ5_size_16_color_FFFFFF_t_70 15]

### 验证strategic merge patch ###

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

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

1.  上述操作完成后，test123就恢复到最初状态了，在浏览器执行http://192.168.50.135:30102/patch/strategic ，即可提交strategic merge patch
2.  再去执行kubectl get pod命令查看，会发现pod会被删除，然后创建新pod，这个新pod的容器数量是2，如下图红框：  
    ![在这里插入图片描述][20200808215822710.png]
3.  执行命令kubectl describe pod test123-59db4854f5-bstz5查看新pod的详情，下图两个红框，可见原有的strategic merge patch并没有替换container，而是新增了一个：  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2JvbGluZ19jYXZhbHJ5_size_16_color_FFFFFF_t_70 16]
4.  此时您应该对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代码中，有一些简单描述，如下图红框：  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2JvbGluZ19jYXZhbHJ5_size_16_color_FFFFFF_t_70 17]
4.  kubernetes的官方文档中，提到此特性在低版本可以通过开关来开启，文档地址：https://kubernetes.cn/docs/reference/command-line-tools-reference/feature-gates/  
    ![在这里插入图片描述][20200808215931237.png]
5.  我这里kubernetes版本是1.14，因此需要手动开启Server-side Apply，首先SSH登录kubernetes环境；
6.  打开文件/etc/kubernetes/manifests/kube-apiserver.yaml ，给spec.containers.command增加一个参数–feature-gates=ServerSideApply=true，如下图红框所示：  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2JvbGluZ19jYXZhbHJ5_size_16_color_FFFFFF_t_70 18]
7.  修改完毕后请保存，由于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依旧会保留：  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2JvbGluZ19jYXZhbHJ5_size_16_color_FFFFFF_t_70 19]
4.  用浏览器访问test123提供的nginx服务，如下图红框所示，nginx版本已经升级，证明本次patch已经生效：  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2JvbGluZ19jYXZhbHJ5_size_16_color_FFFFFF_t_70 20]

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

[https_github.com_zq2599_blog_demos]: https://github.com/zq2599/blog_demos
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2JvbGluZ19jYXZhbHJ5_size_16_color_FFFFFF_t_70]: /images/20221124/2f3858f0af2f4cc8a41678e6f4fad6e9.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2JvbGluZ19jYXZhbHJ5_size_16_color_FFFFFF_t_70 1]: /images/20221124/2194d99e92a74f1aa635668c18651a18.png
[20200808211439809.png]: /images/20221124/a6a662eb320442ddbd72e5a8b47d145b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2JvbGluZ19jYXZhbHJ5_size_16_color_FFFFFF_t_70 2]: /images/20221124/df3817a0a2f643119da6c6a055659ccc.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2JvbGluZ19jYXZhbHJ5_size_16_color_FFFFFF_t_70 3]: /images/20221124/fc2f32ce52d746ef9f6a69f593e70bef.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2JvbGluZ19jYXZhbHJ5_size_16_color_FFFFFF_t_70 4]: /images/20221124/e844e45def704ae3812ad098c6dd5625.png
[Kubernetes_java_]: https://xinchen.blog.csdn.net/article/details/107480015
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2JvbGluZ19jYXZhbHJ5_size_16_color_FFFFFF_t_70 5]: /images/20221124/cd1f9a6c189f46c795e55739331bedfc.png
[20200808214027949.png]: /images/20221124/4f48d134542444819fc4e3c806b772c1.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2JvbGluZ19jYXZhbHJ5_size_16_color_FFFFFF_t_70 6]: /images/20221124/22c99f2b968541b08094db2d7a35bcc6.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2JvbGluZ19jYXZhbHJ5_size_16_color_FFFFFF_t_70 7]: /images/20221124/b732d8d5048c4e759933b383a1c20f97.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2JvbGluZ19jYXZhbHJ5_size_16_color_FFFFFF_t_70 8]: /images/20221124/ae3f2f1d373c4a72879ac1223d4dc405.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2JvbGluZ19jYXZhbHJ5_size_16_color_FFFFFF_t_70 9]: /images/20221124/df56cecae6714f808e3591300d13af7f.png
[2020080821531542.png]: /images/20221124/4780e8a1cf134b0ea7c56722138fbd36.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2JvbGluZ19jYXZhbHJ5_size_16_color_FFFFFF_t_70 10]: /images/20221124/34d1ae9859424d8c9014bd165af1503a.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2JvbGluZ19jYXZhbHJ5_size_16_color_FFFFFF_t_70 11]: /images/20221124/8ba84a6da9a7400f88f4c583a577b982.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2JvbGluZ19jYXZhbHJ5_size_16_color_FFFFFF_t_70 12]: /images/20221124/8e4e965061cd46e2955c3be7a98feb00.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2JvbGluZ19jYXZhbHJ5_size_16_color_FFFFFF_t_70 13]: /images/20221124/6c2e63ed5f1e43c99a3dee5d5d10f84b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2JvbGluZ19jYXZhbHJ5_size_16_color_FFFFFF_t_70 14]: /images/20221124/5c6b5e9c369f4691b5e76c68f23d69d2.png
[2020080821554543.png]: /images/20221124/7cd91daff80746b7bb38505fca69aecd.png
[20200808215553687.png]: /images/20221124/f70e56935184474cae0133b42a0e3633.png
[20200808215622442.png]: /images/20221124/05562f7c77774bb8b0849e22a157d6e3.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2JvbGluZ19jYXZhbHJ5_size_16_color_FFFFFF_t_70 15]: /images/20221124/612a8887c42d40f9919ffd798419a6ed.png
[20200808215822710.png]: /images/20221124/ae3ce6a0ccd24c85a7eab0e6037ab96c.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2JvbGluZ19jYXZhbHJ5_size_16_color_FFFFFF_t_70 16]: /images/20221124/d2ed0665a2c840b2a61a55bb2e6b3afa.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2JvbGluZ19jYXZhbHJ5_size_16_color_FFFFFF_t_70 17]: /images/20221124/0c549aca1d6443ea9c7a07c4aab75e06.png
[20200808215931237.png]: /images/20221124/08d4f5b4e1434e35b24149d75de3e448.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2JvbGluZ19jYXZhbHJ5_size_16_color_FFFFFF_t_70 18]: /images/20221124/016d642de5ac4e8e8c1a7ef36d1b2a37.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2JvbGluZ19jYXZhbHJ5_size_16_color_FFFFFF_t_70 19]: /images/20221124/a8bd25dab3a94c84bee766acb293952d.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2JvbGluZ19jYXZhbHJ5_size_16_color_FFFFFF_t_70 20]: /images/20221124/9ec4a3c7e45e4689a651e6ae06b6a996.png