欢送拜访我的GitHub
https://github.com/zq2599/blog_demos
内容:所有原创文章分类汇总及配套源码,波及Java、Docker、Kubernetes、DevOPS等;
概览
- 本文是《Kubernetes官网java客户端》系列的第八篇,以下提到的<font color=”blue”>java客户端</font>都是指client-jar.jar;
- 前文《Kubernetes官网java客户端之七:patch操作》波及的知识点、代码、操作都太多了,<font color=”red”>对作者和读者都是莫大的折磨</font>,到了本篇咱们轻松一下,写几段简略晦涩的代码,理解java客户端对fluent style编程的反对,并且编码实现后的验证操作也很简略;
对于fluent styel
- 也称为fluid coding, fluent programming,是一种加强代码可读性的格调,使得浏览代码时更加天然晦涩,特点是函数返回无关类型,使得多个函数的调用前后链接起来。
- 对于fluent style能够参考Martin Flowler于2005年发表的文章,地址是:https://martinfowler.com/blik… ,应用fluent style前后的代码对比方下图所示:
### 源码下载
- 如果您不想编码,能够在GitHub下载所有源码,地址和链接信息如下表所示(https://github.com/zq2599/blo…:
名称 | 链接 | 备注 |
---|---|---|
我的项目主页 | https://github.com/zq2599/blo… | 该我的项目在GitHub上的主页 |
git仓库地址(https) | https://github.com/zq2599/blo… | 该我的项目源码的仓库地址,https协定 |
git仓库地址(ssh) | git@github.com:zq2599/blog_demos.git | 该我的项目源码的仓库地址,ssh协定 |
- 这个git我的项目中有多个文件夹,本章的利用在<font color=”blue”>kubernetesclient</font>文件夹下,如下图红框所示:
实战步骤概述
- 在父工程<font color=”blue”>kubernetesclient</font>上面新建名为<font color=”red”>fluent</font>的子工程;
- fluent工程中只有一个类FluentStyleApplication,启动的main办法以及fluent style的代码都在此类中;
- <font color=”blue”>FluentStyleApplication.java</font>提供四个web接口,性能别离是:新建namespace、新建deployment、新建service、删除后面三个接口新建的所有资源;
- <font color=”blue”>fluent</font>工程编码实现后,不须要做成镜像部署在kubernetes环境外部,而是作为一个一般SpringBoot利用找个java环境启动即可,与《Kubernetes官网java客户端之三:内部利用 》一文的部署和启动统一;
- 顺次调用每个接口,验证性能是否合乎预期;
编码
- 在父工程<font color=”blue”>kubernetesclient</font>上面新建名为<font color=”red”>fluent</font>的maven子工程,pom.xml内容如下,须要留神的是排除掉<font color=”blue”>spring-boot-starter-json</font>,起因请参考《Kubernetes官网java客户端之二:序列化和反序列化问题 》:
<?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>fluent</artifactId>
<version>0.0.1-SNAPSHOT</version>
<name>fluent</name>
<description>Demo project for fluent style</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.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>
</plugin>
</plugins>
</build>
</project>
- 新建<font color=”blue”>FluentStyleApplication.java</font>,首先,该类作为启动类,要有main办法:
public static void main(String[] args) {
SpringApplication.run(FluentStyleApplication.class, args);
}
- 定义常量<font color=”blue”>NAMESPACE</font>作为本次实战的namespace:
private final static String NAMESPACE = "fluent";
- 用@PostConstruct注解润饰setDefaultApiClient办法,令其在实例化时执行一次,外面做了一些全局性的初始化设置,留神<font color=”blue”>kubeConfigPath</font>变量对应的config文件门路要正确:
/**
* 默认的全局设置
* @return
* @throws Exception
*/
@PostConstruct
private void setDefaultApiClient() throws Exception {
// 寄存K8S的config文件的全门路
String kubeConfigPath = "/Users/zhaoqin/temp/202007/05/config";
// 以config作为入参创立的client对象,能够拜访到K8S的API Server
ApiClient client = ClientBuilder
.kubeconfig(KubeConfig.loadKubeConfig(new FileReader(kubeConfigPath)))
.build();
// 会打印和API Server之间申请响应的具体内容,生产环境慎用
client.setDebugging(true);
// 创立操作类
Configuration.setDefaultApiClient(client);
}
- 接下来是创立namespace的web服务,如下所示,因为namespace在kubernetes的apiVersion是v1,因而创立的是<font color=”blue”>V1Namespace</font>实例:
@RequestMapping(value = "/fluent/createnamespace")
public V1Namespace createnamespace() throws Exception {
V1Namespace v1Namespace = new V1NamespaceBuilder()
.withNewMetadata()
.withName(NAMESPACE)
.addToLabels("label1", "aaa")
.addToLabels("label2", "bbb")
.endMetadata()
.build();
return new CoreV1Api().createNamespace(v1Namespace, null, null, null);
}
- 为了更清晰的展示<font color=”blue”>fluent style</font>成果,将上述代码与创立namespace的yaml文件内容放在一起比照,如下图所示,可见对照着yaml文件就能将代码写进去:
- 接下来是创立service的代码,为了便于和yaml对应起来,代码中特意加了缩进:
@RequestMapping(value = "/fluent/createservice")
public V1Service createservice() throws Exception {
V1Service v1Service = new V1ServiceBuilder()
// meta设置
.withNewMetadata()
.withName("nginx")
.endMetadata()
// spec设置
.withNewSpec()
.withType("NodePort")
.addToPorts(new V1ServicePort().port(80).nodePort(30103))
.addToSelector("name", "nginx")
.endSpec()
.build();
return new CoreV1Api().createNamespacedService(NAMESPACE, v1Service, null, null, null);
}
- 创立deployment的代码如下,因为内容较多所以绝对简单一些,请留神,因为deployment在kubernetes的apiVersion是<font color=”blue”>extensions/v1beta1</font>,因而创立的是<font color=”red”>ExtensionsV1beta1Deployment</font>实例:
@RequestMapping(value = "/fluent/createdeployment")
public ExtensionsV1beta1Deployment createdeployment() throws Exception {
ExtensionsV1beta1Deployment v1Deployment = new ExtensionsV1beta1DeploymentBuilder()
// meta设置
.withNewMetadata()
.withName("nginx")
.endMetadata()
// spec设置
.withNewSpec()
.withReplicas(1)
// spec的templat
.withNewTemplate()
// template的meta
.withNewMetadata()
.addToLabels("name", "nginx")
.endMetadata()
// template的spec
.withNewSpec()
.addNewContainer()
.withName("nginx")
.withImage("nginx:1.18.0")
.addToPorts(new V1ContainerPort().containerPort(80))
.endContainer()
.endSpec()
.endTemplate()
.endSpec()
.build();
return new ExtensionsV1beta1Api().createNamespacedDeployment(NAMESPACE, v1Deployment, null, null, null);
}
- 从上述代码可见,<font color=”blue”>withXXX</font>和<font color=”blue”>endXXX</font>是成对呈现的,请在编程的时候留神不要脱漏了endXXX,倡议在写withXXX的同时就把endXXX写上;
- 最初一个办法是清理所有资源的,后面创立的deployment、service、namespace都在此一次性清理掉,实际操作中发现了一个难堪的状况:删除deployment和namespace时,发送到API Server的删除申请都收到的操作胜利的响应,但kubernetes客户端在反序列化响应内容时抛出异样(日志中显示了详细情况),<font color=”red”>鄙人能力无限暂未找到解决之道</font>,因而只能用try catch来防止整个办法抛出异样,好在kubernetes实际上曾经删除胜利了,影响不大:
@RequestMapping(value = "/fluent/clear")
public String clear() throws Exception {
// 删除deployment
try {
new ExtensionsV1beta1Api().deleteNamespacedDeployment("nginx", NAMESPACE, null, null, null, null, null, null);
} catch (Exception e)
{
log.error("delete deployment error", e);
}
CoreV1Api coreV1Api = new CoreV1Api();
// 删除service
coreV1Api.deleteNamespacedService("nginx", NAMESPACE, null, null, null, null, null, null);
// 删除namespace
try {
coreV1Api.deleteNamespace(NAMESPACE, null, null, null, null, null, null);
} catch (Exception e)
{
log.error("delete namespace error", e);
}
return "clear finish, " + new Date();
}
- 编码已实现,启动fluent工程,接下来开始验证性能是否失常;
验证
- 将fluent工程间接在IEDA环境启动;
- 浏览器拜访:<font color=”blue”>http://localhost:8080/fluent/createnamespace</font> ,页面会展现API Server返回的残缺namespace信息:
- 浏览器拜访:<font color=”blue”>http://localhost:8080/fluent/createservice</font> ,页面会展现API Server返回的残缺service信息:
- 浏览器拜访:<font color=”blue”>http://localhost:8080/fluent/createdeployment</font> ,页面会展现API Server返回的残缺deployment信息:
- 验证后面几个接口创立的服务是否可用,我这里kubernetes的IP地址是<font color=”blue”>192.168.50.135</font>,因而拜访:<font color=”blue”>http://192.168.50.135:30103</font> ,能够失常显示nginx首页:
- SSH登录kubernetes服务器查看,通过kubernetes的java客户端创立的资源都失常:
- 验证实现后,浏览器拜访:<font color=”blue”>http://localhost:8080/fluent/clear</font> ,即可清理掉后面三个接口创立的资源;
- 至此,基于fluent style调用java客户端的实战就实现了,心愿您能纯熟应用此格调的API调用,使得编码变得更加轻松晦涩,顺便预报一下,下一篇持续做一些简略轻松的操作,指标是相熟java客户端的罕用操作;
你不孤独,欣宸原创一路相伴
- Java系列
- Spring系列
- Docker系列
- kubernetes系列
- 数据库+中间件系列
- DevOps系列
欢送关注公众号:程序员欣宸
微信搜寻「程序员欣宸」,我是欣宸,期待与您一起畅游Java世界…
https://github.com/zq2599/blog_demos
发表回复