Kubernetes Engine

1. Clusters

  • The cluster type can't be changed after a cluster is created. 
  • Choices impact a cluster's availability, version stability, whether the cluster is VPC-native or routes-based, and isolation of workloads.
  • A single-zone cluster has a single control plane (master) running in one zone. 
  • A single-zone cluster control plane manages workloads on nodes running in the same zone.
  • A multi-zonal cluster has a single replica of the control plane running in a single zone, and has nodes running in multiple zones. 
  • During an upgrade of the cluster or an outage of the zone where the control plane runs, workloads still run. 
  • The cluster, its nodes, and its workloads cannot be configured until the control plane is available. 
  • Multi-zonal clusters balance availability and cost for consistent workloads. 
  • Use regional clusters to maintain availability, and if the number of nodes and node pools are changing frequently.
  • A regional cluster has multiple replicas of the control plane, running in multiple zones within a given region. 
  • Nodes also run in each zone where a replica of the control plane runs. 
  • Because a regional cluster replicates the control plane and nodes, it consumes more Compute Engine resources than a similar single-zone or multi-zonal cluster.
  • Choose the cluster's specific Kubernetes version or make choices about its overall mix of stability and features.
  • Recommended to enable auto-upgrade for the cluster and its nodes.
  • Enroll the cluster in a release channel where required stability is known. 
  • Google automatically upgrades the cluster and its nodes when an update is available in that release channel. 
  • The Rapid channel receives multiple updates a month, while the Stable channel only receives a few updates a year.
  • Where release channel is not used or a cluster version is not selected, the current default version is used. 
  • The default version is selected based on stability and real-world performance, and is changed regularly. 
  • A specific supported version of Kubernetes can be specified for a given workload when creating the cluster.
  • Where there is no need to control the specific patch version, enroll cluster in a release channel instead of managing its version directly.
  • An alpha cluster has all Kubernetes alpha APIs (feature gates) enabled. 
  • Alpha clusters can be used for early testing and validation of Kubernetes features.
  • Alpha clusters are not supported for production workloads.
  • Alpha clusters cannot be upgraded, and expire within 30 days.
  • GKE clusters can be distinguished according to the way they route traffic from one Pod to another Pod. 
  • A cluster that uses Alias IPs is called a VPC-native cluster. 
  • A cluster that uses Google Cloud Routes is called a routes-based cluster.
  • VPC-native is the recommended network mode for new clusters.
  • The default cluster network mode depends on the way the cluster is created.
  • Access from public networks to cluster's workloads can be configured. 
  • Routes are not created automatically. 
  • Private clusters assign internal RFC 1918 IP addresses to Pods and nodes, and workloads are completely isolated from public networks.
  • Binary Authorization provides software supply-chain security to GKE workloads. 
  • Binary Authorization works with images deployed to GKE from Container Registry or another container image registry. 
  • Binary Authorization can be used to ensure that internal processes that safeguard the quality and integrity of software have successfully completed before an application is deployed to a production environment.