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

程式設計師欣宸發表於2021-01-13

歡迎訪問我的GitHub

內容：所有原創文章分類彙總及配套原始碼，涉及Java、Docker、Kubernetes、DevOPS等；

概覽

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

本文內容

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

在這裡插入圖片描述

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

關於patch

是對各種資源的增刪改查是kubernetes的基本操作；
對於修改操作，分為Replace和Patch兩種；
Replace好理解，就是用指定資源替換現有資源，replace有個特點，就是optimistic lock約束（類似與轉賬操作，先讀再計算再寫入）；
Patch用來對資源做區域性更新，沒有optimistic lock約束，總是最後的請求會生效，因此如果您只打算修改區域性資訊，例如某個屬性，只要指定屬性去做patch即可（如果用Replace，就只能先取得整個資源，在本地修改指定屬性，再用Replace整體替換）；
更詳細的資訊請參考下圖，來自官方文件，地址：https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.18/

patch的四種型別

kubernetes的patch一共有四種：

json patch：在請求中指定操作型別，例如：add、replace，再指定json內容進行操作z，請參考：https://tools.ietf.org/html/rfc6902
merge patch：合併操作，可以提交整個資源的資訊，與現有資訊進行合併後生效，也可以提交部分資訊用於替換，請參考：https://tools.ietf.org/html/rfc7386
strategic merge patch：json patch和merge patch都遵守rfc標準，但是strategic merge patch卻是kubernetes獨有的，官方中文文件中稱為策略性合併，也是merge的一種，但是真正執行時kubernetes會做合併還是替換是和具體的資源定義相關的（具體策略由 Kubernetes 原始碼中欄位標記中的 patchStrategy 鍵的值指定），以Pod的Container為例，下面是其原始碼，紅框中顯示其Container節點的patchStrategy屬性是merge，也就是說如果您提交了一份strategic merge patch，裡面的內容是關於Pod的Container的，那麼原有的Container不會被替換，而是合併(例如以前只有nginx，提交的strategic merge patch是redis，那麼最終pod下會有兩個container：nginx和redis)：

在這裡插入圖片描述

通過原始碼檢視資源的patchStrategy屬性是很麻煩的事情，因此也可以通過Kubernetes API 文件來檢視，如下圖，地址是：https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.18/#podspec-v1-core

在這裡插入圖片描述

第四種是apply patch：主要是指kubernetes 1.14版本開始的server-side apply，由APIServer 做 diff 和 merge 操作，很多原本易碎的現象都得到了解決(例如controller和kubectl都在更新)，另外要格外注意的是：1.14版本預設是不開啟server-side apply特性的，具體的開啟操作在下面會詳細講解；

以上是對kubernetes四種patch的簡介，講得很淺，如果您想深入瞭解每種patch，建議參閱官方資料，接下來我們們聚焦java客戶端對這些patch能力的實現；

原始碼下載

