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

概覽

本文是《Kubernetes官方java客戶端》系列的第七篇，如下提到的java客戶端都是指client-jar.jar；
本文主要內容是經過java客戶端發起patch請求，用來修改已有資源;
接下來會對kubernetes的patch作一些介紹，因爲我們這裏的重點仍是java客戶端的patch操做，所以不會對patch的原理和概念展開太多，僅作最基本的說明能便可；

本文內容

這是篇萬字長文，因此一開始就要明確本文的核心內容：開發一個SpringBoot應用並部署在kubernetes環境，這個應用經過kubernetes的java客戶端向API Server發請求，請求內容包括：建立名爲test123的deployment、對這個deployment進行patch操做，以下圖：node

接下來先了解一些kubernetes的patch相關的基本知識；nginx

關於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一共有四種：git

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了！

驗證的步驟

先說一下驗證的步驟：github

調用建立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以前是啥樣，以下圖紅框：
web
瀏覽器訪問http://192.168.50.135:30102/patch/fullmerge ，就發起了merge請求，操做成功後再次查看，以下圖紅框，新增了一個label：redis

驗證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/
spring
我這裏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依舊會保留：

4. 用瀏覽器訪問test123提供的nginx服務，以下圖紅框所示，nginx版本已經升級，證實本次patch已經生效：

至此，經過kubernetes的java客戶端執行patch操做的實戰就所有完成了，從理論到環境準備，再到實際操做，涉及到太多內容，感謝您的耐心，但願本文能助您用好java客戶端這個利器，更高效的操做kubernetes環境；