Kubernetes官方java客户端之七:patch操作

Stella981
• 阅读 403

欢迎访问我的GitHub

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官方java客户端之七: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/
    Kubernetes官方java客户端之七:patch操作

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):
    Kubernetes官方java客户端之七:patch操作

  4. 通过源码查看资源的patchStrategy属性是很麻烦的事情,因此也可以通过Kubernetes API 文档来查看,如下图,地址是:https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.18/#podspec-v1-core
    Kubernetes官方java客户端之七:patch操作

  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)

git@github.com:zq2599/blog_demos.git

该项目源码的仓库地址,ssh协议

  1. 这个git项目中有多个文件夹,本章的应用在kubernetesclient文件夹下,如下图红框所示:
    Kubernetes官方java客户端之七:patch操作

实战步骤概述

  • 接下来会创建一个springboot工程(该工程是kubernetesclient的子工程),针对四种patch咱们都有对应的操作;
  • 每种patch都会准备对应的json文件,提前将这些文件的内容保存在字符串变量中,在程序里用kubernetes客户端的patch专用API,将此json字符串发送出去,流程简图如下:
    Kubernetes官方java客户端之七:patch操作
  • 编码完成后,就来动手验证功能,具体操作如下:
  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客户端之一:准备 》一文创建的项目kubernetesclient,新增名为patch的子工程,pom.xml内容如下:

    4.0.0 com.bolingcavalry kubernetesclient 1.0-SNAPSHOT ../pom.xml com.bolingcavalry patch 0.0.1-SNAPSHOT patch patch demo jar org.springframework.boot spring-boot-starter-web org.springframework.boot spring-boot-starter-json org.springframework.boot spring-boot-starter-actuator org.projectlombok lombok true io.kubernetes client-java org.springframework.boot spring-boot-maven-plugin 2.3.0.RELEASE true

  2. 编写一个辅助类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;
    }
    

    }

  3. 接下来新建本篇文章的核心类PatchExample.java,首先这个类中有main方法,整个应用从这里启动:

    public static void main(String[] args) {

        SpringApplication.run(PatchExample.class, args);
    }
    
  4. 接下来有两个常量定义,分别是kubernetes环境里用来测试的deployment名称,以及namespace名称:

    static String DEPLOYMENT_NAME = "test123";

    static String NAMESPACE = "default";

  5. 然后定义几个字符串变量,执行patch操作时用到的json内容都保存到这些字符串变量中:

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

  6. 在resources文件夹中放入json文件,稍后的初始化代码会将这些文件读取到字符串变量中,如下图,这些json文件的内容稍后会详细说明:
    Kubernetes官方java客户端之七:patch操作

  7. 编写初始化代码(通过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(); }

  • 以上就是准备工作;

创建服务

  1. 首先要开发一个部署的接口,通过调用此接口可以在kubernetes环境部署一个deployment:

  2. 部署服务的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); }

  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中,其值如下所示:
    Kubernetes官方java客户端之七:patch操作

  • 接下来可以轻松的开发各种类型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:
    Kubernetes官方java客户端之七:patch操作

  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失败,在官方文档也有说明,如下图红框:
    Kubernetes官方java客户端之七: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
    Kubernetes官方java客户端之七:patch操作

  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的详细信息会展示在浏览器上:
    Kubernetes官方java客户端之七:patch操作

  2. 用kubectl命令验证deployment和pod都正常:
    Kubernetes官方java客户端之七:patch操作

  3. 浏览器访问test123这个deployment里面的nginx容器,地址是http://192.168.50.135:30101/ ,如下图红框所示,返回的header中显示,nginx的版本是1.18.0:
    Kubernetes官方java客户端之七:patch操作

  4. 接下来开始提交patch;

