Shulou(Shulou.com)06/02 Report--

Apply Mirror

The application image is the core of the chart package, and must include: image repository address, image name, image version. The values.yaml field specification is as follows:

Repository: hub: docker.io image: gitlab/gitlab-ce tag: 11.1.4-ce.0deployment reference: image: {{.Values.repository.hub}} / {{.Values.repository.image}}: {{.Values.repository.tag}}

Probe

The probe of the application is used to detect whether the application is healthy and ready to provide services. Health status is a critical attribute, so each application must clearly indicate how to conduct a health test.

The values.yaml file must contain the following probe attributes:

LivenessProbe: # Survival probe enabled: true path: / # APIs for heartbeat detection. Default is the number of seconds it takes for httpGet to request initialDelaySeconds: 30 # after the container starts to perform the probe for the first time. PeriodSeconds: 60 # how often the probe is performed. The default is 10 seconds, with a minimum of 1 second. TimeoutSeconds: 5 # probe timeout. Default 1 second, minimum 1 second. SuccessThreshold: after the 1 # probe fails, at least how many consecutive probes are successful before they are considered successful. The default is 1 failureThreshold: after the 5 # probe is successful, the minimum number of consecutive probe failures before it is considered a failure. Default is 3 readinessProbe: # ready probe enabled: true path: / # API for heartbeat detection, and default is httpGet request initialDelaySeconds: 10 periodSeconds: 10 timeoutSeconds: 5 successThreshold: 1 failureThreshold: 5

The deployment.yaml file reference probe is as follows:

{{- if .livenessProbe.enabled}} livenessProbe: initialDelaySeconds: {{.Values.livenessProbe.initialDelaySeconds}} periodSeconds: {{.Values.livenessProbe.timoutSeconds}} timeoutSeconds: {{.Values.livenessProbe.timeoutSeconds}} successThreshold: {{.Values.livenessProbe.failureThreshold}} failureThreshold: {{.Values.livenessProbe.failureThreshold}} httpGet: path: {{.Values.liv enessProbe.path}} port: http {{- threshold}} } {- if .readinessProbe.enabled}} readinessProbe: initialDelaySeconds: {{.Values.readinessProbe.initialDelaySeconds}} periodSeconds: {{.Values.readinessProbe.timeoutSeconds}} timeoutSeconds: {{.Values.readinessProbe.timeoutSeconds}} successThreshold: {{.Values.readinessProbe.timeoutSeconds}} failureThreshold: {{.Values.readinessProbe.failureThreshold}} httpGet: path: {{.Values.readinessProbe.failureThreshold} httpGet: {{.Values.readinessProbe.timeoutSeconds}} httpGet: {{- value}}

Resource restriction

Each application needs to use CPU and memory resources, which, if not specified, will lead to a fearless waste of resources and will be recycled as soon as resources are insufficient.

Therefore, applications should clearly state the amount of resources they need.

The values.yaml file contains the following attributes:

Resources: requests: # declares the least used resources. If it is not enough, the application cannot start successfully memory: 256Mi cpu: 100m limits: # declare the maximum used resources, and restart the application pod memory: 256Mi cpu: 100m if it exceeds

Persistent storage

If the application does not use persistent storage, all previously saved data will be emptied when the application is restarted. In web stateless applications, this is a good way to keep the environment clean.

But if our application has data that needs to be persisted, we need to use persistent storage. The following is the persistent storage specification:

The values.yaml file should contain the following attributes:

Persistence: enabled: true local: enabled: false # whether to enable local storage name: gitlab-pg # corresponds to the local storage name storageClass: "nfs-dynamic-class" # Cluster shared storage accessMode: ReadWriteOnce # Storage access mode size: 30Mi # declare the size of the required storage annotations: {}

Create a new auto-pvc.yaml file under the templates directory. The reason for adding an auto prefix here is to ensure that the installation pvc is executed first during installation. The default helm is the installation file name order to perform the installation.

The contents are as follows:

{{- if and .Values.persistence.enabled (not .Values.persistence.persistingClaim)}} kind: PersistentVolumeClaimapiVersion: v1metadata: name: {{.Release.Name}}-pvc {{- with .Values.persistence.annotatio ns}} annotations: {{toYaml. | indent 4} {{- end}} labels: app: {{.Release.Name}} spec: {{- if .Values.persistence.local.enabled}} volumeName: "{{- Values.persistence.local.name}}" {{- end}} accessModes:-{Values .persistence.accessMode | quote} resources: requests: storage: {{.Values.persistence.size | quote}} {{- Values.persistence.size | quote} {{- Values.persistence.size. Values.persistence.storageClass} {{- if (eq "-" .Values.persistence.storageClass)} storageClassName: "" {{- else}} storageClassName: "{{.Values.persistence.storageClass}}" {{- end} {{- end}} {{- end}}

Finally, according to the path of reading and writing required by the application, mount it to the container, modify the deployment.yaml file, and add the following:

Volumes:- name: data {{- if .Values.persistence.enabled} persistentVolumeClaim: claimName: {{.Release.Name}}-pvc {{- else}} emptyDir: {} {- end}}

# add to the containers sub-tag

VolumeMounts:- name: data mountPath: / mnt # the path to read and write in the application container

Local Stora

In the future, many applications need to support local storage. The modifications of local storage are as follows:

Values.yamlpersistence: enabled: true local: enabled: true # enable local storage name: gitlab-pg # corresponding to local storage name accessMode: ReadWriteOnce size: 20Gi storageClass: "-" # cancel shared storage annotations: {} nodeSelector: kubernetes.io/hostname: 10.160.144.72 # corresponding to local running host

Safety

Set the user running Pod. Generally speaking, for the sake of security, it is not recommended to use root user to run in the container. But if you need to use local storage, you have to run it using the root user.

In addition, when using shared storage, you can set usePodSecurityContext to false.

Set up to run as root, add to the values.yaml file:

Security: usePodSecurityContext: true runAsUser: 0 fsGroup: 0

Add to the deployment.yaml file:

{{- if .security.usePodSecurityContext}} securityContext: runAsUser: {{default 0 .Values.security.runAsUser}} {- if and (.Values.security.runAsUser) (.Values.security.fsGroup)}} fsGroup: {{.Values.security.fsGroup} {{- end}} {- Values.security.fsGroup} {- end}} {- Values.security.fsGroup} {- Values.securit

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.