DevOps Kubernetes Helm RBAC and Operators

After learning Kubernetes fundamentals, the next step is managing production-grade clusters effectively. This involves packaging Kubernetes applications with Helm, controlling access with RBAC, and automating complex operational tasks with Kubernetes Operators.

Helm – Kubernetes Package Manager

Helm is the package manager for Kubernetes. Just as apt installs software on Ubuntu and npm manages Node.js packages, Helm installs and manages complex Kubernetes applications.

A Helm chart is a collection of YAML templates with parameterized values. One chart can deploy the same application to dev, staging, and production with different configurations — just change the values file.

Why Helm?

• Packages complex multi-resource applications into a single deployable unit.
• Provides versioning and rollback for entire application releases.
• Enables configuration override with values files per environment.
• A public chart repository (Artifact Hub) provides ready-made charts for popular software.

Helm Chart Structure

myapp-chart/
├── Chart.yaml          # Chart metadata (name, version, description)
├── values.yaml         # Default configuration values
├── templates/
│   ├── deployment.yaml # Deployment template with {{ .Values.* }} placeholders
│   ├── service.yaml
│   ├── ingress.yaml
│   ├── configmap.yaml
│   └── _helpers.tpl    # Reusable template snippets
└── charts/             # Sub-chart dependencies

Chart.yaml

apiVersion: v2
name: myapp
description: My web application Helm chart
version: 1.2.0
appVersion: "2.5.1"

values.yaml

replicaCount: 3

image:
  repository: myrepo/webapp
  tag: "2.5.1"
  pullPolicy: IfNotPresent

service:
  type: ClusterIP
  port: 80

ingress:
  enabled: true
  host: myapp.example.com

resources:
  requests:
    memory: "128Mi"
    cpu: "100m"
  limits:
    memory: "256Mi"
    cpu: "500m"

env:
  DB_HOST: "mysql-service"
  LOG_LEVEL: "info"

templates/deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ include "myapp.fullname" . }}
spec:
  replicas: {{ .Values.replicaCount }}
  template:
    spec:
      containers:
        - name: webapp
          image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
          ports:
            - containerPort: 8080
          env:
            {{- range $key, $value := .Values.env }}
            - name: {{ $key }}
              value: {{ $value | quote }}
            {{- end }}
          resources:
            {{- toYaml .Values.resources | nindent 12 }}

Essential Helm Commands

# Install a chart as a release named "myapp-prod"
helm install myapp-prod ./myapp-chart -f values-production.yaml

# Upgrade an existing release
helm upgrade myapp-prod ./myapp-chart -f values-production.yaml

# Rollback to previous release version
helm rollback myapp-prod 2

# List all releases
helm list -A

# View release history
helm history myapp-prod

# Uninstall a release
helm uninstall myapp-prod

# Install from Artifact Hub (public chart)
helm repo add bitnami https://charts.bitnami.com/bitnami
helm install my-postgres bitnami/postgresql --set auth.postgresPassword=mypass

Kubernetes RBAC – Role-Based Access Control

RBAC controls who can do what inside a Kubernetes cluster. In production, nobody should have unrestricted cluster access. RBAC defines fine-grained permissions: which users and applications can read, create, update, or delete specific resources.

RBAC Core Objects

Example: Read-Only Role for Developers

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: developer-readonly
  namespace: production
rules:
  - apiGroups: [""]
    resources: ["pods", "services", "configmaps"]
    verbs: ["get", "list", "watch"]
  - apiGroups: ["apps"]
    resources: ["deployments", "replicasets"]
    verbs: ["get", "list", "watch"]

Binding the Role to a User

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: developer-readonly-binding
  namespace: production
subjects:
  - kind: User
    name: john.smith@company.com
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: developer-readonly
  apiGroup: rbac.authorization.k8s.io

ServiceAccount for CI/CD Pipeline

apiVersion: v1
kind: ServiceAccount
metadata:
  name: cicd-deployer
  namespace: production
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: deployer-role
  namespace: production
rules:
  - apiGroups: ["apps"]
    resources: ["deployments"]
    verbs: ["get", "update", "patch"]
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["get", "list"]

Kubernetes Operators

A Kubernetes Operator is a software extension that uses custom resources to manage applications and their components. Operators encode the operational knowledge of an experienced human operator into software.

For example, deploying a PostgreSQL database on Kubernetes manually requires: creating a StatefulSet, configuring persistent volumes, setting up replication, managing backups, handling failover, and upgrading versions — all complex operational tasks. A PostgreSQL Operator automates all of this.

How Operators Work

1. An Operator introduces a Custom Resource Definition (CRD) — a new resource type that Kubernetes doesn't know by default.
2. Users create instances of this custom resource (e.g., a PostgresCluster object).
3. The Operator's controller watches for these custom resources and takes action.
4. The Operator continuously reconciles the actual state with the desired state — like Kubernetes does natively, but for complex applications.

Example: Creating a PostgreSQL Cluster with an Operator

apiVersion: postgres-operator.crunchydata.com/v1beta1
kind: PostgresCluster
metadata:
  name: my-postgres
  namespace: production
spec:
  image: registry.developers.crunchydata.com/crunchydata/crunchy-postgres:ubi8-14.7
  postgresVersion: 14
  instances:
    - name: instance1
      replicas: 3
      dataVolumeClaimSpec:
        accessModes:
          - ReadWriteOnce
        resources:
          requests:
            storage: 50Gi
  backups:
    pgbackrest:
      repos:
        - name: repo1
          s3:
            bucket: my-postgres-backups
            region: us-east-1

The Operator reads this manifest and automatically creates a three-node PostgreSQL cluster with replication, automated backups to S3, and self-healing.

Popular Kubernetes Operators

Custom Resource Definitions (CRDs)

CRDs extend the Kubernetes API with new resource types. An operator installs CRDs when deployed. After that, teams interact with these custom resources using standard kubectl commands — the same way they work with built-in resources.

# List all CRDs in the cluster
kubectl get crd

# Describe a custom resource
kubectl describe postgrescluster my-postgres -n production

# Get all PostgreSQL clusters across namespaces
kubectl get postgresclusters -A

Summary

• Helm packages Kubernetes applications as versioned, parameterized charts — enabling environment-specific deployments with values overrides.
• RBAC enforces least-privilege access in Kubernetes — users and services get only the permissions they need.
• Roles and RoleBindings control namespace-level access. ClusterRoles cover the entire cluster.
• Kubernetes Operators extend Kubernetes to manage stateful, complex applications with the same declarative model as native resources.
• Operators encode deep operational knowledge — provisioning, scaling, backups, failover — into automated controllers.