Kubernetes官方java客戶端之七：patch操作
阿新 • • 發佈：2021-01-13
### 歡迎訪問我的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操作，如下圖：
接下來先了解一些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/
### 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)：
4. 通過原始碼檢視資源的patchStrategy屬性是很麻煩的事情，因此也可以通過Kubernetes API 文件來檢視，如下圖，地址是：https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.18/#podspec-v1-core
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)：
| 名稱 | 連結 | 備註|
| :-------- | :----| :----|
| 專案主頁| 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協議 |
2. 這個git專案中有多個資料夾，本章的應用在kubernetesclient資料夾下，如下圖紅框所示：
### 實戰步驟概述
- 接下來會建立一個springboot工程(該工程是kubernetesclient的子工程)，針對四種patch咱們都有對應的操作；
- 每種patch都會準備對應的json檔案，提前將這些檔案的內容儲存在字串變數中，在程式裡用kubernetes客戶端的patch專用API，將此json字串傳送出去，流程簡圖如下：
- 編碼完成後，就來動手驗證功能，具體操作如下：
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客戶端之一：準備 》](https://xinchen.blog.csdn.net/article/details/107480015)一文建立的專案kubernetesclient，新增名為patch的子工程，pom.xml內容如下：
```xml
```
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;
}
}
```
3. 接下來新建本篇文章的核心類PatchExample.java，首先這個類中有main方法，整個應用從這裡啟動：
```java
public static void main(String[] args) {
SpringApplication.run(PatchExample.class, args);
}
```
4. 接下來有兩個常量定義，分別是kubernetes環境裡用來測試的deployment名稱，以及namespace名稱：
```java
static String DEPLOYMENT_NAME = "test123";
static String NAMESPACE = "default";
```
5. 然後定義幾個字串變數，執行patch操作時用到的json內容都儲存到這些字串變數中：
```shell
static String deployStr, jsonStr, mergeStr, strategicStr, applyYamlStr;
```
6. 在resources資料夾中放入json檔案，稍後的初始化程式碼會將這些檔案讀取到字串變數中，如下圖，這些json檔案的內容稍後會詳細說明：
7. 編寫初始化程式碼(通過PostConstruct註解實現)，主要是客戶端配置，還有將json檔案的內容讀出來，儲存到剛剛準備的字串變數中：
```java
@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即可：
```java
/**
* 通用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);
}
```
3. body例項用到的json字串來自deploy.json檔案，內容如下，很簡單，只有nginx的1.18.0版本的pod：
```json
{
"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":{
}
}
```
4. 如此一來，web瀏覽器只要訪問/patch/deploy就能建立deployment了；
### 發起patch請求的通用方法
- 通過kubernetes的客戶端發起不同的patch請求，其大致步驟都是相同的，只是引數有所不同，我這裡做了個私有方法，發起幾種patch請求的操作都呼叫此方法實現(只是入參不同而已)，可見都是先建好ApiClient例項，將patch型別傳入，再建立V1Patch例項，將patch字串傳入，最後執行ExtensionsV1beta1Api例項的patchNamespacedDeployment方法即可傳送patch請求：
```java
/**
* 通用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方法：
```java
/**
* 通用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的主程序的最長時間：
```json
[
{
"op":"replace",
"path":"/spec/template/spec/terminationGracePeriodSeconds",
"value":27
}
]
```
2. 接下來就是web介面的程式碼，可見非常簡單，僅需呼叫前面準備好的patch方法：
```java
/**
* 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：
2. 程式碼依然很簡單：
```java
@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，內容如下：
```json
{
"spec":{
"template":{
"spec":{
"containers":[
{
"name":"test456",
"image":"tomcat:7.0.105-jdk8"
}
]
}
}
}
}
```
3. 增量merge的程式碼如下：
```java
@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是同一個，程式碼如下：
```java
@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欄位不能像之前那樣為空了：
```java
@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);
}
```
2. 上面的程式碼中，如果force欄位不等於true，可能會導致patch失敗，在官方文件也有說明，如下圖紅框：
3. 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
4. 以上就是所有程式碼和patch的內容了，接下來部署到kubernetes環境實戰吧
### 製作映象並且部署
1. 在patch工程目錄下執行以下命令編譯構建：
```shell
mvn clean package -U -DskipTests
```
2. 在patch工程目錄下建立Dockerfile檔案，內容如下：
```shell
# 指定基礎映象，這是分階段構建的前期階段
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 .
```
4. 如果您已經配置了docker映象倉庫私服，建議將此映象推送到私服上去，以便kubernetes上可以使用該映象，我這邊的推送命令如下，僅供參考(涉及到身份驗證的話還請執行docker login登入)：
```shell
docker push 192.168.50.43:5888/common/patch:1.0-SNAPSHOT
```
5. SSH登入kubernetes環境，新建patch.yaml檔案，內容如下，image那裡請按您的映象情況自行調整：
```yaml
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"
```
6. 執行以下命令即可完成部署：
```shell
kubectl apply -f patch.yaml
```
7. 用於驗證patch的deployment名為test123(瀏覽器訪問/patch/deploy就會建立)，這個deployment裡面是個nginx容器，咱們要給它準備一個NodePort型別的service，以便驗證的是否可以通過瀏覽器訪問，該service對應的yaml檔案是nginx-service.yaml，內容如下：
```shell
apiVersion: v1
kind: Service
metadata:
name: test123
namespace : default
spec:
type: NodePort
ports:
- port: 80
nodePort: 30101
selector:
run: test123
```
8. 執行以下命令即可完成部署：
```shell
kubectl apply -f nginx-service.yaml
```
9. 終於，部署工作全部完成，可以驗證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的詳細資訊會展示在瀏覽器上：
2. 用kubectl命令驗證deployment和pod都正常：
3. 瀏覽器訪問test123這個deployment裡面的nginx容器，地址是http://192.168.50.135:30101/ ，如下圖紅框所示，返回的header中顯示，nginx的版本是1.18.0：
4. 接下來開始提交patch；
### 驗證json patch
1. json patch修改的是原deployment的terminationGracePeriodSeconds屬性，所以咱們先來看看修改前是啥樣的，執行命令kubectl get deployment test123 -o yaml，如下圖紅框，terminationGracePeriodSeconds等於30：
2. 瀏覽器訪問http://192.168.50.135:30102/patch/json，即可發起json patch請求，並將deployment的結果返回，如下圖所示，terminationGracePeriodSeconds屬性值已經改變：
3. 再次用命令kubectl get deployment test123 -o yaml檢視，如下圖紅框，json patch已經生效：
4. 執行kubectl logs -f patch-56cd7f7f87-bpl5r -n kubernetesclient可以看到咱們應用通過java客戶端與kubernetes 的API Server之前的詳細日誌(patch-56cd7f7f87-bpl5r是patch工程對應的pod)，如下圖：
5. json patch驗證已經完成，接著驗證下一個；
### 驗證merge patch（全量）
1. merge patch（全量）給原有的deployment增加了一個label，先看看執行patch之前是啥樣，如下圖紅框：
2. 瀏覽器訪問http://192.168.50.135:30102/patch/fullmerge ，就發起了merge請求，操作成功後再次檢視，如下圖紅框，新增了一個label：
### 驗證merge patch（增量）
1. 瀏覽器訪問http://192.168.50.135:30102/patch/partmerge
2. 在kubernetes環境檢視test123這個deployment的pod，發現原有pod被刪除，新增了一個：
3. 執行命令kubectl describe pod test123-5ff477967-tv729檢視新pod的詳情，發現已經部署nginx了，而是patch中提交的tomcat，如下圖所示，看來增量merge patch實際上做是替換操作：
### 驗證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
2. 上述操作完成後，test123就恢復到最初狀態了，在瀏覽器執行http://192.168.50.135:30102/patch/strategic ，即可提交strategic merge patch
3. 再去執行kubectl get pod命令檢視，會發現pod會被刪除，然後建立新pod，這個新pod的容器數量是2，如下圖紅框：
4. 執行命令kubectl describe pod test123-59db4854f5-bstz5檢視新pod的詳情，下圖兩個紅框，可見原有的strategic merge patch並沒有替換container，而是新增了一個：
5. 此時您應該對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程式碼中，有一些簡單描述，如下圖紅框：
4. kubernetes的官方文件中，提到此特性在低版本可以通過開關來開啟，文件地址：https://kubernetes.cn/docs/reference/command-line-tools-reference/feature-gates/
5. 我這裡kubernetes版本是1.14，因此需要手動開啟Server-side Apply，首先SSH登入kubernetes環境；
6. 開啟檔案/etc/kubernetes/manifests/kube-apiserver.yaml ，給spec.containers.command增加一個引數--feature-gates=ServerSideApply=true，如下圖紅框所示：
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依舊會保留：
4. 用瀏覽器訪問test123提供的nginx服務，如下圖紅框所示，nginx版本已經升級，證明本次patch已經生效：
至此，通過kubernetes的java客戶端執行patch操作的實戰就全部完成了，從理論到環境準備，再到實際操作，涉及到太多內容，感謝您的耐心，希望本文能助您用好java客戶端這個利器，更高效的操作kubernetes環境；
### 你不孤單，欣宸原創一路相伴
1. [Java系列](https://xinchen.blog.csdn.net/article/details/105068742)
2. [Spring系列](https://xinchen.blog.csdn.net/article/details/105086498)
3. [Docker系列](https://xinchen.blog.csdn.net/article/details/105086732)
4. [kubernetes系列](https://xinchen.blog.csdn.net/article/details/105086794)
5. [資料庫+中介軟體系列](https://xinchen.blog.csdn.net/article/details/105086850)
6. [DevOps系列](https://xinchen.blog.csdn.net/article/details/105086920)
### 歡迎關注公眾號：程式設計師欣宸
> 微信搜尋「程式設計師欣宸」，我是欣宸，期待與您一同暢遊Java世界...
[https://github.com/zq2599/blog_demos](https://github.com/zq2599/blo