Shulou(Shulou.com)05/31 Report--

This article will explain in detail how to make a Helm chart for Kubernetes. The editor thinks it is very practical, so I share it for you as a reference. I hope you can get something after reading this article.

Create a Helm chart

First confirm that we have installed the prerequisites.

$which helm # # this can be in any folder as long as it returns in the path/usr/local/bin/helm$ minikube status # # if it shows Stopped, run `minikube start`host: Runningkubelet: Runningapiserver: Runningkubeconfig: Configured

A simple command is required to start a new Helm chart:

$helm create mychartname

For this tutorial, name the chart buildachart:

$helm create buildachartCreating buildachart$ ls buildachart/Chart.yaml charts/ templates/ values.yaml

Check the structure of the chart

Now that you have created the chart, look at its structure to see the internal contents. The first two files you see, Chart.yaml and values.yaml, define the contents of the chart and the values in it at deployment time. Looking at Chart.yaml, you can see the outline of the Helm chart structure:

ApiVersion: v2name: buildachartdescription: A Helm chart for Kubernetes# A chart can be either an 'application' or a' library' chart.## Application charts are a collection of templates that can be packaged into versioned archives# to be deployed.## Library charts provide useful utilities or functions for the chart developer. They're included as# a dependency of application charts to inject those utilities and functions into the rendering# pipeline. Library charts do not define any templates and therefore cannot be deployed.type: application# This is the chart version. This version number should be incremented each time you make changes# to the chart and its templates, including the app version.version: 0.1.0# This is the version number of the application being deployed. This version number should be# incremented each time you make changes to the application.appVersion: 1.16.0

The first part includes the API version that the chart is using (this is required), the name of the chart, and the description of the chart. The next section describes the type of chart (application by default), the version of the chart to be deployed, and the version of the application (which should be incremented when changes are made).

The most important part of the chart is the template directory. It contains all the configurations of the applications that will be deployed to the cluster. As shown below, the application has basic deployment, portals, service accounts, and services. The directory also includes a test directory, which includes a test to test the connection to the application. Each of these application functions has its own template file under templates /:

$ls templates/NOTES.txt _ helpers.tpl deployment.yaml ingress.yaml service.yaml serviceaccount.yaml tests/