如果您不想編碼，可以在GitHub下載所有原始碼，地址和連結資訊如下表所示(https://github.com/zq2599/blog_demos)：

名稱	連結	備註
專案主頁	https://github.com/zq2599/blog_demos	該專案在GitHub上的主頁
git倉庫地址(https)	https://github.com/zq2599/blog_demos.git	該專案原始碼的倉庫地址，https協議
git倉庫地址(ssh)	git@github.com:zq2599/blog_demos.git	該專案原始碼的倉庫地址，ssh協議

這個git專案中有多個資料夾，本章的應用在kubernetesclient資料夾下，如下圖紅框所示：

在這裡插入圖片描述

實戰步驟概述

接下來會建立一個springboot工程(該工程是kubernetesclient的子工程)，針對四種patch我們們都有對應的操作；
每種patch都會準備對應的json檔案，提前將這些檔案的內容儲存在字串變數中，在程式裡用kubernetes客戶端的patch專用API，將此json字串傳送出去，流程簡圖如下：
編碼完成後，就來動手驗證功能，具體操作如下：

部署名為patch的deployment，這裡面是我們們編碼的SpringBoot工程，提供多個web介面；
瀏覽器訪問/patch/deploy介面，就會建立名為test123的deployment，這個deployment裡面是個nginx，接下來的patch操作都是針對這個名為test123的deployment；
瀏覽器訪問test123的nginx服務，確保部署成功了；
瀏覽器訪問/patch/json介面，該介面會修改test123的一個屬性：terminationGracePeriodSeconds
瀏覽器訪問/patch/fullmerge介面，該介面會提交全量merge請求，修改內容很少，僅增加了一個label屬性；
接下來是對比merge patch和strategic merge patch區別，分別訪問/patch/partmerge和/patch/strategic這兩個介面，其實它們操作的是同一段patch內容(一個新的container)，結果merge patch會替換原有的continer，而strategic merge patch不會動原有的container，而是新增container，導致test123這個deployment下面的pod從一個變為兩個；
最後是apply yaml patch，訪問介面/patch/apply，會將nginx容器的標籤從1.18.0改為1.19.1，我們們只要在瀏覽器訪問test123裡面的nginx服務就能確定是否修改生效了；

準備工作

準備工作包括建立工程、編寫輔助功能程式碼、初始化程式碼等：

開啟《Kubernetes官方java客戶端之一：準備》一文建立的專案kubernetesclient，新增名為patch的子工程，pom.xml內容如下：

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <parent>
        <groupId>com.bolingcavalry</groupId>
        <artifactId>kubernetesclient</artifactId>
        <version>1.0-SNAPSHOT</version>
        <relativePath>../pom.xml</relativePath>
    </parent>

    <groupId>com.bolingcavalry</groupId>
    <artifactId>patch</artifactId>
    <version>0.0.1-SNAPSHOT</version>
    <name>patch</name>
    <description>patch demo</description>
    <packaging>jar</packaging>

    <dependencies>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-web</artifactId>
            <exclusions>
                <exclusion>
                    <groupId>org.springframework.boot</groupId>
                    <artifactId>spring-boot-starter-json</artifactId>
                </exclusion>
            </exclusions>
        </dependency>

        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-actuator</artifactId>
        </dependency>

        <dependency>
            <groupId>org.projectlombok</groupId>
            <artifactId>lombok</artifactId>
            <optional>true</optional>
        </dependency>

        <dependency>
            <groupId>io.kubernetes</groupId>
            <artifactId>client-java</artifactId>
        </dependency>
    </dependencies>

    <build>
        <plugins>
            <plugin>
                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-maven-plugin</artifactId>
                <version>2.3.0.RELEASE</version>
                <!--該配置會在jar中增加layer描述檔案，以及提取layer的工具-->
                <configuration>
                    <layers>
                        <enabled>true</enabled>
                    </layers>
                </configuration>
            </plugin>
        </plugins>
    </build>

</project>

編寫一個輔助類ClassPathResourceReader.java，作用是讀取json檔案的內容作為字串返回：

package com.bolingcavalry.patch;

import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
import java.util.stream.Collectors;
import org.springframework.core.io.ClassPathResource;

public class ClassPathResourceReader {

    private final String path;

    private String content;

    public ClassPathResourceReader(String path) {
        this.path = path;
    }

    public String getContent() {
        if (content == null) {
            try {
                ClassPathResource resource = new ClassPathResource(path);
                BufferedReader reader = new BufferedReader(new InputStreamReader(resource.getInputStream()));
                content = reader.lines().collect(Collectors.joining("\n"));
                reader.close();
            } catch (IOException ex) {
                throw new RuntimeException(ex);
            }
        }
        return content;
    }
}

接下來新建本篇文章的核心類PatchExample.java，首先這個類中有main方法，整個應用從這裡啟動：

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

接下來有兩個常量定義，分別是kubernetes環境裡用來測試的deployment名稱，以及namespace名稱：

static String DEPLOYMENT_NAME = "test123";

static String NAMESPACE = "default";

然後定義幾個字串變數，執行patch操作時用到的json內容都儲存到這些字串變數中：

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

在resources資料夾中放入json檔案，稍後的初始化程式碼會將這些檔案讀取到字串變數中，如下圖，這些json檔案的內容稍後會詳細說明：

在這裡插入圖片描述

編寫初始化程式碼(通過PostConstruct註解實現)，主要是客戶端配置，還有將json檔案的內容讀出來，儲存到剛剛準備的字串變數中：

@PostConstruct
    private void init() throws IOException {
        // 設定api配置
        ApiClient client = Config.defaultClient();
        Configuration.setDefaultApiClient(client);
        // 設定超時時間
        Configuration.getDefaultApiClient().setConnectTimeout(30000);

        // 部署用的JSON字串
        deployStr = new ClassPathResourceReader("deploy.json").getContent();

        // json patch用的JSON字串
        jsonStr = new ClassPathResourceReader("json.json").getContent();

        // merge patch用的JSON字串，和部署的JSON相比：replicas從1變成2，增加一個名為from的label，值為merge
        mergeStr = new ClassPathResourceReader("merge.json").getContent();

        // strategic merge patch用的JSON字串
        strategicStr = new ClassPathResourceReader("strategic.json").getContent();

        // server side apply用的JSON字串
        applyYamlStr = new ClassPathResourceReader("applyYaml.json").getContent();
    }

以上就是準備工作；

建立服務

首先要開發一個部署的介面，通過呼叫此介面可以在kubernetes環境部署一個deployment：
部署服務的path是/patch/deploy，程式碼如下，可見部署deployment的程式碼分為三步：建立api例項、用字串建立body例項、把body傳給api即可：

/**
     * 通用patch方法
     * @param patchFormat patch型別，一共有四種
     * @param deploymentName deployment的名稱
     * @param namespace namespace名稱
     * @param jsonStr patch的json內容
     * @param fieldManager server side apply用到
     * @param force server side apply要設定為true
     * @return patch結果物件轉成的字串
     * @throws Exception
     */
    private String patch(String patchFormat, String deploymentName, String namespace, String jsonStr, String fieldManager, Boolean force) throws Exception {
        // 建立api物件，指定格式是patchFormat
        ApiClient patchClient = ClientBuilder
                .standard()
                .setOverridePatchFormat(patchFormat)
                .build();

        log.info("start deploy : " + patchFormat);

        // 開啟debug便於除錯，生產環境慎用！！！
        patchClient.setDebugging(true);

        // 建立deployment
        ExtensionsV1beta1Deployment deployment = new ExtensionsV1beta1Api(patchClient)
                .patchNamespacedDeployment(
                        deploymentName,
                        namespace,
                        new V1Patch(jsonStr),
                        null,
                        null,
                        fieldManager,
                        force
                );

        log.info("end deploy : " + patchFormat);

        return new GsonBuilder().setPrettyPrinting().create().toJson(deployment);
    }

body例項用到的json字串來自deploy.json檔案，內容如下，很簡單，只有nginx的1.18.0版本的pod：

{
  "kind":"Deployment",
  "apiVersion":"extensions/v1beta1",
  "metadata":{
    "name":"test123",
    "labels":{
      "run":"test123"
    }
  },
  "spec":{
    "replicas":1,
    "selector":{
      "matchLabels":{
        "run":"test123"
      }
    },
    "template":{
      "metadata":{
        "creationTimestamp":null,
        "labels":{
          "run":"test123"
        }
      },
      "spec":{
        "terminationGracePeriodSeconds":30,
        "containers":[
          {
            "name":"test123",
            "image":"nginx:1.18.0",
            "ports":[
              {
                "containerPort":80
              }
            ],
            "resources":{

            }
          }
        ]
      }
    },
    "strategy":{

    }
  },
  "status":{

  }
}

如此一來，web瀏覽器只要訪問/patch/deploy就能建立deployment了；

發起patch請求的通用方法

通過kubernetes的客戶端發起不同的patch請求，其大致步驟都是相同的，只是引數有所不同，我這裡做了個私有方法，發起幾種patch請求的操作都呼叫此方法實現(只是入參不同而已)，可見都是先建好ApiClient例項，將patch型別傳入，再建立V1Patch例項，將patch字串傳入，最後執行ExtensionsV1beta1Api例項的patchNamespacedDeployment方法即可傳送patch請求：

/**
     * 通用patch方法
     * @param patchFormat patch型別，一共有四種
     * @param deploymentName deployment的名稱
     * @param namespace namespace名稱
     * @param jsonStr patch的json內容
     * @param fieldManager server side apply用到
     * @param force server side apply要設定為true
     * @return patch結果物件轉成的字串
     * @throws Exception
     */
    private String patch(String patchFormat, String deploymentName, String namespace, String jsonStr, String fieldManager, Boolean force) throws Exception {
        // 建立api物件，指定格式是patchFormat
        ApiClient patchClient = ClientBuilder
                .standard()
                .setOverridePatchFormat(patchFormat)
                .build();

        log.info("start deploy : " + patchFormat);

        // 開啟debug便於除錯，生產環境慎用！！！
        patchClient.setDebugging(true);

        // 建立deployment
        ExtensionsV1beta1Deployment deployment = new ExtensionsV1beta1Api(patchClient)
                .patchNamespacedDeployment(
                        deploymentName,
                        namespace,
                        new V1Patch(jsonStr),
                        null,
                        null,
                        fieldManager,
                        force
                );

        log.info("end deploy : " + patchFormat);

        return new GsonBuilder().setPrettyPrinting().create().toJson(deployment);
    }

上述程式碼中，有一行程式碼要格外重視，就是patchClient.setDebugging(true)這段，執行了這一行，在log日誌中就會將http的請求和響應全部列印出來，是我們除錯的利器，但是日誌內容過多，生產環境請慎用；
上述patch方法有六個入參，其實除了patch型別和patch內容，其他引數都可以固定下來，於是再做個簡化版的patch方法：

/**
     * 通用patch方法，fieldManager和force都預設為空
     * @param patchFormat patch型別，一共有四種
     * @param jsonStr patch的json內容
     * @return patch結果物件轉成的字串
     * @throws Exception
     */
    private String patch(String patchFormat, String jsonStr) throws Exception {
        return patch(patchFormat,  DEPLOYMENT_NAME, NAMESPACE, jsonStr, null, null);
    }

入參patchFormat的值是四種patch型別的定義，在V1Patch.java中，其值如下所示：

在這裡插入圖片描述

接下來可以輕鬆的開發各種型別patch的程式碼了；

執行json patch

首先來看json patch要提交的內容，即json.json檔案的內容，這些內容在應用啟動時被儲存到變數jsonStr，如下所示，非常簡單，修改了terminationGracePeriodSeconds屬性的值，原來是30，這個屬性在停止pod的時候用到，是等待pod的主程式的最長時間：

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

接下來就是web介面的程式碼，可見非常簡單，僅需呼叫前面準備好的patch方法：

/**
     * JSON patch格式的關係
     *
     * @return
     * @throws Exception
     */
    @RequestMapping(value = "/patch/json", method = RequestMethod.GET)
    public String json() throws Exception {
        return patch(V1Patch.PATCH_FORMAT_JSON_PATCH, jsonStr);
    }

merge patch（全量）

先嚐試全量的merge patch，也就是準備好完整的deployment內容，修改其中一部分後進行提交，下圖是json檔案merge.json的內容，其內容前面的deploy.json相比，僅增加了紅框處的內容，即增加了一個label：

在這裡插入圖片描述

程式碼依然很簡單：

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

merge patch（增量）

前面曾提到merge patch和strategic merge patch的區別：merge patch提交一個container時做的是替換，而strategic merge patch提交一個container時做的是合併，為了展示這兩種patch的不同，這裡我們就用同一個json內容，分別執行merge patch和strategic merge patch，看看結果有什麼區別，這是最直觀的學習方法；
這個json對應的檔案是strategic.json，內容如下：

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

增量merge的程式碼如下：

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

strategic merge patch

strategic merge patch用的json內容和前面的增量merge patch是同一個，程式碼如下：

@RequestMapping(value = "/patch/strategic", method = RequestMethod.GET)
    public String strategic() throws Exception {
        return patch(V1Patch.PATCH_FORMAT_STRATEGIC_MERGE_PATCH, strategicStr);
    }

apply yaml patch

apply yaml patch與其他patch略有不同，呼叫ExtensionsV1beta1Api的patchNamespacedDeployment方法發請求時，fieldManager和force欄位不能像之前那樣為空了：

 @RequestMapping(value = "/patch/apply", method = RequestMethod.GET)
    public String apply() throws Exception {
        return patch(V1Patch.PATCH_FORMAT_APPLY_YAML,  DEPLOYMENT_NAME, NAMESPACE, applyYamlStr, "example-field-manager", true);
    }

上面的程式碼中，如果force欄位不等於true，可能會導致patch失敗，在官方文件也有說明，如下圖紅框：

在這裡插入圖片描述

apply yaml patch的json字串來自檔案applyYaml.json，其內容是從deploy.json直接複製的，然後改了下圖兩個紅框中的內容，紅框1修改了nginx的版本號，用來驗證patch是否生效(原有版本是1.18)，紅框2是kubernetes1.16之前的一個問題，protocol欄位必填，否則會報錯，問題詳情請參考：https://github.com/kubernetes-sigs/structured-merge-diff/issues/130

在這裡插入圖片描述

以上就是所有程式碼和patch的內容了，接下來部署到kubernetes環境實戰吧

製作映象並且部署

在patch工程目錄下執行以下命令編譯構建：

mvn clean package -U -DskipTests

在patch工程目錄下建立Dockerfile檔案，內容如下：

# 指定基礎映象，這是分階段構建的前期階段
FROM openjdk:8u212-jdk-stretch as builder
# 執行工作目錄
WORKDIR application
# 配置引數
ARG JAR_FILE=target/*.jar
# 將編譯構建得到的jar檔案複製到映象空間中
COPY ${JAR_FILE} application.jar
# 通過工具spring-boot-jarmode-layertools從application.jar中提取拆分後的構建結果
RUN java -Djarmode=layertools -jar application.jar extract

# 正式構建映象
FROM openjdk:8u212-jdk-stretch
WORKDIR application
# 前一階段從jar中提取除了多個檔案，這裡分別執行COPY命令複製到映象空間中，每次COPY都是一個layer
COPY --from=builder application/dependencies/ ./
COPY --from=builder application/spring-boot-loader/ ./
COPY --from=builder application/snapshot-dependencies/ ./
COPY --from=builder application/application/ ./
ENTRYPOINT ["java", "org.springframework.boot.loader.JarLauncher"]

在patch工程目錄下執行以下命令建立docker映象：

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

如果您已經配置了docker映象倉庫私服，建議將此映象推送到私服上去，以便kubernetes上可以使用該映象，我這邊的推送命令如下，僅供參考(涉及到身份驗證的話還請執行docker login登入)：

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

SSH登入kubernetes環境，新建patch.yaml檔案，內容如下，image那裡請按您的映象情況自行調整：

apiVersion: v1
kind: Service
metadata:
  name: patch
  namespace : kubernetesclient
spec:
  type: NodePort
  ports:
    - port: 8080
      nodePort: 30102
  selector:
    name: patch
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  namespace : kubernetesclient
  name: patch
spec:
  replicas: 1
  template:
    metadata:
      labels:
        name: patch
    spec:
      serviceAccountName: kubernates-client-service-account
      containers:
        - name: patch
          image: 192.168.50.43:5888/common/patch:1.0-SNAPSHOT
          tty: true
          livenessProbe:
            httpGet:
              path: /actuator/health/liveness
              port: 8080
            initialDelaySeconds: 5
            failureThreshold: 10
            timeoutSeconds: 10
            periodSeconds: 5
          readinessProbe:
            httpGet:
              path: /actuator/health/readiness
              port: 8080
            initialDelaySeconds: 5
            timeoutSeconds: 10
            periodSeconds: 5
          ports:
            - containerPort: 8080
          resources:
            requests:
              memory: "512Mi"
              cpu: "100m"
            limits:
              memory: "1Gi"
              cpu: "1000m"

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

kubectl apply -f patch.yaml

用於驗證patch的deployment名為test123(瀏覽器訪問/patch/deploy就會建立)，這個deployment裡面是個nginx容器，我們們要給它準備一個NodePort型別的service，以便驗證的是否可以通過瀏覽器訪問，該service對應的yaml檔案是nginx-service.yaml，內容如下：

apiVersion: v1
kind: Service
metadata:
  name: test123
  namespace : default
spec:
  type: NodePort
  ports:
    - port: 80
      nodePort: 30101
  selector:
    run: test123

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

kubectl apply -f nginx-service.yaml

終於，部署工作全部完成，可以驗證patch了！

驗證的步驟

先說一下驗證的步驟：

呼叫建立deployment的介面，建立名為test123的deployment，裡面是個nginx-1.18版本的pod，可以通過瀏覽器訪問到(前面的nginx-service.yaml已經部署了service)；
通過web請求執行各種patch操作；

建立deployment

假設kubernetes宿主機IP地址是192.168.50.135，所以通過瀏覽器訪問：http://192.168.50.135:30102/patch/deploy，即可建立名為test123的deployment，如下圖，建立成功後deployment的詳細資訊會展示在瀏覽器上：

在這裡插入圖片描述

用kubectl命令驗證deployment和pod都正常：

在這裡插入圖片描述

瀏覽器訪問test123這個deployment裡面的nginx容器，地址是http://192.168.50.135:30101/ ，如下圖紅框所示，返回的header中顯示，nginx的版本是1.18.0：

在這裡插入圖片描述

接下來開始提交patch；

驗證json patch

json patch修改的是原deployment的terminationGracePeriodSeconds屬性，所以我們們先來看看修改前是啥樣的，執行命令kubectl get deployment test123 -o yaml，如下圖紅框，terminationGracePeriodSeconds等於30：

在這裡插入圖片描述

瀏覽器訪問http://192.168.50.135:30102/patch/json，即可發起json patch請求，並將deployment的結果返回，如下圖所示，terminationGracePeriodSeconds屬性值已經改變：

在這裡插入圖片描述

再次用命令kubectl get deployment test123 -o yaml檢視，如下圖紅框，json patch已經生效：

在這裡插入圖片描述

執行kubectl logs -f patch-56cd7f7f87-bpl5r -n kubernetesclient可以看到我們們應用通過java客戶端與kubernetes 的API Server之前的詳細日誌(patch-56cd7f7f87-bpl5r是patch工程對應的pod)，如下圖：

在這裡插入圖片描述

json patch驗證已經完成，接著驗證下一個；

驗證merge patch（全量）

merge patch（全量）給原有的deployment增加了一個label，先看看執行patch之前是啥樣，如下圖紅框：
瀏覽器訪問http://192.168.50.135:30102/patch/fullmerge ，就發起了merge請求，操作成功後再次檢視，如下圖紅框，新增了一個label：

在這裡插入圖片描述

驗證merge patch（增量）

瀏覽器訪問http://192.168.50.135:30102/patch/partmerge
在kubernetes環境檢視test123這個deployment的pod，發現原有pod被刪除，新增了一個：

在這裡插入圖片描述

執行命令kubectl describe pod test123-5ff477967-tv729檢視新pod的詳情，發現已經部署nginx了，而是patch中提交的tomcat，如下圖所示，看來增量merge patch實際上做是替換操作：

在這裡插入圖片描述

驗證strategic merge patch

此時的test123這個deployment，其pod已經被剛才的merge patch操作改成了tomcat，不適合接下來的驗證，因此要執行以下操作進行清理和重新部署：

刪除test123這個deployment：kubectl delete deployment test123
瀏覽器訪問：http://192.168.50.135:30102/patch/deploy ，就會重新部署test123

上述操作完成後，test123就恢復到最初狀態了，在瀏覽器執行http://192.168.50.135:30102/patch/strategic ，即可提交strategic merge patch
再去執行kubectl get pod命令檢視，會發現pod會被刪除，然後建立新pod，這個新pod的容器數量是2，如下圖紅框：

在這裡插入圖片描述

執行命令kubectl describe pod test123-59db4854f5-bstz5檢視新pod的詳情，下圖兩個紅框，可見原有的strategic merge patch並沒有替換container，而是新增了一個：

在這裡插入圖片描述

此時您應該對merge patch和strategic merge patch的區別應該有了清晰的認識；

開啟kubernetes的Server-side Apply(低於1.16版本才需要執行)

最後一個實戰是apply yaml patch，此型別patch主要是用於Server-side Apply特性的，
該特性自kubernetes的1.14版本就有了，但是預設並未開啟，直到1.16版本才預設開啟，因此，如果您的kubernetes低於1.16版本，需要開啟這個特性；
java客戶端的官方demo程式碼中，有一些簡單描述，如下圖紅框：

在這裡插入圖片描述

kubernetes的官方文件中，提到此特性在低版本可以通過開關來開啟，文件地址：https://kubernetes.cn/docs/reference/command-line-tools-reference/feature-gates/
我這裡kubernetes版本是1.14，因此需要手動開啟Server-side Apply，首先SSH登入kubernetes環境；
開啟檔案/etc/kubernetes/manifests/kube-apiserver.yaml ，給spec.containers.command增加一個引數--feature-gates=ServerSideApply=true，如下圖紅框所示：

在這裡插入圖片描述

修改完畢後請儲存，由於kubernetes一直在監聽此檔案，因此會立即自動生效；

驗證apply yaml patch

此時的test123，由於剛剛驗證過strategic merge patch，現在的pod裡面有nginx和tomcat兩個container；
瀏覽器訪問http://192.168.50.135:30102/patch/apply
此時pod會重建，如下圖，可見最終container還是兩個，也就是說，儘管applyYaml.json中的container只有一個nginx，但由於是在服務端merge的，服務端只會升級nginx的版本，對於已有的tomcat這個container依舊會保留：

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

在這裡插入圖片描述

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

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

歡迎關注公眾號：程式設計師欣宸

微信搜尋「程式設計師欣宸」，我是欣宸，期待與您一同暢遊Java世界...
https://github.com/zq2599/blog_demos

Kubernetes官方java客戶端之五：proto基本操作
2021-09-09
Java客戶端
Kubernetes官方java客戶端之六：OpenAPI基本操作
2021-01-11
Java客戶端API
Kubernetes官方java客戶端之八：fluent style
2021-01-14
Java客戶端
Kubernetes官方java客戶端之四：內部應用
2021-01-06
Java客戶端
Kubernetes官方java客戶端之一：準備
2020-12-31
Java客戶端
Kubernetes官方java客戶端之三：外部應用
2021-01-05
Java客戶端
【zookeeper之七】Zookeeper客戶端
2018-12-13
客戶端
Kubernetes官方java客戶端之二：序列化和反序列化問題
2021-01-04
Java客戶端
Kubernetes安裝之五：配置kubectl客戶端
2019-02-14
客戶端
Kubernetes客戶端認證（三）—— Kubernetes使用CertificateSigningRequest方式簽發客戶端證書
2024-03-24
客戶端
java客戶端查詢ES操作步驟
2021-09-08
Java客戶端
java websocket 客戶端
2019-03-25
JavaWeb客戶端
ETH官方客戶端Geth的使用(一)
2018-08-12
客戶端
YouTube Vanced: 替代YouTube官方Android客戶端
2019-05-16
Android客戶端
Elasticsearch的PHP客戶端操作
2021-09-09
ElasticsearchPHP客戶端
kubernetes 客戶端KubeClient使用及常用api
2019-03-31
客戶端clientAPI
如何編寫一個前端框架之七－客戶端路由(譯)
2019-02-24
前端框架客戶端路由
Zookeeper Java 客戶端搭建
2021-09-09
Java客戶端
VNC客戶端是Windows，VNC客戶端是Windows如何進行操作
2020-06-02
VNC客戶端Windows
java版gRPC實戰之四：客戶端流
2021-09-16
JavaRPC客戶端
[Redis 客戶端整合] Java 中常用Redis客戶端比較
2024-11-21
Redis客戶端Java
InfluxDB 客戶端基礎操作2
2024-04-25
UX客戶端
ElasticSearch-命令列客戶端操作
2021-01-25
Elasticsearch命令列客戶端
Lens —— 最炫酷的 Kubernetes 桌面客戶端
2020-06-24
客戶端
Kubernetes客戶端和管理介面大集合
2020-09-25
客戶端
zookeeper的Java客戶端API
2018-06-01
Java客戶端API
HTTP客戶端框架之Retrofit
2024-06-09
HTTP客戶端框架
zookeeper在Linux客戶端操作命令大全
2020-11-20
Linux客戶端
ElasticSearch客戶端簡單操作例項
2021-09-08
Elasticsearch客戶端
[jaeger] 二、客戶端使用 (Java版本)
2019-05-06
客戶端Java
SSH客戶端常用工具SecureCRT操作
2023-05-06
客戶端Securecrt
RMAN之客戶端互動（一）
2024-10-30
客戶端
RMAN之客戶端互動（二）
2024-10-30
客戶端
【面經】七戰騰訊之移動客戶端開發實習生
2024-03-21
客戶端
Java HTTP 客戶端的比較 - reflectoring
2021-11-16
JavaHTTP客戶端
Tars-Java客戶端原始碼分析
2021-05-08
Java客戶端原始碼
客戶端登陸logout操作，事務回滾
2020-04-18
客戶端Go
客戶端動態化系列之——URLRoute
2019-03-04
客戶端

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

歡迎訪問我的GitHub

概覽

本文內容

關於patch

patch的四種型別

原始碼下載

實戰步驟概述

準備工作

建立服務

發起patch請求的通用方法

執行json patch

merge patch（全量）

merge patch（增量）

strategic merge patch

apply yaml patch

製作映象並且部署

驗證的步驟

建立deployment

驗證json patch

驗證merge patch（全量）

驗證merge patch（增量）

驗證strategic merge patch

開啟kubernetes的Server-side Apply(低於1.16版本才需要執行)

驗證apply yaml patch

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

歡迎關注公眾號：程式設計師欣宸

相關文章