Installing Rancher on K3s

A kubeconfig is the file kubectl and helm read to find a cluster: its API server URL, a cluster CA certificate to trust, and your credentials. By convention it lives at ~/.kube/config.

On this playground the kubeconfig was placed on your workstation for you, already pointed at the cluster's network address - so you arrive ready to work, the way a consultant would after being handed credentials for an engagement.

In a Rancher-managed environment, the usual way to get one is to download it straight from the Rancher UI: Rancher generates a kubeconfig scoped to your permissions and pointed at the right endpoint. You will see exactly where to do that in the next lesson.

Helm is the package manager for Kubernetes - think apt or brew, but for Kubernetes applications. Instead of applying a pile of individual YAML manifests by hand, you install a chart: a versioned, parameterized package that bundles all the resources an application needs.

The pieces you will use in this lesson:

• Chart - the package itself (for example, cert-manager or rancher), describing all the Kubernetes objects to create.
• Repository - a place charts are published and pulled from. helm repo add registers one (like adding a package source).
• Release - a specific install of a chart into your cluster, with a name you choose. helm install rancher ... creates a release called rancher.
• Values - the knobs you tune with --set, such as --set hostname=rancher.localhost. They let one chart produce different configurations without editing its templates.

Helm is a graduated CNCF project and comes pre-installed on your workstation, so it is ready to use. Every install step in this lesson is a helm install - you are packaging-managing Rancher and its prerequisites rather than hand-writing manifests.

Traefik is an open-source reverse proxy and ingress controller first released in 2015 by Traefik Labs (formerly Containous), a company founded by Emile Vauge. It was one of the first proxies designed for dynamic, container-native environments, discovering services automatically instead of relying on static configuration files.

A few facts that matter here:

• It is K3s's default ingress controller. K3s bundles Traefik out of the box, which is why this cluster can route external traffic to Rancher without you installing anything extra.
• Automatic service discovery. Traefik watches the Kubernetes API (and other providers) and reconfigures its routes on the fly as Ingress resources appear or change - no reloads required.
• Ingress class traefik. When you install Rancher later in this lesson, you point its Ingress at this controller with the traefik ingress class.
• Written in Go. Like Kubernetes and K3s themselves, Traefik is written in Go, which keeps it lightweight and easy to ship as a single binary - a good match for K3s's small footprint.

You do not need to configure Traefik in this course; it simply provides the front door through which you will reach the Rancher UI.

NGINX is an equally valid choice, and in many Rancher installations it is the ingress controller people reach for. It began as a web server and reverse proxy written by Igor Sysoev, first released in 2004, and quickly became one of the most widely deployed web servers in the world thanks to its event-driven design and low memory footprint. The company behind it, NGINX Inc., was acquired by F5 in 2019, and the project continues as both an open-source server and commercial products.

In the Kubernetes world, the community ingress-nginx controller wraps NGINX as an Ingress controller. It is mature, heavily documented, and the default many Rancher guides assume - Rancher's own docs frequently show installing ingress-nginx before Rancher on clusters that ship without an ingress controller.

So why does this course use Traefik instead?

• It is already here. This K3s playground ships Traefik enabled, so there is nothing extra to install. Adding ingress-nginx would mean installing and configuring a second controller for no real benefit in this environment.
• Fewer moving parts. One ingress controller keeps the lesson focused on Rancher rather than on ingress setup.
• The concepts transfer. Whether the controller is Traefik or NGINX, Rancher creates a standard Kubernetes Ingress; only the ingress class name changes (traefik vs nginx). What you learn here applies directly to an NGINX-based cluster.

If you later install Rancher on a cluster that uses NGINX, the only real difference is setting --set ingress.ingressClassName=nginx and installing ingress-nginx first.

Jetstack is the name in the Helm repository URL (charts.jetstack.io), and it is worth knowing why it is there. Jetstack was a UK-based Kubernetes consultancy that created cert-manager, the project you are about to install. cert-manager became the de facto standard for automating TLS certificate issuance and renewal in Kubernetes - talking to issuers like Let's Encrypt, HashiCorp Vault, or a cluster's own self-signed CA, and keeping certificates rotated before they expire.