验证json patch

  1. json patch修改的是原deployment的terminationGracePeriodSeconds属性,所以咱们先来看看修改前是啥样的,执行命令kubectl get deployment test123 -o yaml,如下图红框,terminationGracePeriodSeconds等于30:
    Kubernetes官方java客户端之七:patch操作

  2. 浏览器访问http://192.168.50.135:30102/patch/json,即可发起json patch请求,并将deployment的结果返回,如下图所示,terminationGracePeriodSeconds属性值已经改变:
    Kubernetes官方java客户端之七:patch操作

  3. 再次用命令kubectl get deployment test123 -o yaml查看,如下图红框,json patch已经生效:
    Kubernetes官方java客户端之七:patch操作

  4. 执行kubectl logs -f patch-56cd7f7f87-bpl5r -n kubernetesclient可以看到咱们应用通过java客户端与kubernetes 的API Server之前的详细日志(patch-56cd7f7f87-bpl5r是patch工程对应的pod),如下图:
    Kubernetes官方java客户端之七:patch操作

  5. json patch验证已经完成,接着验证下一个;

验证merge patch(全量)

  1. merge patch(全量)给原有的deployment增加了一个label,先看看执行patch之前是啥样,如下图红框:
    Kubernetes官方java客户端之七:patch操作

  2. 浏览器访问http://192.168.50.135:30102/patch/fullmerge ,就发起了merge请求,操作成功后再次查看,如下图红框,新增了一个label:
    Kubernetes官方java客户端之七:patch操作

验证merge patch(增量)

  1. 浏览器访问http://192.168.50.135:30102/patch/partmerge

  2. 在kubernetes环境查看test123这个deployment的pod,发现原有pod被删除,新增了一个:
    Kubernetes官方java客户端之七:patch操作

  3. 执行命令kubectl describe pod test123-5ff477967-tv729查看新pod的详情,发现已经部署nginx了,而是patch中提交的tomcat,如下图所示,看来增量merge patch实际上做是替换操作:
    Kubernetes官方java客户端之七:patch操作

验证strategic merge patch

  1. 此时的test123这个deployment,其pod已经被刚才的merge patch操作改成了tomcat,不适合接下来的验证,因此要执行以下操作进行清理和重新部署:
  1. 上述操作完成后,test123就恢复到最初状态了,在浏览器执行http://192.168.50.135:30102/patch/strategic ,即可提交strategic merge patch

  2. 再去执行kubectl get pod命令查看,会发现pod会被删除,然后创建新pod,这个新pod的容器数量是2,如下图红框:
    Kubernetes官方java客户端之七:patch操作

  3. 执行命令kubectl describe pod test123-59db4854f5-bstz5查看新pod的详情,下图两个红框,可见原有的strategic merge patch并没有替换container,而是新增了一个:
    Kubernetes官方java客户端之七:patch操作

  4. 此时您应该对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代码中,有一些简单描述,如下图红框:
    Kubernetes官方java客户端之七:patch操作

  4. kubernetes的官方文档中,提到此特性在低版本可以通过开关来开启,文档地址:https://kubernetes.cn/docs/reference/command-line-tools-reference/feature-gates/
    Kubernetes官方java客户端之七:patch操作

  5. 我这里kubernetes版本是1.14,因此需要手动开启Server-side Apply,首先SSH登录kubernetes环境;

  6. 打开文件/etc/kubernetes/manifests/kube-apiserver.yaml ,给spec.containers.command增加一个参数–feature-gates=ServerSideApply=true,如下图红框所示:
    Kubernetes官方java客户端之七:patch操作

  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依旧会保留:
    Kubernetes官方java客户端之七:patch操作
  4. 用浏览器访问test123提供的nginx服务,如下图红框所示,nginx版本已经升级,证明本次patch已经生效:
    Kubernetes官方java客户端之七:patch操作

至此,通过kubernetes的java客户端执行patch操作的实战就全部完成了,从理论到环境准备,再到实际操作,涉及到太多内容,感谢您的耐心,希望本文能助您用好java客户端这个利器,更高效的操作kubernetes环境;

