One of the official java clients of Kubernetes: preparation

Welcome to my GitHub

Content: Classification and summary of all original articles and supporting source code, involving Java, Docker, Kubernetes, DevOPS, etc.;

About Kubernetes official java client

The full name of Kubernetes official java client is Kubernetes Java Client , which is the java library officially launched by K8S. Taking version 8.0.2 as an example, its maven coordinates are as follows:

<dependency>
    <groupId>io.kubernetes</groupId>
    <artifactId>client-java</artifactId>
    <version>8.0.2</version>
    <scope>compile</scope>
</dependency>

This article is the first in the "Kubernetes official java client" series, the main content is to understand the concept, and then prepare for the subsequent chapters;
Recall how we usually operate the K8S environment, such as deploying deployment, uploading yaml files on the dashboard page, or executing kubectl commands on the SSH terminal. The destination of these operations is the K8S API Server, as shown below:
As can be seen from the above figure, if the request can be sent to the API Server, K8S can be operated like kubectl commands. The official K8S java client (Kubernetes Java Client) is an SDK with such capabilities, making java applications have the capabilities of kubectl. As shown in the figure below, the SpringBoot application loaded with the official K8S java client library can directly send the request to the K8S environment:

What needs to be prepared

"Kubernetes Official Java Client" is a series of articles focusing on actual combat. For the smooth progress of actual combat, preparations will be made in this chapter, including hardware, software, configuration, etc., which will be listed one by one next;

Development environment

The environment I use for coding is as follows:

Operating system: macOS Catalina 10.15.5
JDK：1.8.0_121
Maven：33.3.9
Development tools: IntelliJ IDEA 2019.3.2 (Ultimate Edition)

Operating environment

After the encoding is completed, run in the K8S environment, which has only one CentoOS computer, and the information is as follows:

Operating system: CentOS Linux release 7.8.2003
K8S：1.15.3

Select the client-java version

There are multiple versions of K8S and multiple versions of the java client. How do I choose when I use it? Please refer to the official compatibility list:
As shown above, the horizontal is the K8S version, and the vertical is the java client version. There are three symbols in the table, which have the following meanings:

✓ It means that from features to API, the client and K8S environment are matched;
+ Indicates that some features and APIs of the client cannot match the K8S environment, but their shared features and APIs can all run normally;
-Indicates that some features and APIs in the current K8S environment cannot be provided by the client;
My K8S version is 1.15 . It can be seen that the client of version 7.0.0 is the most suitable. This version will also be used in subsequent actual combat. Please choose the corresponding version according to your K8S situation;

SpringBoot application operation permissions

In the following actual combat, our SpringBoot application will run in the K8S environment in the form of a Pod, and operate K8S through the client-java API. Naturally, K8S will not allow the Pod to operate on the pod and deployment resources in the environment at will, so we Perform RBAC-related operations in accordance with K8S specifications;
The role setting of K8S can be very detailed, but it will also be more complicated. Let’s not spend too much time on it. Here I have chosen to use the role with the highest authority that comes with K8S: cluster-admin , you can follow your own reality Customize the role of the situation, the following is the specific operation;
Log in to K8S via SSH and create a namespace:

kubectl create namespace kubernetesclient

Create a file rbac.yaml with the following content:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: kubernates-client-service-account
  namespace: kubernetesclient
---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: kubernates-client-cluster-role-binding
subjects:
  - kind: ServiceAccount
    name: kubernates-client-service-account
    namespace: kubernetesclient
roleRef:
  kind: ClusterRole
  name: cluster-admin
  apiGroup: rbac.authorization.k8s.io

Future actual combat, SpringBoot application will be deployed in the name kubernetesclient under the namespace, using the name kubernates-Client-Service-the Account Service of the Account;

IEDA install plugin

Because Slf4j annotations are used in the project , please install the lombok plugin on IEDA , otherwise there will be a red cross when writing log-related code:
Insert picture description here

Create the parent project of all java applications

To create multiple SpringBoot applications in the following actual combat, it is necessary to create a parent maven project in advance, and place the definition and version of the dependent library here;
Create a maven project named kubernetesclient , pom.xml is as follows:

<?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 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <parent>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-parent</artifactId>
        <version>2.3.1.RELEASE</version>
        <relativePath/> <!-- lookup parent from repository -->
    </parent>

    <groupId>com.bolingcavalry</groupId>
    <artifactId>kubernetesclient</artifactId>
    <version>1.0-SNAPSHOT</version>
    <packaging>pom</packaging>

    <modules>
        <module>helloworld</module>
        <module>outsidecluster</module>
    </modules>

    <properties>
        <java.version>1.8</java.version>
    </properties>

    <dependencies>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-test</artifactId>
            <scope>test</scope>
            <exclusions>
                <exclusion>
                    <groupId>org.junit.vintage</groupId>
                    <artifactId>junit-vintage-engine</artifactId>
                </exclusion>
            </exclusions>
        </dependency>
    </dependencies>

    <dependencyManagement>

        <dependencies>
            <dependency>
                <groupId>io.kubernetes</groupId>
                <artifactId>client-java</artifactId>
                <version>7.0.0</version>
                <scope>compile</scope>
            </dependency>
        </dependencies>

    </dependencyManagement>
</project>

Since this is a parent project, there is currently no other content except pom.xml. Subprojects will be added to it in the actual combat later;

Full range of source downloads

An ordinary SpringBoot project was used in this actual combat. The source code can be downloaded on GitHub. The address and link information are shown in the following table (https://github.com/zq2599/blog_demos):

name	link	Remarks
Project homepage	https://github.com/zq2599/blog_demos	The project's homepage on GitHub
git warehouse address (https)	https://github.com/zq2599/blog_demos.git	The warehouse address of the project source code, https protocol
git warehouse address (ssh)	[email protected]:zq2599/blog_demos.git	The warehouse address of the source code of the project, ssh protocol

There are multiple folders in this git project. The application of this chapter is under the kubernetesclient folder, as shown in the red box below:

The above is the preparatory work before the actual combat, thank you for your attention, the actual combat will be more exciting later;