There is another directory, called the chart, which is empty. It allows you to add the dependency diagrams required to deploy the application. Some Helm diagrams for applications require up to four additional diagrams to be deployed with the main application. When this happens, the value file is updated with the values of each chart to configure and deploy the application at the same time. This is a much more advanced configuration (I won't cover it in this introductory article), so leave the chart / folder blank.

Understand and edit valu

The format of the template file collects deployment information from the values.yaml file. Therefore, to customize the Helm chart, you need to edit the values file. By default, the values.yaml file looks like this:

# Default values for buildachart.# This is a YAML-formatted file.# Declare variables to be passed into your templates.replicaCount: 1image:repository: nginxpullPolicy: IfNotPresentimagePullSecrets: [] nameOverride: "" fullnameOverride: "" serviceAccount: # Specifies whether a service account should be createdcreate: true # Annotations to add to the service accountannotations: {} # The name of the service account to use. # If not set and create is true A name is generated using the fullname templatename:podSecurityContext: {} # fsGroup: 2000securityContext: {} # capabilities: # drop: #-ALL # readOnlyRootFilesystem: true # runAsNonRoot: true # runAsUser: 1000service:type: ClusterIPport: 80ingress:enabled: falseannotations: {} # http://kubernetes.io/ingress.class: nginx # http://kubernetes.io/tls-acme: "true" hosts:- host: chart-example.localpaths: [] tls: [] #-secretName: chart -example-tls # hosts: #-chart-example.localresources: {} # We usually recommend not to specify default resources and to leave this as a conscious # choice for the user. This also increases chances charts run on environments with little # resources, such as Minikube. If you do want to specify resources, uncomment the following # lines, adjust them as necessary, and remove the curly braces after 'resources:'. # limits: # cpu: 100m # memory: 128Mi # requests: # cpu: 100m # memory: 128MinodeSelector: {} tolerations: [] affinity: {}

Basic configuration

From the top, you can see that copyingCount is automatically set to 1, which means that only one pod will appear. In this example, you only need one Pod, but you can see how easy it is to tell Kubernetes to run multiple Pod to achieve redundancy.

The image section has two things you need to see: library where you pull your image and pullPolicy. PullPolicy is set to IfNotPresent; this means that if the image does not exist in the cluster, the image will download a new version of the image. There are two other options: Always, which means that it will extract the image every time it is deployed or restarted (which I always recommend if the image fails) and Latest, which will always extract the latest version. Available images. If you believe that the image repository is compatible with the deployment environment, the latest news may be useful, but not always.

Change the value to Always.

Before:

Image:repository: nginxpullPolicy: IfNotPresent

Later:

Image:repository: nginxpullPolicy: Always

Naming and encryption

Next, look at the overrides in the chart. The first alternative is imagePullSecrets, which is the setting to extract secrets (for example, a password or API key that you have generated as the credentials of a private registry). Then there are nameOverride and fullnameOverride. From the moment you take control of create, its name (buildachart) is added to many configuration files-from the YAML file above to the templates / helper.tpl file. If you need to rename the chart after creating the chart, this section is the best place to do so, so you won't miss any configuration files.

Use overrides to change the name of the chart.

Before:

ImagePullSecrets: [] nameOverride: "" fullnameOverride: ""

Later:

ImagePullSecrets: [] nameOverride: "cherry-awesome-app" fullnameOverride: "cherry-chart"

Account setting

The service account provides a user identity that can be run in the Pod within the cluster. If left blank, the helpers.tpl file is used to generate the name based on the full name. I recommend that you always set up a service account so that the application will be directly associated with the users controlled in the diagram.

As an administrator, if you use the default service account, there will be too few or too many permissions, so change this setting.

Before:

ServiceAccount: # Specifies whether a service account should be createdcreate: true # Annotations to add to the service accountannotations: {} # The name of the service account to use. # If not set and create is true, a name is generated using the fullname templateName:

Later:

ServiceAccount: # Specifies whether a service account should be createdcreate: true # Annotations to add to the service accountannotations: {} # The name of the service account to use. # If not set and create is true, a name is generated using the fullname templateName: cherrybomb

Security settin

You can configure pod security to set the type of file system group to use or the restrictions on which users can and cannot be used. Understanding these options is important for protecting the Kubernetes pod, but I won't repeat it for this example.

PodSecurityContext: {} # fsGroup: 2000securityContext: {} # capabilities: # drop: #-ALL # readOnlyRootFilesystem: true # runAsNonRoot: true # runAsUser: 1000

Networking Settin

There are two different types of network options in this chart. A network of local services with ClusterIP addresses that exposes services on IP within the cluster. Select this value to make the services associated with your application accessible only from within the cluster (and through ingress, set to false by default). Another network option is NodePort, which exposes services on statically assigned ports on the IP address of each Kubernetes node. It is recommended that you use this option to run minikube, so you can use it for this method.

Before:

Service:type: ClusterIPport: 80ingress:enabled: false

Later:

Service:type: NodePortport: 80ingress:enabled: false

Resource Settin

Helm allows you to explicitly allocate hardware resources. You can configure the maximum amount of resources that an Helm chart can request and the maximum limits that can be received. Because I use Minikube on my laptop, I'll set some limits by removing curly braces and hash values (converting comments to commands).

Before:

Resources: {} # We usually recommend not to specify default resources and to leave this as a conscious# choice for the user. This also increases chances charts run on environments with little# resources, such as Minikube. If you do want to specify resources, uncomment the following# lines, adjust them as necessary, and remove the curly braces after 'resources:'.# limits:# cpu: 100m# memory: 128Mi# requests:# cpu: 100m# memory: 128Mi

Later:

Resources: # We usually recommend not to specify default resources and to leave this as a conscious # choice for the user. This also increases chances charts run on environments with little # resources, such as Minikube. If you do want to specify resources, uncomment the following # lines, adjust them as necessary, and remove the curly braces after 'resources:'.limits:cpu: 100mmemory: 128Mirequests:cpu: 100mmemory: 128Mi

Tolerances, node selectors, and associativity

The last three values are based on the node configuration. Although I cannot use any of them in the local configuration, I will explain their purpose.

NodeSelector comes in handy when you want to allocate a portion of the application to a specific node in the Kubernetes cluster. If you have an infrastructure-specific application, you can set the node selector name and match it in the Helm diagram. Then, when the application is deployed, it will be associated with the node of the matching selector.

Tolerance, smudges, and affinity work together to ensure that Pod runs on separate nodes. Node affinity is the nature of pods that should attract them to a group of nodes (either as a preference or as a hard requirement). Stains, on the contrary, allow nodes to repel a set of pods.

In fact, if the node is contaminated, it means that the node is not working properly or may not have enough resources to accommodate the application deployment. The tolerance is set to the key / value pair monitored by the scheduler to confirm that the node will be used with the deployment.

Node similarity is conceptually similar to nodeSelector: it allows you to limit which nodes Pod can schedule based on the labels on the nodes. However, the tags are different because they match the rules that apply to schedule.

NodeSelector: {} tolerations: [] affinity: {}

Start deployment

Now that you have made the necessary changes to create the Helm diagram, you can deploy it using the Helm command, add a name point to the chart, add a value file, and send it to the namespace:

Helm install my-cherry-chart buildachart/-- values buildachart/values.yamlRelease "my-cherry-chart" has been upgraded. Happy Helming!

The output of this command provides you with the next steps to connect to the application, including setting up port forwarding so that you can access the application from the local host. To follow these instructions and connect to the Nginx load balancer:

$export POD_NAME=$ (kubectl get pods-l "http://app.kubernetes.io/name=buildachart,app.kubernetes.io/instance=my-cherry-chart"-o jsonpath=" {.items [0] .metadata.name} ") $echo" Visit http://127.0.0.1:8080 to use your application "Visit http://127.0.0.1:8080 to use your application$ kubectl port-forward $POD_NAME 8080:80Forwarding from 127.0.1 http://127.0.0.1:8080 8080-> 80Forwarding from [:: 1]: 8080-> 80

View deployed applications

To view your application, open the Web browser:

This is the end of this article on "how to make a Helm chart for Kubernetes". I hope the above content can be of some help to you, so that you can learn more knowledge. if you think the article is good, please share it out for more people to see.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.