A few relevant facts:

• Acquired by Venafi (2020), then part of CyberArk. Jetstack was acquired by the machine-identity company Venafi in 2020; Venafi itself was later acquired by CyberArk. The Helm repository kept the historical jetstack name.
• cert-manager is a CNCF project. It was donated to the Cloud Native Computing Foundation and is maintained in the open, independent of any single vendor.
• Why Rancher needs it. Rancher serves its UI and API over HTTPS. cert-manager provisions and renews the certificate behind that endpoint - which is why it must be installed before Rancher.

So jetstack/cert-manager simply means "the cert-manager chart, published in the repository historically maintained by Jetstack." You are installing cert-manager, not a separate Jetstack product.

Kubernetes ships with built-in object types like Pods, Deployments, and Services. A Custom Resource Definition (CRD) lets a project teach the Kubernetes API about brand-new object types of its own.

Once a CRD is installed, the cluster understands those new objects and you can create and manage them with kubectl exactly like the built-in ones. cert-manager, for example, adds types such as Certificate, Issuer, and ClusterIssuer - so you can request a certificate by writing a Certificate object, and cert-manager's controller does the rest.

That is why --set crds.enabled=true matters: it installs those definitions so the rest of cert-manager (and later Rancher, which relies on them) has the object types it needs. CRDs are the standard way tools extend Kubernetes without modifying Kubernetes itself.

This course installs the community edition of Rancher, published from releases.rancher.com. It is free and open source under the Apache License 2.0, which permits using, modifying, and distributing the software freely. There is no license key, trial period, or usage restriction - it is the same Rancher codebase maintained in the open at github.com/rancher/rancher.

SUSE also offers a separate commercial product, SUSE Rancher Prime, which adds enterprise support, hardened images, and extra features on top of the same core. This course does not install Rancher Prime and does not require any SUSE subscription.

In short: everything you do here uses freely licensed, open-source software.

This is a general summary of the projects' public licensing, not legal advice.

Rancher serves its UI and API over HTTPS, so it always needs a TLS certificate. The ingress.tls.source value chooses where that certificate comes from, and there are three options worth knowing because the right one depends on the environment:

• rancher - Rancher-generated self-signed (what this course uses). Rancher creates its own Certificate Authority and issues its own certificate through cert-manager. It has no external dependencies, works offline, and comes up immediately. The tradeoff is that nothing outside the cluster trusts that CA by default, so browsers show a certificate warning, and any cluster you later import has to be given Rancher's CA so its agent can trust the connection. This is the standard quick-start and proof-of-concept choice.
• letsEncrypt - a real, publicly trusted certificate. cert-manager requests a certificate from Let's Encrypt, which is trusted by browsers automatically, so there are no warnings and no CA to distribute. It requires a real public DNS name for Rancher and inbound reachability so Let's Encrypt can validate the domain. This is a common choice for internet-facing Rancher installations.
• secret - bring your own certificate. You supply a certificate issued by your organization's internal CA or a commercial CA, stored in a Kubernetes secret. This suits enterprise and private or air-gapped environments where machines already trust the corporate CA and Rancher sits behind a load balancer.

Which one resembles production? There is no single answer - it splits by environment. Internet-facing Rancher tends toward Let's Encrypt; enterprise or private Rancher tends toward bring-your-own with a corporate CA. Self-signed is the outlier: excellent for learning, not intended for production. We use it here precisely because a throwaway playground has no public DNS and no corporate CA, and because it makes the certificate-trust flow visible - something you will see directly in Module 3 when an imported cluster's agent has to trust this self-signed CA to connect.

This is a general summary of Rancher's TLS options, not a security recommendation for any specific deployment.

The Rancher you just installed is the free, open-source community edition. SUSE's commercial offering, Rancher Prime, is built on the same core and adds enterprise-oriented extras. The everyday management experience is nearly identical - the differences matter mostly for production and support, not for learning.

For learning, experimentation, and even many production setups, the community edition is fully capable. Rancher Prime is aimed at organizations that need vendor support, hardened supply-chain images, and contractual guarantees.

This is a general summary, not legal or purchasing advice.