logo

GCP vs Kubernetes

IAM

Role

  • Kubernetes Role / ClusterRole: Defines permissions (what actions can be performed).
  • GCP IAM Custom Roles / Predefined Roles: Defines permissions (what actions can be performed) within GCP services.

RoleBinding

  • Kubernetes RoleBinding / ClusterRoleBinding: Grants permissions defined in a Role/ClusterRole to a user, group, or service account.
  • GCP IAM Policy: Binds principals (users, groups, service accounts) to roles, granting them the defined permissions on specific resources.

Service Account

  • Kubernetes Service Account: An identity for processes that run in a Pod, used for cluster-internal access.
  • GCP Service Account: An identity for applications or VMs to access GCP resources.

No "User" in K8s!

In the world of Kubernetes, there is no such thing as a "User" object. If you try to run kubectl get users, you will get an error.

Kubernetes acts like a High-End Club. The club doesn't keep a list of members. It doesn't care who you are; it only cares if you have a valid ticket (a certificate or a token). When you send a command to K8s, it looks at your ticket and says, "This ticket was signed by Google. Google says this person is '[email protected]'. I trust Google, so I'll let Alice in." Once the command is finished, K8s "forgets" Alice existed. There is no Alice resource sitting in the cluster's database.

Kubernetes was designed to be pluggable. If K8s had its own internal user database, you would have to manually create "Bob" in your AWS cluster, then create "Bob" again in your Google cluster, and again in your on-prem cluster.

By having no user object, K8s allows you to "plug in" whatever identity you already use (like Google IAM, Active Directory, or Okta). This way, when Bob leaves the company and you delete him from the main corporate directory, he is automatically "deleted" from every K8s cluster he ever had access to.

How GKE bridges the gap (Workload Identity): in GCP you can use Workload Identity Federation. This is the "bridge" that allows a Kubernetes Service Account (the internal K8s object) to act as if it were a GCP Service Account (the external GCP object). It’s essentially a way to give your code a "Passport" so it can go out and use GCP services like Cloud Storage or BigQuery.

Compute

Node

  • Kubernetes Node: A worker machine (VM or physical) in a Kubernetes cluster.
  • A Google Compute Engine (GCE) VM instance.

Cluster

  • Kubernetes Cluster: A set of nodes that run containerized applications.
  • A Google Kubernetes Engine (GKE) Cluster.

Pod

  • Kubernetes Pod: The smallest deployable unit in Kubernetes, representing a single instance of a running process.
  • While not a direct one-to-one mapping, a Google Compute Engine (GCE) VM instance or a Cloud Run service instance can be seen as a similar concept in terms of a single, isolated execution unit.

Deployment

  • Kubernetes Deployment: Manages the desired state of ReplicaSets, providing declarative updates for Pods.
  • Managed Instance Groups (MIGs) in GCE for VM-based applications, or Cloud Run services for containerized applications, both manage the desired state and scaling of instances.

Service

  • Kubernetes Service: An abstract way to expose an application running on a set of Pods as a network service.
  • Cloud Load Balancing (various types like HTTP(S), TCP/UDP Load Balancers) combined with Instance Groups or NEG (Network Endpoint Group) for GKE. Also Cloud Run URLs or API Gateway for specific use cases.

Storage

Disk

  • Kubernetes PersistentVolume (PV): A piece of storage in the cluster provisioned by an administrator or dynamically.
  • Google Persistent Disk (PD), Filestore, or Cloud Storage buckets (when used with CSI drivers).

And

  • Kubernetes PersistentVolumeClaim (PVC): A request for storage by a user.
  • When using PVs on GCP, the PVC directly maps to a request for a specific Google Persistent Disk or other storage type configured by the PV.

Storage Class

  • Kubernetes StorageClass: Describes the "classes" of storage offered in a cluster.
  • While StorageClasses are a K8s concept, they provision Google Persistent Disks with specific types (e.g., standard, ssd) and features.

Networking

Ingress / Gateway

  • Kubernetes Ingress: Manages external access to services in a cluster, typically HTTP/HTTPS.
  • GCP HTTP(S) Load Balancer with an Ingress for GKE controller, or Cloud CDN for content delivery.

Service mesh

  • K8s: Istio
  • GCP: Cloud Service Mesh is using Istio under the hood.

Network Policy

  • Kubernetes Network Policy: Specifies how groups of pods are allowed to communicate with each other and other network endpoints.
  • VPC Firewall Rules (for VM-level traffic), Cloud Armor (for DDoS and WAF), and GKE Network Policy (which often leverages underlying VPC features).

Configuration / Secrets / Security

Secrets

  • Kubernetes ConfigMap: Stores non-confidential data in key-value pairs.
  • Google Secret Manager (for less sensitive configuration that you want versioned and audited), or application-specific configuration files stored on Cloud Storage.

Configs

  • Kubernetes Secret: Stores sensitive information, such as passwords, OAuth tokens, and ssh keys.
  • Google Secret Manager, which provides robust encryption, access control, and auditing for secrets.

Cert Manager

Key Management

  • HashiCorp Vault or Kubernetes Secret
  • Google Cloud Key Management Service (KMS)

Observability

Logs

  • Kubernetes Logs (Pod logs): Output from applications running in pods.
  • Cloud Logging (Stackdriver Logging): Collects and stores logs from all GCP services and GKE.

Metrics / Monitoring

  • Kubernetes Metrics (Prometheus, Heapster, etc.): Performance metrics from containers, pods, nodes.
  • Cloud Monitoring (Stackdriver Monitoring): Collects metrics from GCP resources, including GKE, and allows for custom metrics.
logo
PRIVACY POLICYABOUT中文