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)	[email protected]: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 = "https://www.cnblogs.com/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 = "https://www.cnblogs.com/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 = "https://www.cnblogs.com/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 = "https://www.cnblogs.com/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 = "https://www.cnblogs.com/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依舊會保留：

在這里插入圖片描述
4. 用瀏覽器訪問test123提供的nginx服務，如下圖紅框所示，nginx版本已經升級，證明本次patch已經生效：

在這里插入圖片描述

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

你不孤單，欣宸原創一路相伴

Java系列
Spring系列
Docker系列
kubernetes系列
資料庫+中間件系列
DevOps系列

歡迎關注公眾號：程式員欣宸

微信搜索「程式員欣宸」，我是欣宸，期待與您一同暢游Java世界...
https://github.com/zq2599/blog_demos

轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/248039.html

標籤：Java

上一篇：Sorry！Hbase的LSM Tree就是可以為所欲為！

下一篇：Kubernetes官方java客戶端之七：patch操作