[*]
Guaranteeing that you’re utilizing the most recent model of the Helm Charts software program that you simply set up in a Kubernetes cluster will help you keep away from recognized safety points and offer you entry to the most recent challenge options. If you’re utilizing Helm to handle your releases, this information will help you discover outdated or out of date Helm Charts operating in your cluster.
Whas is Helm?
Helm charts are a technique for managing and deploying purposes on Kubernetes. Helm itself is a package deal supervisor for Kubernetes, just like apt for Debian-based Linux distributions or yum for Purple Hat-based methods. The Helm charts are primarily packages of Kubernetes assets organized in a structured means.
Helm and Helm charts make it a lot simpler to handle purposes on Kubernetes. They supply a standardized strategy to describe and configure Kubernetes deployments and make it simpler to share, reuse and replace purposes.
Tutorial
On this article, we’ll create a PowerShell script to determine the put in Helm charts in a Kubernetes cluster and seek for the most recent model of the charts in our Helm repositories. The outcomes must be despatched in an e mail.
The PowerShell script must be executed in a Docker container for which we create a Docker picture and publish it as a CronJob in a Kubernetes cluster.
To offer our PowerShell script the required permissions in a Kubernetes cluster, we additionally create a service account with the corresponding authorization and position binding.
PowerShell Script: check-helm-chart
Create a brand new folder and a brand new PowerShell script there and put it aside as check-helm-charts.ps1ab. Then add the next content material to the script.
The script collects an outline of all put in Helm charts within the Kubernetes namespaces, compares their variations with the most recent out there ones, creates an HTML report and sends it by e mail.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 |
$smtpServer = $env:SMTP_SERVER $smtpPort = $env:SMTP_PORT $smtpUser = $env:SMTP_USER $smtpPassword = $env:SMTP_PASSWORD $recipientEmail = $env:RECIPIENT_EMAIL $helmRepos = $env:HELM_REPOS –break up ‘,’
$namespaces = $(kubectl get namespaces –o jsonpath=‘{.objects[*].metadata.identify}’).Cut up(” “)
$tableData = @()
foreach ($repo in $helmRepos) { $identify, $url = $repo –break up ‘=’ helm repo add $identify $url } helm repo replace
foreach ($namespace in $namespaces) { Write–Output “Namespace: $($namespace)” $installedCharts = helm listing —namespace $namespace —output json | ConvertFrom–Json foreach ($chart in $installedCharts) { $chartName = $chart.identify $currentChart = $chart.chart $currentVersion = ($chart.chart –change ‘^(.*)–([^–]+) |
Rationalization of the script
Step 1: Loading the atmosphere variables. At first you load numerous atmosphere variables. These variables comprise info such because the SMTP settings (server, port, consumer identify and password), the e-mail handle of the recipient and the Helm repositories that you simply need to examine:
$smtpServer, $smtpPort, $smtpUser, $smtpPassword: SMTP settings for sending emails.
$recipientEmail: The e-mail handle to which the report must be despatched.
$helmRepos: The listing of Helm repositories from which the put in Helm charts originate. These repositories are then looked for the most recent model, separated by commas.
Step 2: Namespace willpower, the script retrieves all Kubernetes namespaces and saves them in an inventory.
kubectl get namespaces returns all names of the namespaces.
Step 3: For every specified Helm repository, Helm provides an entry and updates the repository info. With helm repo add, Helm provides these repositories. helm repo replace ensures that Helm masses the most recent repository info.
Step 4: The method runs via the namespaces and determines the at present put in Helm charts for every namespace within the Kubernetes cluster. It extracts info for every chart, akin to identify, present model, app model, and standing, after which checks for the most recent model.
Step 5: Create a desk with the outcomes and easy HTML layouts. For every helmet chart discovered, the knowledge (namespace, identify, present model, app model, newest model, standing) is saved in a desk.
Step 6: Lastly, an e mail is shipped with the standing of the helmet charts.
Docker Deployment
In the identical folder, we create a .dockerfile with the next content material.
This Dockerfile creates a Docker picture based mostly on PowerShell and Ubuntu. It installs vital instruments such because the Azure CLI, kubectl and Helm. It then copies a PowerShell script into the container and executes the script when the container is began.
|
FROM mcr.microsoft.com/powershell:7.3–ubuntu–22.04 RUN apt–get replace && apt–get set up –y curl apt–transport–https gnupg && curl –sL https://aka.ms/InstallAzureCLIDeb | bash && curl –LO “https://storage.googleapis.com/kubernetes-release/launch/$(curl -s https://storage.googleapis.com/kubernetes-release/launch/secure.txt)/bin/linux/amd64/kubectl” && chmod +x ./kubectl && mv ./kubectl /usr/native/bin/kubectl && curl https://uncooked.githubusercontent.com/helm/helm/major/scripts/get-helm-3 | bash
COPY examine–helm–charts.ps1 /examine–helm–charts.ps1
WORKDIR /
CMD [“pwsh”, “/check-helm-charts.ps1”] |
Deployment
To entry a Kubernetes cluster from a container and have learn permissions to learn Helm releases, you could comply with a number of steps.
- Service account and RBAC: Arrange a service account with the corresponding authorizations.
- Configure kubectl in the container: Combine the service account so that the container can use it. Retrieve Helm releases: Use kubectl or helm to retrieve the releases.
Create a service account and configure RBAC
You want a service account with the corresponding roles and bindings to have learn entry to all assets within the cluster which are vital for studying the Helm releases.
Create the next helm-version-check-sa.yaml and put it aside within the /rbac subfolder.
|
# helm-version-check-sa.yaml apiVersion: v1 sort: ServiceAccount metadata: identify: helm–model–examine |
Create position and RoleBinding
The ClusterRole defines which assets and actions are permitted within the Kubernetes cluster. Create a ClusterRole helm-version-check-role.yaml additionally within the /rbac subfolder with the required learn rights.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
# helm-version-check-role.yaml apiVersion: rbac.authorization.k8s.io/v1 sort: ClusterRole metadata: identify: helm–model–examine guidelines: – apiGroups: [“”] assets: [“pods”, “services”, “endpoints”, “configmaps”, “secrets”, “namespaces”] verbs: [“get”, “list”] – apiGroups: [“apps”, “extensions”] assets: [“deployments”, “replicasets”, “statefulsets”] verbs: [“get”, “list”] – apiGroups: [“batch”] assets: [“jobs”, “cronjobs”] verbs: [“get”, “list”] – apiGroups: [“helm.sh”] assets: [“releases”] verbs: [“get”, “list”] |
We then create the required position binding helm-version-check-rolebinding.yaml once more within the /rbac subfolder; this ClusterRoleBinding hyperlinks the ClusterRole with our ServiceAccount. Which means the ServiceAccount can use the rights and authorizations of the ClusterRole.
|
# helm-version-check-rolebinding.yaml apiVersion: rbac.authorization.k8s.io/v1 sort: ClusterRoleBinding metadata: identify: helm–model–examine–binding roleRef: apiGroup: rbac.authorization.k8s.io sort: ClusterRole identify: helm–model–examine topics: – sort: ServiceAccount identify: helm–model–examine |
In our case, the duty of evaluating Helm chart variations belongs in monitoring. We due to this fact publish the assets we’ve got simply created within the monitoring namespace.
|
kubectl apply –f ./rbac/*.yaml –n monitoring |
K8S Deployment als CronJob
The final step is to create the CronJob helm-check-version.yaml with the next content material.
This CronJob executes a job each Monday at 7:00 am. It begins a Docker container that works with the desired Helm repositories and checks the variations. If the duty fails, it’s retried as much as 4 occasions. The job makes use of the ServiceAccount simply created to entry the required assets within the cluster and sends the outcomes by e mail to the configured handle.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 |
apiVersion: batch/v1 sort: CronJob metadata: identify: helm–model–examine spec: concurrencyPolicy: Forbid schedule: “0 7 * * 1” jobTemplate: spec: template: spec: serviceAccountName: helm–model–examine containers: – identify: helm–model–examine picture: artifactory.fa01.internet/docker–native/helm–model–examine:v1.0.6 env: – identify: SMTP_SERVER worth: “smtp.office365.com” – identify: SMTP_PORT worth: “587” – identify: SMTP_USER worth: “<USERNAME>” – identify: SMTP_PASSWORD worth: “<PASSWORD>” – identify: RECIPIENT_EMAIL worth: “<DENNIS.RUPP@FIRSTATTRIBUTE.COM>” – identify: HELM_REPOS worth: “jfrog=https://charts.jfrog.io,grafana=https://grafana.github.io/helm-charts,ingress-nginx=https://kubernetes.github.io/ingress-nginx,jetstack=https://charts.jetstack.io” restartPolicy: OnFailure backoffLimit: 4 – identify: SMTP_USER worth: “<USERNAME>” – identify: SMTP_PASSWORD worth: “<PASSWORD>” – identify: RECIPIENT_EMAIL worth: “<DENNIS.RUPP@FIRSTATTRIBUTE.COM>” – identify: HELM_REPOS worth: “jfrog=https://charts.jfrog.io,grafana=https://grafana.github.io/helm-charts,ingress-nginx=https://kubernetes.github.io/ingress-nginx,jetstack=https://charts.jetstack.io” restartPolicy: OnFailure backoffLimit: 4 |
After creating the useful resource, we switch it to our Kubernetes cluster with the next command:
|
kubectl apply –f ./helm–examine–model.yaml –n monitoring |
Abstract
This information exhibits the right way to develop a PowerShell script and deploy it as a CronJob in a Kubernetes cluster to seek out outdated Helm charts. The script checks put in Helm charts in a Kubernetes cluster, compares their variations with the most recent variations from outlined Helm repositories and sends the outcomes as an HTML report by e mail.
Implementation steps:
PowerShell script: Creates a report on put in Helm charts and their variations.
Docker container: The script is executed in a Docker container that installs PowerShell, kubectl and Helm.
ServiceAccount and RBAC: A ServiceAccount with acceptable permissions permits the script to entry Kubernetes assets.
CronJob: This executes the script weekly and sends an e mail with the outcomes. It makes use of the ServiceAccount and repeats itself as much as 4 occasions within the occasion of errors.
The mix of automated model checking and clear reporting by e mail retains the standing of the Helm charts clear. Corporations profit from a standardized and repeatable strategy that ensures Kubernetes deployments are up-to-date and safe.
FirstAttribute AG – Id Administration & IAM Cloud Providers
We’d be completely happy to current our providers and options to you. Get in contact and learn the way we will help you.
Did this allow you to? Share it or depart a remark:
Artikel erstellt am: 24.02.2025
[*]
