This is the 11th day of my participation in the August More text Challenge. For details, see: August More Text Challenge
Write your own running chart that starts a SpringBoot service
The scaffold
The official demo is actually the best scaffolding. We only need to modify it according to the content in the demo and change it to the configuration we need
This demo chart deploys an Nginx container with a Deployment controller
Create scaffolding
# generate a chart package with the name mychartCopy the codeLooking at the directory tree structure, you can see the following
- Chart.yaml Describes the Chart package file
- Values.yaml Value definition file (very important)
- TLP help file
- Tip file after NOTES deployment
- Test file
[root@k8s-node1 mychart]# tree ├── charts ├─ chart.yaml ├── templates │ ├── deployment.yaml │ ├── helpers.tpl │ ├── ├── notes.txt │ ├── service.yaml │ ├── service.yaml │ ├─ tests │ ├─ The test - connection. Yaml └ ─ ─ values. The yamlCopy the codeComb structure
Next we will delete the files we don’t need first, because we are building a Chart that SpringBoot is running, and we are not going to use ingresss, and only use NodePort to provide access. And run directly online without testing. In addition, this service does not involve permissions, it is just a small interface, so the following files will be deleted
Delete the following files
│ ├── hpa.yaml │ ├── ingress.yaml │ ├── serviceaccount. Yaml │ ├─ tests │ ├─ test-connectionCopy the codeAfter deleting the structure
Configuration File Analysis
Profile by profile, step by step how to modify and understand the profile
Chart.yaml
Look at the chart.yaml file and filter out the comment files that start with Spaces and # to show the main content
[root@k8s-node1 mychart]# cat Chart.yaml | grep -v ^# | grep -v ^$
apiVersion: v2
name: mychart
description: A Helm chart for Kubernetes
type: application
version: 0.1. 0
appVersion: "1.16.0"
Copy the code- ApiVersion HelM3 Compatible APIS
- Name Chart Indicates the package name
- Description Describes the chart, for example, the SpringBoot interface
- Type Type (database, application, middleware, etc)
- Version Current version of the chart
- AppVersion is the version of the app. Let’s say we just started this project. Write a 0.1 or something like that
values.yaml
Look at the chart.yaml file, again filtering out the comment files that start with Spaces and # to show the main content
[root@k8s-node1 mychart]# cat values.yaml | grep -v ^# | grep -v ^$ | grep -v "#"
replicaCount: 1
image:
repository: nginx
pullPolicy: IfNotPresent
tag: ""
imagePullSecrets: []
nameOverride: ""
fullnameOverride: ""
serviceAccount:
create: true
annotations: {}
name: ""
podAnnotations: {}
podSecurityContext: {}
securityContext: {}
service:
type: ClusterIP
port: 80
ingress:
enabled: false
className: ""
annotations: {}
hosts:
- host: chart-example.local
paths:
- path: /
pathType: ImplementationSpecific
tls: []
resources: {}
autoscaling:
enabled: false
minReplicas: 1
maxReplicas: 100
targetCPUUtilizationPercentage: 80
nodeSelector: {}
tolerations: []
affinity: {}
Copy the codeThe YAML file is all the values required by the configuration file in the template directory. Since we have deleted hPA,ingress, and service account, these three parts of the configuration file can also be deleted
Only the number of controller copies, mirroring, service access mode, and port configuration are left. Other configurations are null
service.yaml
Service is the service configuration in K8s, just using the helm configuration file syntax, but a lot of it is easy to see at a glance
[root@k8s-node1 mychart]# cat templates/service.yaml
apiVersion: v1
kind: Service
metadata:
name: {{ include "mychart.fullname".}}labels:
{{- include "mychart.labels" . | nindent 4 }}
spec:
type: {{ .Values.service.type }}
ports:
- port: {{ .Values.service.port }}
targetPort: http
protocol: TCP
name: http
selector:
{{- include "mychart.selectorLabels" . | nindent 4 }}
Copy the codedeployment.yaml
The same is true for Deployment in K8S, where helm syntax is also used, and because we have removed the values section,
If you don’t know how to delete it, you can use Helm Lint to check the syntax first. How many lines will it give you
If affinity and tolerance are not configured, you can delete them
apiVersion: apps/v1
kind: Deployment
metadata:
name: {{ include "mychart.fullname".}}labels:
{{- include "mychart.labels" . | nindent 4 }}
spec:
replicas: {{ .Values.replicaCount }}
selector:
matchLabels:
{{- include "mychart.selectorLabels" . | nindent 6 }}
template:
metadata:
{{- with .Values.podAnnotations }}
annotations:
{{- toYaml . | nindent 8 }}
{{- end }}
labels:
{{- include "mychart.selectorLabels" . | nindent 8 }}
spec:
{{- with .Values.imagePullSecrets }}
imagePullSecrets:
{{- toYaml . | nindent 8 }}
{{- end }}
securityContext:
{{- toYaml .Values.podSecurityContext | nindent 8 }}
containers:
- name: {{ .Chart.Name }}
securityContext:
{{- toYaml .Values.securityContext | nindent 12 }}
image: "{{ .Values.image.repository }}:{{ .Values.image.tag | default .Chart.AppVersion }}"
imagePullPolicy: {{ .Values.image.pullPolicy }}
ports:
- name: http
containerPort: 80
protocol: TCP
livenessProbe:
httpGet:
path: /
port: http
readinessProbe:
httpGet:
path: /
port: http
resources:
{{- toYaml .Values.resources | nindent 12 }}
{{- with .Values.nodeSelector }}
nodeSelector:
{{- toYaml . | nindent 8 }}
{{- end }}
{{- with .Values.affinity }}
affinity:
{{- toYaml . | nindent 8 }}
{{- end }}
{{- with .Values.tolerations }}
tolerations:
{{- toYaml . | nindent 8 }}
{{- end }}
Copy the codeNOTES.txt
Next we render, but don’t actually deploy
helm install --debug --dry-run testchart .
Copy the codeThe NOTES section that appears at the end is the content defined in notes.txt, which is the usage description file after the application is deployed, as well as the previous deletion of values. Yaml
You can use helm Lint to locate the line count
_helpers.tpl
A template definition file is abstracted from places that use the same content
You can see a lot of the define keyword, which will be inserted into the Service and Deployment profiles with the include keyword
Example labels
{{/*
Common labels
*/}}
{{- define "mychart.labels" -}}
helm.sh/chart: {{ include "mychart.chart" . }}
{{ include "mychart.selectorLabels".}} {{-if .Chart.AppVersion }}
app.kubernetes.io/version: {{ .Chart.AppVersion | quote }}
{{- end }}
app.kubernetes.io/managed-by: {{ .Release.Service }}
{{- end }}
Copy the codespringboot-chart
The next step is to transform into the Chart package for the SpringBoot application that we’re going to use
1. Modify the chart. yaml configuration options
Change the name, description, and app version
name: springboot-api
description: springboot small api
appVersion: "1.0.0"
Copy the code2. Modify the values. Yaml configuration option
Change the image name and address, as well as the service access. Our SpringBoot is port 8080, which is changed to 2 to distinguish the number of copies
replicaCount: 2
image:
repository: springboot
tag: v1
service:
type: NodePort
port: 8080
Copy the code3. Modify the Deployment.yaml configuration options
Because all values of service.yaml are in values. Therefore, there is no need to change it here, just change deployment directly
Just change the containerPort to delete the livenessProbe: readinessProbe: not two rows.
containerPort: 8080
Copy the codeAt this point, a simple configuration chart package is modified. Next, use helm Lint to check the configuration, using helm install –debug –dry-run testchart. Render Debug runs directly without being used
Deploying the Testchart name directly can also be a little more semantic, such as test-order-api
helm install --debug --dry-run testchart .
Copy the code
As you can see, the service deployment is successful and the interface is accessible using cluster IP:31928
conclusion
Making the Chart package involves the Kubernetes YAML configuration and the helm template syntax, which requires practice to master
If you want to learn how the titans write chart packs, check out the templates for Artifact Hub