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

Posted 2022-01-19 程序员欣宸

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了Kubernetes官方java客户端之七：patch操作相关的知识，希望对你有一定的参考价值。

欢迎访问我的GitHub

https://github.com/zq2599/blog_demos
内容：所有原创文章分类汇总及配套源码，涉及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>


2. 编写一个辅助类==ClassPathResourceReader.java==，作用是读取json文件的内容作为字符串返回：
```java
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";


5. 然后定义几个字符串变量，执行patch操作时用到的json内容都保存到这些字符串变量中：
```shell
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
1. 首先来看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"]


3. 在patch工程目录下执行以下命令创建docker镜像：
```shell
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已经生效：