本文同步分享在 博客“程序员欣宸”(CSDN)。
如有侵权,请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”,欢迎正在阅读的你也加入,一起分享。

点赞
收藏
评论区
推荐文章
刚刚好 刚刚好
2个月前
css问题
1、在IOS中图片不显示(给图片加了圆角或者img没有父级)<div<imgsrc""/</divdiv{width:20px;height:20px;borderradius:20px;overflow:h
blmius blmius
1年前
MySQL:[Err] 1292 - Incorrect datetime value: ‘0000-00-00 00:00:00‘ for column ‘CREATE_TIME‘ at row 1
文章目录问题用navicat导入数据时,报错:原因这是因为当前的MySQL不支持datetime为0的情况。解决修改sql\mode:sql\mode:SQLMode定义了MySQL应支持的SQL语法、数据校验等,这样可以更容易地在不同的环境中使用MySQL。全局s
晴空闲云 晴空闲云
2个月前
css中box-sizing解放盒子实际宽高计算
我们知道传统的盒子模型,如果增加内边距padding和边框border,那么会撑大整个盒子,造成盒子的宽度不好计算,在实务中特别不方便。boxsizing可以设置盒模型的方式,可以很好的设置固定宽高的盒模型。盒子宽高计算假如我们设置如下盒子:宽度和高度均为200px,那么这会这个盒子实际的宽高就都是200px。但是当我们设置这个盒子的边框和内间距的时候,那
艾木酱 艾木酱
1个月前
快速入门|使用MemFire Cloud构建React Native应用程序
MemFireCloud是一款提供云数据库,用户可以创建云数据库,并对数据库进行管理,还可以对数据库进行备份操作。它还提供后端即服务,用户可以在1分钟内新建一个应用,使用自动生成的API和SDK,访问云数据库、对象存储、用户认证与授权等功能,可专
Stella981 Stella981
1年前
JUnit5学习之二:Assumptions类
欢迎访问我的GitHubhttps://github.com/zq2599/blog\_demos(https://www.oschina.net/action/GoToLink?urlhttps%3A%2F%2Fgithub.com%2Fzq2599%2Fblog_demos)内容:所有原创文章分类汇总及配套源码,涉及Java、Doc
Stella981 Stella981
1年前
JUnit5学习之三:Assertions类
欢迎访问我的GitHubhttps://github.com/zq2599/blog\_demos(https://www.oschina.net/action/GoToLink?urlhttps%3A%2F%2Fgithub.com%2Fzq2599%2Fblog_demos)内容:所有原创文章分类汇总及配套源码,涉及Java、Doc
Stella981 Stella981
1年前
MyBatis初级实战之四:druid多数据源
欢迎访问我的GitHubhttps://github.com/zq2599/blog\_demos(https://www.oschina.net/action/GoToLink?urlhttps%3A%2F%2Fgithub.com%2Fzq2599%2Fblog_demos)内容:所有原创文章分类汇总及配套源码,涉及Java、Do
Stella981 Stella981
1年前
MyBatis初级实战之二:增删改查
欢迎访问我的GitHubhttps://github.com/zq2599/blog\_demos(https://www.oschina.net/action/GoToLink?urlhttps%3A%2F%2Fgithub.com%2Fzq2599%2Fblog_demos)内容:所有原创文章分类汇总及配套源码,涉及Java、Do
Stella981 Stella981
1年前
MyBatis初级实战之三:springboot集成druid
欢迎访问我的GitHubhttps://github.com/zq2599/blog\_demos(https://www.oschina.net/action/GoToLink?urlhttps%3A%2F%2Fgithub.com%2Fzq2599%2Fblog_demos)内容:所有原创文章分类汇总及配套源码,涉及Java、Do
helloworld_28799839 helloworld_28799839
2个月前
常用知识整理
Javascript判断对象是否为空jsObject.keys(myObject).length0经常使用的三元运算我们经常遇到处理表格列状态字段如status的时候可以用到vue