> Source: https://meetrix.io/blogs/rancher-kubernetes-management-gcp/ > Markdown copy of that page. Cite the URL above, not this file. Development # Rancher Kubernetes Management on GCP Marketplace [By Shalomi Umeshika](https://meetrix.io/blogs/authors/shalomi-umeshika/) • October 15, 2026 • 10 min read ## Your Clusters Aren't All on GKE Most teams on Google Cloud start with one GKE cluster. Then a second one shows up for staging. Then someone runs K3s on a box in the office, a client hands over an EKS cluster, and suddenly there are four kubeconfig files in a shared drive and nobody's quite sure who has admin on what. The GKE console is good at GKE. It doesn't see anything else. Rancher does. **Rancher Kubernetes Management on GCP Marketplace** by Meetrix puts a working Rancher server in your own Google Cloud project, with K3s, Nginx, and a Let's Encrypt certificate already set up. You fill in a deployment form, point a DNS record, and log in. If you'd rather follow along with screenshots, the [Rancher on GCP developer guide](https://meetrix.io/blogs/rancher-gcp-developer-guide/) walks through every field. The Quick Verdict You only run GKE You may not need Rancher yet. The GKE console handles one cloud well. Rancher earns its place once clusters live in more than one place. GKE plus anything else Launch the Meetrix image, import every cluster, and give people one sign-in instead of a pile of kubeconfig files. You want to try it first The listing has a 5-day trial with up to USD 50 in licence credits. You still pay for the VM and disk. Production management plane Plan high availability. This image is one VM, and Rancher's docs call for at least three nodes in production. ## What Rancher Actually Does [Rancher](https://github.com/rancher/rancher) is SUSE's open-source Kubernetes management platform, released under Apache 2.0. One web dashboard, every cluster. The [Rancher docs](https://ranchermanager.docs.rancher.com/getting-started/overview) group them into three kinds: clusters Rancher provisions itself (RKE2 and K3s), hosted clusters on GKE, EKS, and AKS, and any existing cluster you import. The parts that matter day to day are less flashy. Central authentication, so people sign in with Active Directory or GitHub instead of passing kubeconfig files around. Role-based access across clusters and projects. A Helm chart catalog. Prometheus-based monitoring. And Fleet, which deploys apps from a Git repository to as many downstream clusters as you point it at. The current stable release is [v2.15.2](https://github.com/rancher/rancher/releases/tag/v2.15.2), published on September 23, 2026. It's a patch release that fixes a few security issues worth knowing about, including a vulnerability where logging out cleared browser cookies but didn't delete the server-side API session token, meaning a captured token stayed valid until it expired naturally (that one affects setups using public API session tokens, such as OIDC sign-in). There's also a fix for unauthenticated settings routes that could be modified by an attacker and executed on the login page. If you're running an older 2.15.x, upgrading is worth the time. Rancher 2.15.x supports Kubernetes v1.34 through v1.36 for RKE2 and K3s clusters, and the 2.15 line removed support for v1.33. Per [SUSE's lifecycle page](https://www.suse.com/lifecycle/), the 2.15 release line is maintained until February 27, 2027 and reaches end of life on February 27, 2028, so you've got runway. On Google Cloud, the obvious first move is importing your GKE clusters. After that, everything else you run (an EKS cluster, an on-prem K3s node, a client's AKS) shows up in the same list. Why run Rancher in your own GCP project Your cluster credentials, access policies, and Rancher configuration stay in a project you control, in a zone you pick. Rancher itself is open source. What you pay for is the Compute Engine VM and disk, plus the licence fee shown on the listing. ## Deploying Rancher on GCP Building this by hand means standing up a Kubernetes cluster just to host Rancher, installing it with Helm, then sorting out ingress, certificates, and a bootstrap password. The Meetrix image has all of that baked in. Here's the actual sequence: 1. **Launch from GCP Marketplace** Open the [Rancher listing](https://console.cloud.google.com/marketplace/product/meetrix-public/rancher), click Launch, pick your project, and accept the terms. Tick the trial checkbox at the bottom of the form if you want the 5-day trial. 2. **Fill In the Deployment Form** A deployment name, a service account, a zone close to the clusters you'll manage, and a machine type (leave it on e2-standard-2 unless you already know you'll manage a lot of nodes). Under Application Settings, enter your domain, an admin email for Let's Encrypt, and the admin password you'll use to log in. 3. **Point DNS at the VM** Copy the External IP from the VM's network interfaces and add an A record for your domain at whichever DNS provider you use. Let's Encrypt checks the domain over HTTP, so the record has to resolve before the certificate request runs. 4. **Log In and Import Your Clusters** Open your domain, enter the admin password on the Welcome to Rancher screen, and click Log in with Local User. Confirm the server URL. The local K3s cluster is already listed as Active, and Import Existing is where your GKE clusters come in. Two snags come up often enough to mention. A 502 on first visit just means K3s and the Rancher pods are still starting, so give it 5 to 10 minutes. And if Google says a zone doesn't have capacity for your machine type, pick a different zone and redeploy. If the certificate didn't issue because DNS was slow, SSH in and run the bundled certificate script. The exact command is in the [developer guide](https://meetrix.io/blogs/rancher-gcp-developer-guide/). ## Reserve a Static IP Before You Rely on It This is the one thing I'd change straight after deploying. The form leaves the external IP as Ephemeral. That's fine for a test. But Google's [IP address docs](https://docs.cloud.google.com/vpc/docs/ip-addresses) say an ephemeral address is released when you stop the VM. Start it again and it may come back with a different IP, which means your A record now points nowhere, and the agents on every downstream cluster can't reach the Rancher server URL until DNS catches up. The fix takes a minute. In VPC network, under IP addresses, [promote the ephemeral address to static](https://docs.cloud.google.com/vpc/docs/reserve-static-external-ip-address). Google says promotion doesn't drop traffic to the VM, so you can do it on a running server. A reserved static address carries its own small charge, so check current Compute Engine pricing. ## What the Meetrix Image Includes - **Rancher on K3s, already running.** Rancher is installed with the official Helm chart on a single-node K3s cluster, so you aren't building a cluster to host your cluster manager. - **Nginx and Let's Encrypt.** Nginx terminates SSL in front of Rancher, and the certificate is requested for the domain you entered on the form. A certificate script is there as a fallback. - **DNS anywhere.** It works with whichever DNS provider you already use, since the certificate check only needs your A record to resolve. - **A trial before you commit.** Five days and up to USD 50 in licence credits. Delete the deployment to cancel. - **A plain upgrade path.** When a newer version lands on the listing, back up, delete the old deployment from [Solution deployments](https://console.cloud.google.com/products/solutions/deployments), and launch the new one. - Support from people who built the image, at [support@meetrix.io](mailto:support@meetrix.io), with a reply within 12 hours. The [Rancher store page](https://meetrix.io/store/rancher/) has the AWS and GCP options side by side. One thing it doesn't do for you: backups. The AWS version of this image asks for an S3 bucket at launch. The GCP form doesn't ask for a backup location, so set one up yourself. The [Rancher Backups operator](https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/back-up-rancher) writes to S3-compatible storage or a persistent volume. On GCP, you can use a Persistent Volume Claim with a StorageClass that has a "Retain" reclaim policy, so the backup volume survives even if the application is deleted. Or point it at a GCS bucket through Cloud Storage's S3-compatible XML API with HMAC keys, and test a restore before you count on it. Do it before you've spent a week configuring users and projects, not after. ## Who Is Rancher on GCP Right For? The reader I have in mind is a platform engineer on Google Cloud whose cluster count just went past two, and who is tired of being the person everyone asks for a kubeconfig. It also fits: - Teams running GKE alongside clusters on another cloud or on-prem - Companies that want one sign-in and role-based access across every cluster - Agencies and MSPs managing clusters for several clients, with Fleet pushing the same apps from Git to each one - Anyone learning Kubernetes who wants a lab with a real management layer on top. The trial is enough for a weekend of poking at it. If you're serving models, Rancher is a tidy way to keep the GPU clusters in view. Our guides to [running open-weight LLMs on GKE](https://meetrix.io/blogs/open-weight-llms-gke/) and [GPU scheduling in Kubernetes](https://meetrix.io/blogs/gpu-scheduling-kubernetes/) cover the workload side. ## One VM, Honestly 1Compute Engine VM The Meetrix image runs Rancher on a single VM. Quick to launch, simple to run, and one point of failure for your management plane. Fine for a lab or a small team. Worth deciding on purpose before critical work depends on it. Rancher's [installation requirements](https://ranchermanager.docs.rancher.com/getting-started/installation-and-upgrade/installation-requirements) are clear: production needs a high-availability setup of at least three nodes. Three is the smallest cluster where etcd keeps quorum through the loss of one node. The same page says a single-node Docker install is only suitable for development or testing. What softens it: your downstream clusters keep running while the Rancher VM is down. GKE keeps serving traffic. You just can't manage anything through the dashboard until the VM is back. So reserve the static IP, set up backups, keep the VM patched, and plan HA before Rancher becomes something people can't work without. ## Rancher on GCP by Meetrix vs Alternatives | Feature | Rancher on GCP by Meetrix | Self-built Rancher | SUSE Rancher Prime | GKE console only | | --- | --- | --- | --- | --- | | Clusters it manages | GKE, EKS, AKS, RKE2, K3s, imported | Same as open-source Rancher | Same, with SUSE support | GKE only | | Time to first login | Minutes after DNS resolves | Longer: host cluster, Helm install, ingress and certificates are yours | Same install work, with vendor help | Already there | | High availability | Single VM; HA is yours to plan | Three or more nodes, as the docs require for production | Supported HA deployments | Managed by Google | | SSL | Let's Encrypt on deploy, script as fallback | You configure it | You configure it | Not applicable | | Support | Meetrix, support@meetrix.io | Community | SUSE enterprise support | Google Cloud support plans | | Pricing model | Compute Engine plus the listing's licence fee; 5-day trial | Infrastructure only | Per-core or per-socket subscription in Standard and Priority tiers; ask SUSE for a quote | Included with GKE | Check the GCP Marketplace listing for the current licence fee. It can change, so we don't quote it here. Weighing up clouds rather than tools? There's an AWS version of this same image, covered in [Rancher on AWS Marketplace](https://meetrix.io/blogs/rancher-aws-marketplace/). The short answer is to run Rancher on the cloud where most of your clusters already live, so the management traffic stays close. Our piece on [AWS Marketplace vs Google Cloud Marketplace](https://meetrix.io/blogs/aws-marketplace-vs-google-cloud-marketplace-isvs/) covers how the two marketplaces differ. ## Resources [ Rancher on GCP - Developer Guide Step-by-step walkthrough of the full deployment: launching from GCP Marketplace, filling in the deployment form, pointing DNS, first login, SSL, logs and troubleshooting. Meetrix.IO | Binuka Ranatunga ![Rancher on GCP Developer Guide](https://meetrix.io/blog-images/paas-dev-guides/rancher-gcp/rancher-gcp-image.png)](https://meetrix.io/blogs/rancher-gcp-developer-guide/) ## Where I'd Start Day one Start the trial, deploy, point DNS, and log in. Import one GKE cluster and click around. Same day Promote the external IP to static. It's a minute of work and saves a confusing outage later. That week Set up the Backups operator, then central sign-in and role-based access, so nobody needs a kubeconfig from you again. Before it matters Decide on high availability, or on SUSE Rancher Prime if you want a vendor on the hook. Rancher ships often, and the Kubernetes versions it supports change between releases. Read the [release notes](https://github.com/rancher/rancher/releases) before you plan an upgrade. ## Frequently Asked Questions Can Rancher manage GKE clusters? Yes. Rancher can import and manage GKE clusters, and it can also provision them. GKE, EKS, and AKS are all listed as supported hosted cluster types. Is there a free trial for Rancher on GCP Marketplace? Yes. The listing includes a 5-day trial with up to USD 50 in licence fee credits. Infrastructure charges for the VM and disk still apply. Which machine type does the Meetrix Rancher image need on GCP? The default is e2-standard-2 (2 vCPU and 8 GB of memory), which is enough for Rancher and its K3s cluster. Size up if you plan to manage a large number of nodes. What is the bootstrap password for the Rancher dashboard? It's the admin password you set in the deployment form. You enter it on the Welcome to Rancher screen. Why does my Rancher domain show 502 Bad Gateway? K3s and the Rancher pods are still starting. Give it 5 to 10 minutes and try again. Do my clusters stop if the Rancher VM stops? No. Your downstream clusters keep running and serving traffic. You just can't manage them through the Rancher dashboard until the VM is back. Is one Rancher VM enough for production? No. Rancher's docs call for a high-availability setup of at least three nodes in production. A single VM is fine for a lab, a trial, or a small team that understands the tradeoff. ## Manage Every Cluster From Your Own GCP Project Launch a pre-configured Rancher server on Google Cloud, import your GKE clusters, and try it free for five days. [Deploy on GCP Marketplace](https://console.cloud.google.com/marketplace/product/meetrix-public/rancher) Meetrix Store Rancher Manage every Kubernetes cluster from one dashboard [Deploy it](https://meetrix.io/store/rancher/) Meetrix Store New Deploy what this guide covers, pre-configured. - [Rancher Manage every Kubernetes cluster from one dashboard](https://meetrix.io/store/rancher/) - [Coolify Deploy from Git, a Heroku alternative](https://meetrix.io/store/coolify/) - [Grafana Dashboards and alerts for Prometheus and more](https://meetrix.io/store/grafana/) - [Jitsi Meet Self-hosted video calls for 50 to 500 users](https://meetrix.io/store/jitsi-meet/) - [RustDesk Remote desktop AMI, a TeamViewer alternative](https://meetrix.io/store/rustdesk/) - [Coturn TURN/STUN for WebRTC, no per-minute relay fees](https://meetrix.io/store/coturn/) [Browse all products](https://meetrix.io/store/)