This is the sixth day of my participation in the August More text Challenge. For details, see: August More Text Challenge

The name of the chart

In the previous chapter, we used helm install bitnami/nginx –generate-name to install nginx, but this installs nginx with a random number after the name. If I want to install mysql for three teams, one for each team. If you want to distinguish between names, it’s important to be semantic,

Here’s an example:

helm install cetner-nginx bitnami/nginx 
helm install message-nginx bitnami/nginx 
helm install order-nginx bitnami/nginx 
Copy the code

Chart Installation Process

When deploying k8s applications, especially complex applications, you need to apply for a lot of permissions, etc., because it is a custom YAML file, you want to install that step directly kubectl apply -f XXX. Yaml is available, but helm is not directly installed for you. So what’s the order of it

Helm installs resources in the following order:

  • Namespace
  • NetworkPolicy
  • ResourceQuota
  • LimitRange
  • PodSecurityPolicy
  • PodDisruptionBudget
  • ServiceAccount
  • Secret
  • SecretList
  • ConfigMap
  • StorageClass
  • PersistentVolume
  • PersistentVolumeClaim
  • CustomResourceDefinition
  • ClusterRole
  • ClusterRoleList
  • ClusterRoleBinding
  • ClusterRoleBindingList
  • Role
  • RoleList
  • RoleBinding
  • RoleBindingList
  • Service
  • DaemonSet
  • Pod
  • ReplicationController
  • ReplicaSet
  • Deployment
  • HorizontalPodAutoscaler
  • StatefulSet
  • Job
  • CronJob
  • Ingress
  • APIService

During installation, the Helm client prints some useful information, including which resources have been created, the current state of release, and whether you need to perform any additional configuration steps

State chart

The Helm client does not quit until all resources are running, and many Harts require Docker images over 500M in size, which can take a long time to install into a cluster

This is when you need to manually check the status

helm status center-nginx
Copy the code

You can see the deployment time, the deployed status is deployed, and you can also see the notes you’re using, so you don’t have to remember them at the beginning, just look them up

Chart modified configuration

There are a number of ways to change the chart configuration, and this is the way to use it in the Install chart

To change the configuration, you need to know what configuration the chart has, which is called values in the helm

Check values, because chart has a lot of configuration and comments, let’s filter it here

helm show values bitnami/nginx > vvv.yaml
cat vvv.yaml  | grep -v "#"
Copy the code

Create a values. Yaml file and write to it. Specify the file at install time

echo '{metrics.service.port: 9113, metrics.securityContext.runAsUser: 1001}' > values.yaml
helm install -f values.yaml bitnami/nginx 
Copy the code

The above operation can modify the configuration, but for the few configuration changes, it is troublesome, in fact, helm is directly provided to modify the configuration parameter -set

The cat VVV. Yaml | grep -v “#” | grep -c 3 image to view the image information

Change the image name or warehouse address during installation

Helm install bitnami/nginx \ --set metric.image. registry= XXXXCopy the code

Release

After Helm installs chart, the application is called release, and subsequent updates, rolling back, looking at history are all related to that

To view

helm history center-nginx

update

Change the nGINx version to 1.18

helm upgrade --set image.tag=nginx.18 center-nginx bitnami/nginx

View the changed values

helm get values center-nginx

The rollback

helm rollback center-nginx 2

conclusion

Helm is smarter and faster than release, which is the equivalent of traditional releases, where you have to write your own scripts and then maintain a bunch of history packages