- Secured and managed Kubernetes services with auto-scaling and multi-cluster support
- Can be configured to automatically scale node pool and clusters across multiple node pools based on changing workload requirements.
- Auto-repair can be enabled to do health checks on node
- Choose clusters tailored to your requirements based on:
- Version Stability
- Pod Traffic requirements
- Enable Cloud Logging and Cloud Monitoring via simple checkbox configurations.
- Kubernetes version can be enabled to auto-upgrade with the latest release patch.
- Supports Docker container format.
- Integrates with Google Container Registry so you can easily access your private Docker images.
- Is the main CLI tool for running commands and managing Kubernetes clusters.
- All of the Kubernetes objects that represent your containerized applications run on top of a cluster.
- Nodes are the worker machines that run your containerized applications and other workloads.
- A cluster typically has one or more nodes,
- Kubernetes runs your workload by placing containers into Pods to run on Nodes.
- Node Pool
- A node pool is a set of nodes within a cluster that have similar configurations.
- Cluster Autoscaler
- Cluster Autoscaler automatically resizes the number of nodes in a given node pool, based on the demands of your workloads.
- Horizontal Pod Autoscaling
- HPA automatically scales the number of pods in response to
- your workload’s CPU or memory consumption
- custom metrics reported from within Kubernetes
- customer metrics reported externally.
- Cannot be used for workloads that cannot be scaled, such as DaemonSets.
- HPA automatically scales the number of pods in response to
- Are the smallest deployable units of computing that you can create and manage in Kubernetes.
- Every pod has its own IP address.
- You describe the desired state in a Deployment, and the Deployment Controller changes the actual state to the desired state at a controlled rate.
- Serves as a load balancer to balance traffic across a set of Pods
- You are allowed to specify which type of Service you would like to use:
- ClusterIP: Exposes the Service on a cluster-internal IP.
- NodePort: Exposes the Service on each Node’s IP at a static port (the NodePort).
- LoadBalancer: Exposes the Service externally using a cloud provider’s load balancer.
- Daemon Set
- A DaemonSet ensures that all (or some) Nodes run a copy of a Pod.
- ConfigMaps enable you to separate your configurations from your Pods and components, which helps keep your workloads portable.
- Provides a second layer of security between containerized workloads on GKE.
- GKE Sandbox uses gVisor.
- You cannot enable GKE Sandbox on a default node pool.
- When using Sandbox, you must have at least 2 node pools.
- It is not possible to use accelerators such as GPUs or TPUs
Pricing for Cluster Management
- One zonal cluster (single-zone or multi-zonal) per billing account is free.
- The fee is flat, irrespective of cluster size and topology—whether it is a single-zone cluster, multi-zonal cluster or regional cluster, all accrue the same flat fee per cluster.
- Billing is computed on a per-second basis for each cluster. The total amount is rounded to the nearest cent, at the end of each month.
- The fee does not apply to Anthos GKE clusters.
Pricing for worker node
- GKE uses Compute Engine instances for worker nodes in the cluster. You are billed for each of those instances according to Compute Engine’s pricing, until the nodes are deleted. Compute Engine resources are billed on a per-second basis with a one-minute minimum usage cost.
You are developing your product on a Kubernetes cluster in the Google Cloud Platform. You dedicate one Pod for each of your customers, and they are allowed to deploy untrusted code in their respective Pod. Knowing this, you want to make sure that you isolate the Pods from each other to avoid issues.
What should you do?
- Add a custom node pool and configure the
Enable sandbox with gVisoroption. Add the
runtimeClassName:gvisorparameter to each of your customers’ Pods.
- Whitelist the container images used by your customers’ Pods using Binary Authorization.
- Identify security vulnerabilities among the containers used by your customers’ Pods using the Container Analysis API.
- Utilize the cos_containerd image when creating GKE nodes. Add a
nodeSelectorfield to your pod configuration with the value of
Preemptible VMs are Compute Engine VM instances that last a maximum of 24 hours in general and provide no availability guarantees. Preemptible VMs are priced lower than standard Compute Engine VMs and offer the same machine types and options.
You can use preemptible VMs in your GKE clusters or node pools to run batch or fault-tolerant jobs that are less sensitive to the ephemeral, non-guaranteed nature of preemptible VMs.
When GKE clusters or node pools create Compute Engine VMs, the VMs behave like a managed instance group. Preemptible VMs in GKE are subject to the same limitations as preemptible instances in a managed instance group. Preemptible instances terminate after 30 seconds upon receiving a preemption notice.
To use preemptible VMs as node pool, select the
Enable preemptible nodes checkbox on the node pool creation.
You can create a cluster or node pool with preemptible VMs by specifying the
gcloud container clusters create cluster-name --preemptible
gcloud container node-pools create pool-name --preemptible \
Hence the correct answer is: Create a Google Kubernetes Engine Cluster. Create a node pool and select the
Enable preemptible nodes checkbox.
The option that says: Create a Google Kubernetes Engine Cluster and enable Vertical Pod Autoscaling using the
VerticalPodAutoscaler custom resource is incorrect because the Vertical Pod Scaling service is primarily used to automate the configuration of your container’s CPU and memory request limits. It doesn’t lower down the cost of your batch jobs unlike what the
Enable preemptible nodes feature can do.
The option that says: Create a Google Kubernetes Engine Cluster and enable the node auto-provisioning feature is incorrect because the Node Auto-provisioning feature just automatically manages a set of node pools in the Google Kubernetes Engine cluster on your behalf. It is stated in the scenario that the cluster is using local PersistentVolumes, which doesn’t support the node auto-provisioning feature.
The option that says: Create a Google Kubernetes Engine Cluster. Enable autoscaling to automatically create and delete nodes is incorrect. Even though this approach can save costs by automatically deleting unused nodes, using preemptible VMs still provides a bigger cost reduction.
Note: This question was extracted from our Google Certified Associate Cloud Engineer Practice Exams.