2024年最全Kubernetes官方java客户端之七：patch操作，java面试写代码

总结

阿里伤透我心，疯狂复习刷题，终于喜提offer 哈哈~好啦，不闲扯了

1、JAVA面试核心知识整理（PDF）：包含JVM，JAVA集合，JAVA多线程并发，JAVA基础，Spring原理，微服务，Netty与RPC，网络，日志，Zookeeper，Kafka，RabbitMQ，Hbase，MongoDB，Cassandra，设计模式，负载均衡，数据库，一致性哈希，JAVA算法，数据结构，加密算法，分布式缓存，Hadoop，Spark，Storm，YARN，机器学习，云计算共30个章节。

2、Redis学习笔记及学习思维脑图

3、数据面试必备20题+数据库性能优化的21个最佳实践

本文已被CODING开源项目：【一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码】收录

需要这份系统化的资料的朋友，可以点击这里获取

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

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

}

3. 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”:{

}

}

4. 如此一来，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

}

]

2. 接下来就是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（全量）

1. 先尝试全量的merge patch，也就是准备好完整的deployment内容，修改其中一部分后进行提交，下图是json文件merge.json的内容，其内容前面的deploy.json相比，仅增加了红框处的内容，即增加了一个label：

2. 代码依然很简单：

@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，内容如下：

{

“spec”:{

“template”:{

“spec”:{

“containers”:[

{

“name”:“test456”,

“image”:“tomcat:7.0.105-jdk8”

}

]

}

}

}

}

3. 增量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

1. 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);

}

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工程目录下执行以下命令编译构建：

mvn clean package -U -DskipTests

2. 在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镜像：

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

4. 如果您已经配置了docker镜像仓库私服，建议将此镜像推送到私服上去，以便kubernetes上可以使用该镜像，我这边的推送命令如下，仅供参考(涉及到身份验证的话还请执行docker login登录)：

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

5. 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”

6. 执行以下命令即可完成部署：

kubectl apply -f patch.yaml

7. 用于验证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

8. 执行以下命令即可完成部署：

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特性的，

最后

经过日积月累， 以下是小编归纳整理的深入了解Java虚拟机文档，希望可以帮助大家过关斩将顺利通过面试。
由于整个文档比较全面，内容比较多，篇幅不允许，下面以截图方式展示 。

由于篇幅限制，文档的详解资料太全面，细节内容太多，所以只把部分知识点截图出来粗略的介绍，每个小节点里面都有更细化的内容！

本文已被CODING开源项目：【一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码】收录

需要这份系统化的资料的朋友，可以点击这里获取

shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2JvbGluZ19jYXZhbHJ5,size_16,color_FFFFFF,t_70)

5. 此时您应该对merge patch和strategic merge patch的区别应该有了清晰的认识；

开启kubernetes的Server-side Apply(低于1.16版本才需要执行)

1. 最后一个实战是apply yaml patch，此类型patch主要是用于Server-side Apply特性的，

最后

经过日积月累， 以下是小编归纳整理的深入了解Java虚拟机文档，希望可以帮助大家过关斩将顺利通过面试。
由于整个文档比较全面，内容比较多，篇幅不允许，下面以截图方式展示 。

[外链图片转存中…(img-29xQLHJN-1715086299486)]
[外链图片转存中…(img-OmZHPlAc-1715086299486)]
[外链图片转存中…(img-sZL7ZNTV-1715086299486)]
[外链图片转存中…(img-veyPH2qJ-1715086299486)]
[外链图片转存中…(img-devphDok-1715086299487)]
[外链图片转存中…(img-YNEcsFVw-1715086299487)]
[外链图片转存中…(img-Sc33K5bu-1715086299487)]

由于篇幅限制，文档的详解资料太全面，细节内容太多，所以只把部分知识点截图出来粗略的介绍，每个小节点里面都有更细化的内容！

本文已被CODING开源项目：【一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码】收录

需要这份系统化的资料的朋友，可以点击这里获取