Summary and best practices

In this closing section you bring together what you learned in the training, explore production best practices — RKE2 maintenance, Rancher’s centralized management, the basics of RBAC security, and resource limits — and finally clean up the exercise resources. The section ends with an open Q&A.

1. Training summary

During the training you went through the fundamentals of Kubernetes in a hands-on way:

• Architecture – orchestration, the declarative model, and the reconciliation loop.
• Management and RKE2 – the control plane, worker nodes, and RKE2’s server/agent structure.
• Networking and add-ons – Service types, CoreDNS, CNI, and Ingress.
• Configuration and state – ConfigMaps, Secrets, and PV/PVC/StorageClass.
• Package management – Helm, Rancher Apps, Kustomize, and everyday tools.

All of these are managed through the same kube-apiserver — both kubectl and Rancher.

2. RKE2 upgrades and maintenance

RKE2 is designed to be easy to maintain:

• etcd backups – RKE2 takes automatic snapshots. Make sure they are also stored outside the cluster (e.g. S3).
• Upgrades – done in a controlled manner one node at a time (rolling upgrade). Rancher can handle upgrades centrally.
• Node maintenance – take a node out of service safely before maintenance:

# Estä uudet Podit solmulle ja siirrä olemassa olevat muualle
kubectl cordon <solmu>
kubectl drain <solmu> --ignore-daemonsets --delete-emptydir-data

# Palauta solmu käyttöön huollon jälkeen
kubectl uncordon <solmu>

💡 Practice recovery: a backup is only useful if the restore has been tested. Practice restoring from an etcd snapshot regularly.

3. Rancher’s centralized management

Rancher brings the management of multiple clusters into one place:

• Multi-cluster management – create, import, and manage RKE2 and other clusters.
• Projects and namespaces – group namespaces into projects and manage permissions at the project level.
• Permissions – Rancher binds users and groups to the clusters’ RBAC roles.
• Monitoring and logs – integrated monitoring (Prometheus/Grafana) and log collection.
• Fleet (GitOps) – distribute applications and configuration to many clusters from Git.

4. Security: RBAC basics

RBAC (Role-Based Access Control) defines who may do what and where. Four basic concepts:

• Role – a set of permissions within a single namespace.
• ClusterRole – permissions at the whole-cluster level.
• RoleBinding / ClusterRoleBinding – binds a role to a user, a group, or a ServiceAccount.

flowchart LR
    U[User / ServiceAccount] --> RB[RoleBinding]
    RB --> R[Role]
    R --> P[Permissions:<br/>get, list, create, delete ...]

Example: allow reading Pods in your own namespace:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: <oma-nimi>
  name: pod-reader
rules:
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: <oma-nimi>
subjects:
  - kind: User
    name: matti
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

⚠️ Follow the principle of least privilege: grant only the permissions that are actually needed. Avoid handing out cluster-admin permissions.

5. Resource limits: requests and limits

For every container it is worth defining resource requests and limits:

• requests – how much CPU/memory the container reserves at minimum. The scheduler uses this for the placement decision.
• limits – a hard upper limit. Exceeding memory leads to the container being killed (OOMKilled); CPU is throttled (throttling).

resources:
  requests:
    cpu: "100m"       # 0,1 CPU-ydintä
    memory: "128Mi"
  limits:
    cpu: "500m"
    memory: "256Mi"

At the namespace level, limits can be enforced:

• ResourceQuota – limits the combined resource usage of a namespace.
• LimitRange – sets default and maximum values for individual containers.

💡 Without requests and limits values, one application can consume all of a node’s resources. They are the foundation of production stability.

6. Best practices (checklist)

• Use your own namespaces and clear labels to group resources.
• Always define requests/limits and health checks (liveness/readiness).
• Manage configuration with ConfigMaps and secrets with Secrets (+ etcd encryption).
• Use the declarative approach (kubectl apply, Helm, GitOps) — avoid editing by hand.
• Pin container images to versioned tags, not the latest tag.
• Follow RBAC’s principle of least privilege.
• Ensure etcd backups and test the restore.

7. Hands-on: cleaning up resources

Clean up the resources created during the training both from the command line and from Rancher.

1. See what is in your namespace:

kubectl get all -n <oma-nimi>

2. Remove Helm releases and individual resources as needed:

# Helmillä asennetut sovellukset
helm list -n <oma-nimi>
helm uninstall web -n <oma-nimi>

# Yksittäiset resurssit
kubectl delete deployment web -n <oma-nimi>

3. Delete your entire namespace — this removes all of its resources at once:

kubectl delete namespace <oma-nimi>

4. Clean up from Rancher:

1. Open Cluster Explorer and select your namespace.
2. Delete the remaining workloads or the whole namespace with the Delete action.
3. Check Apps → Installed Apps to make sure no installed releases are left.

5. Verify that no extra resources remain:

kubectl get namespaces

8. Q&A – open discussion

Let’s go through questions and consider how what you learned applies in your own environment. Good discussion topics:

• How does Kubernetes/RKE2 fit into your current infrastructure?
• Which applications would be worth moving to the cluster first?
• How are CI/CD, monitoring, and backups arranged?

Summary

• RKE2 maintenance relies on etcd backups, controlled upgrades, and node maintenance (cordon/drain).
• Rancher centralizes multi-cluster management, permissions, and monitoring.
• RBAC implements the principle of least privilege through roles and bindings.
• requests/limits ensure stable resource usage for applications.