Some Important Xtra+ Notes Google Kubernetes Engine GKE for Google Cloud Associate Certification

https://cloud.google.com/solutions/prep-kubernetes-engine-for-prod

Kubernetes on Google Cloud

When you run a GKE cluster, you also gain the benefit of advanced cluster management features that Google Cloud provides. These include:

• Google Cloud’s load-balancing for Compute Engine instances
• Node pools to designate subsets of nodes within a cluster for additional flexibility
• Automatic scaling of your cluster’s node instance count
• Automatic upgrades for your cluster’s node software
• Node auto-repair to maintain node health and availability
• Logging and monitoring with Google Cloud’s operations suite for visibility into your cluster

Cluster architecture

A cluster is the foundation of Google Kubernetes Engine (GKE): the Kubernetes objects that represent your containerized applications all run on top of a cluster.

In GKE, a cluster consists of at least one cluster master and multiple worker machines called nodes. These master and node machines run the Kubernetes cluster orchestration system.

The following diagram provides an overview of the architecture for a zonal cluster in GKE.

Cluster master

The cluster master runs the Kubernetes control plane processes, including the Kubernetes API server, scheduler, and core resource controllers. The master’s lifecycle is managed by GKE when you create or delete a cluster. This includes upgrades to the Kubernetes version running on the cluster master, which GKE performs automatically, or manually at your request if you prefer to upgrade earlier than the automatic schedule.

Cluster master and the Kubernetes API

The master is the unified endpoint for your cluster. All interactions with the cluster are done via Kubernetes API calls, and the master runs the Kubernetes API Server process to handle those requests. You can make Kubernetes API calls directly via HTTP/gRPC, or indirectly, by running commands from the Kubernetes command-line client (kubectl) or interacting with the UI in the Cloud Console.

The cluster master’s API server process is the hub for all communication for the cluster. All internal cluster processes (such as the cluster nodes, system and components, application controllers) all act as clients of the API server; the API server is the single “source of truth” for the entire cluster.

Master and node interaction

The cluster master is responsible for deciding what runs on all of the cluster’s nodes. This can include scheduling workloads, like containerized applications, and managing the workloads’ lifecycle, scaling, and upgrades. The master also manages network and storage resources for those workloads.

The master and nodes also communicate using Kubernetes APIs.

Master interactions with the gcr.io container registry

When you create or update a cluster, container images for the Kubernetes software running on the masters (and nodes) are pulled from the gcr.io container registry. An outage affecting the gcr.io registry may cause the following types of failures:

• Creating new clusters will fail during the outage.
• Upgrading clusters will fail during the outage.
• Disruptions to workloads may occur even without user intervention, depending on the specific nature and duration of the outage.

In the event of a zonal or regional outage of the gcr.io container registry, Google may redirect requests to a zone or region not affected by the outage.

To check the current status of Google Cloud services, go to the Google Cloud status dashboard.

Nodes

A cluster typically has one or more nodes, which are the worker machines that run your containerized applications and other workloads. The individual machines are Compute Engine VM instances that GKE creates on your behalf when you create a cluster.

Each node is managed from the master, which receives updates on each node’s self-reported status. You can exercise some manual control over node lifecycle, or you can have GKE perform automatic repairs and automatic upgrades on your cluster’s nodes.

A node runs the services necessary to support the Docker containers that make up your cluster’s workloads. These include the Docker runtime and the Kubernetes node agent (kubelet) which communicates with the master and is responsible for starting and running Docker containers scheduled on that node.

In GKE, there are also a number of special containers that run as per-node agents to provide functionality such as log collection and intra-cluster network connectivity.

Pod

This page describes Kubernetes’ Pod object and its use in Google Kubernetes Engine.

What is a Pod?

Pods are the smallest, most basic deployable objects in Kubernetes. A Pod represents a single instance of a running process in your cluster.

Pods contain one or more containers, such as Docker containers. When a Pod runs multiple containers, the containers are managed as a single entity and share the Pod’s resources. Generally, running multiple containers in a single Pod is an advanced use case.

Pods also contain shared networking and storage resources for their containers:

• Network: Pods are automatically assigned unique IP addresses. Pod containers share the same network namespace, including IP address and network ports. Containers in a Pod communicate with each other inside the Pod on localhost.
• Storage: Pods can specify a set of shared storage volumes that can be shared among the containers.

You can consider a Pod to be a self-contained, isolated “logical host” that contains the systemic needs of the application it serves.

A Pod is meant to run a single instance of your application on your cluster. However, it is not recommended to create individual Pods directly. Instead, you generally create a set of identical Pods, called replicas, to run your application. Such a set of replicated Pods are created and managed by a controller, such as a Deployment. Controllers manage the lifecycle of their constituent Pods and can also perform horizontal scaling, changing the number of Pods as necessary.

Although you might occasionally interact with Pods directly to debug, troubleshoot, or inspect them, it is highly recommended that you use a controller to manage your Pods.

Pods run on nodes in your cluster. Once created, a Pod remains on its node until its process is complete, the Pod is deleted, the Pod is evicted from the node due to lack of resources, or the node fails. If a node fails, Pods on the node are automatically scheduled for deletion.

Deployment

This page describes Kubernetes Deployment objects and their use in Google Kubernetes Engine (GKE).

What is a Deployment?

Deployments represent a set of multiple, identical Pods with no unique identities. A Deployment runs multiple replicas of your application and automatically replaces any instances that fail or become unresponsive. In this way, Deployments help ensure that one or more instances of your application are available to serve user requests. Deployments are managed by the Kubernetes Deployment controller.

Deployments use a Pod template, which contains a specification for its Pods. The Pod specification determines how each Pod should look like: what applications should run inside its containers, which volumes the Pods should mount, its labels, and more.

When a Deployment’s Pod template is changed, new Pods are automatically created one at a time.

Usage patterns

Deployments are well-suited for stateless applications that use ReadOnlyMany or ReadWriteMany volumes mounted on multiple replicas, but are not well-suited for workloads that use ReadWriteOnce volumes. For stateful applications using ReadWriteOnce volumes, use StatefulSets. StatefulSets are designed to deploy stateful applications and clustered applications that save data to persistent storage, such as Compute Engine persistent disks. StatefulSets are suitable for deploying Kafka, MySQL, Redis, ZooKeeper, and other applications needing unique, persistent identities and stable hostnames.

StatefulSets

StatefulSets are designed to deploy stateful applications and clustered applications that save data to persistent storage, such as Compute Engine persistent disks. StatefulSets are suitable for deploying Kafka, MySQL, Redis, ZooKeeper, and other applications needing unique, persistent identities and stable hostnames. For stateless applications, use Deployments.

What is a DaemonSet?

Like other workload objects, a DaemonSet manages groups of replicated Pods. However, DaemonSets attempt to adhere to a one-Pod-per-node model, either across the entire cluster or a subset of nodes. As you add nodes to a node pool, DaemonSets automatically add Pods to the new nodes as needed.

Usage patterns

DaemonSets are useful for deploying ongoing background tasks that you need to run on all or certain nodes, and which do not require user intervention. Examples of such tasks include storage daemons like ceph, log collection daemons like fluentd, and node monitoring daemons like collectd.

For example, you could have DaemonSets for each type of daemon run on all of your nodes. Alternatively, you could run multiple DaemonSets for a single type of daemon, but have them use different configurations for different hardware types and resource needs.

ConfigMap

This page describes Kubernetes’ ConfigMap object and its use in Google Kubernetes Engine (GKE).

Overview

ConfigMaps bind configuration files, command-line arguments, environment variables, port numbers, and other configuration artifacts to your Pods’ containers and system components at runtime. ConfigMaps enable you to separate your configurations from your Pods and components, which helps keep your workloads portable. This makes their configurations easier to change and manage, and prevents hardcoding configuration data to Pod specifications.

ConfigMaps are useful for storing and sharing non-sensitive, unencrypted configuration information. To use sensitive information in your clusters, you must use Secrets.

Secret

This page describes the Secret object in Kubernetes and its use in Google Kubernetes Engine (GKE).

What is a Secret?

Secrets are secure objects which store sensitive data, such as passwords, OAuth tokens, and SSH keys, in your clusters. Storing sensitive data in Secrets is more secure than plaintext ConfigMaps or in Pod specifications. Using Secrets gives you control over how sensitive data is used, and reduces the risk of exposing the data to unauthorized users.

You can also encrypt Secrets at the application layer using a key you manage in Cloud KMS. To learn more, see Application-layer Secrets Encryption.

Creating a Secret

You create a Secret by using the kubectl create secret:

kubectl create secret type name data

Overview of deploying workloads

To deploy and manage your containerized applications and other workloads on your Google Kubernetes Engine (GKE) cluster, you use the Kubernetes system to create Kubernetes controller objects. These controller objects represent the applications, daemons, and batch jobs running on your clusters.

You can create these controller objects using the Kubernetes API or by using kubectl, a command-line interface to Kubernetes installed by gcloud. Typically, you build a representation of your desired Kubernetes controller object as a YAML configuration file, and then use that file with the Kubernetes API or the kubectl command-line interface.

Types of workloads

Kubernetes provides different kinds of controller objects that correspond to different kinds of workloads you can run. Certain controller objects are better suited to representing specific types of workloads. The following sections describe some common types of workloads and the Kubernetes controller objects you can create to run them on your cluster, including:

• Stateless applications
• Stateful applications
• Batch jobs
• Daemons

Stateless applications

A stateless application does not preserve its state and saves no data to persistent storage — all user and session data stays with the client.

Some examples of stateless applications include web frontends like Nginx, web servers like Apache Tomcat, and other web applications.

You can create a Kubernetes Deployment to deploy a stateless application on your cluster. Pods created by Deployments are not unique and do not preserve their state, which makes scaling and updating stateless applications easier.

Stateful applications

A stateful application requires that its state be saved or persistent. Stateful applications use persistent storage, such as persistent volumes, to save data for use by the server or by other users.

Examples of stateful applications include databases like MongoDB and message queues like Apache ZooKeeper.

You can create a Kubernetes StatefulSet to deploy a stateful application. Pods created by StatefulSets have unique identifiers and can be updated in an ordered, safe way.

Batch jobs

Batch jobs represent finite, independent, and often parallel tasks which run to their completion. Some examples of batch jobs include automatic or scheduled tasks like sending emails, rendering video, and performing expensive computations.

You can create a Kubernetes Job to execute and manage a batch task on your cluster. You can specify the number of Pods that should complete their tasks before the Job is complete, as well as the maximum number of Pods that should run in parallel.

Daemons

Daemons perform ongoing background tasks in their assigned nodes without the need for user intervention. Examples of daemons include log collectors like Fluentd and monitoring services.

You can create a Kubernetes DaemonSet to deploy a daemon on your cluster. DaemonSets create one Pod per node, and you can choose a specific node to which the DaemonSet should deploy.

Managing workload objects

You can create, manage, and delete objects using imperative and declarative methods. The following sections describe these methods as well as the following tools you can use to employ them:

• kubectl, the Kubernetes command-line tool installed with Cloud SDK
• GKE Workloads menu in Cloud Console
• The GKE REST API and the Kubernetes API.

Imperative commands

Imperative commands allow you to quickly create, view, update, and delete objects with kubectl. These commands are useful for one-off tasks or for making changes to active objects in a cluster. Imperative commands are commonly used to operate on live, deployed objects on your cluster.

kubectl features several verb-driven commands for creating and editing Kubernetes objects. For example:

• run: Generate a new object in the cluster. Unless otherwise specified, run creates a Deployment object. run also supports several other generators.
• expose: Create a new Service object to load balance traffic across a set of labelled Pods.
• autoscale: Create a new Autoscaler object to automatically horizontally scale a controller object, such as a Deployment.

Imperative commands do not require strong understanding of object schema and do not require configuration files.

Imperative object configuration

Imperative object configuration creates, updates, and deletes objects using configuration files containing fully-defined object definitions. You can store object configuration files in source control systems and audit changes more easily than with imperative commands.

You can run kubectl apply, delete, and replace operations with configuration files or directories containing configuration files.

Declarative object configuration

Declarative object configuration operates on locally-stored configuration files but does not require explicit definition of the operations to be executed. Instead, operations are automatically detected per-object by kubectl. This is useful if you are working with a directory of configuration files with many different operations. Declarative object management requires a strong understanding of object schemas and configuration files.

You can run kubectl apply to create and updates objects declaratively. apply updates objects by reading the whole live object, calculating the differences, then merging those differences by sending patch requests to the API server.

Console

After you have deployed a workload using kubectl or the API, you can use the GKE Workloads menu in Cloud Console to inspect, manage, and edit workloads running on your clusters.

The menu offers the following features:

• You can use the YAML-based text editor to edit live objects from your web browser
• You can view detailed information about objects, including revision history, recent events and activities, and its managed Pods
• You can easily scale Deployments, Jobs, and StatefulSets
• You can autoscale, trigger rolling updates, and manually scale Deployments from the Actions menu.
• You can use Cloud Shell to inspect, edit, and delete any object.

API

You can use the GKE REST API and Kubernetes API alongside the Google Cloud Client Libraries to programmatically create and manage workloads.

Configuration files

When you deploy a workload using any of the methods previously described, GKE adds a configuration file to your cluster that represents the object.

An object’s live configuration might differ from its local file. YAML is most commonly used to create and represent Kubernetes objects. You can also use JSON.

To learn more about Kubernetes object specifications, statuses, and the Kubernetes API, refer to Understanding Kubernetes Objects and the Kubernetes API reference.

Inspecting live configurations

Consolegcloud

To inspect the live configuration of a deployed object, run the following command:

kubectl get [OBJECT_TYPE] [OBJECT_NAME] -o yaml

[OBJECT_TYPE] might be deployment, statefulset, job, or other object type. For example:

kubectl get deployment my-stateless-app -o yaml

Networking Outside the Cluster

This section explains how traffic from outside the cluster reaches applications running within a Kubernetes cluster. This information is important when designing your cluster’s applications and workloads.

You’ve already read about how Kubernetes uses Services to provide stable IP addresses for applications running within Pods. By default, Pods do not expose an external IP address, because kube-proxy manages all traffic on each node. Pods and their containers can communicate freely, but connections outside the cluster cannot access the Service. For instance, in the previous illustration, clients outside the cluster cannot access the frontend Service via its ClusterIP.

GKE provides three different types of Load Balancers to control access and to spread incoming traffic across your cluster as evenly as possible. You can configure one Service to use multiple types of Load Balancers simultaneously.

• External Load Balancers manage traffic coming from outside the cluster and outside your Google Cloud Virtual Private Cloud (VPC) network. They use forwarding rules associated with the Google Cloud network to route traffic to a Kubernetes node.
• Internal Load Balancers manage traffic coming from within the same VPC network. Like external load balancers, they use forwarding rules associated with the Google Cloud network to route traffic to a Kubernetes node.
• HTTP(S) Load Balancers are specialized external load balancers used for HTTP(S) traffic. They use an Ingress resource rather than a forwarding rule to route traffic to a Kubernetes node.

When traffic reaches a Kubernetes node, it is handled the same way, regardless of the type of load balancer. The load balancer is not aware of which nodes in the cluster are running Pods for its Service. Instead, it balances traffic across all nodes in the cluster, even those not running a relevant Pod. On a regional cluster, the load is spread across all nodes in all zones for the cluster’s region. When traffic is routed to a node, the node routes the traffic to a Pod, which may be running on the same node or a different node. The node forwards the traffic to a randomly chosen Pod by using the iptables rules that kube-proxy manages on the node.

Container-native load balancing

Container-native load balancing enables several kinds of load balancers to target Pods directly and to evenly distribute their traffic to Pods.

Container-native load balancing leverages a data model called network endpoint groups (NEGs). NEGs are collections of network endpoints represented by IP-port pairs.

When NEGs are used with GKE Ingress, the Ingress controller facilitates the creation of all aspects of the L7 load balancer. This includes creating the virtual IP address, forwarding rules, health checks, firewall rules, and more.

For more flexibility, you can also create standalone NEGs. In this case, you are responsible for creating and managing all aspects of the L7 load balancer.

Benefits

Container-native load balancing offers the following benefits:

Pods are first-class citizens for load balancingkube-proxy configures nodes’ iptables rules to distribute traffic to Pods. Without container-native load balancing, load balancer traffic travels to the node instance groups and gets routed via iptables rules to Pods which might or might not be in the same node. With container-native load balancing, load balancer traffic is distributed directly to the Pods which should receive the traffic, eliminating the extra network hop. Container-native load balancing also helps with improved health checking since it targets Pods directly.

Improved network performanceBecause the container-native load balancer talks directly with the Pods, and connections have fewer network hops, both latency and throughput are improved.Increased visibilityWith container-native load balancing, you have visibility into the round-trip time (RTT) from the client to the HTTP(S) load balancer, including Stackdriver UI support. This makes troubleshooting your services at the NEG-level easier.Support for advanced Load Balancing featuresContainer-native load balancing offer native support in Google Kubernetes Engine for several features of HTTP(S) Load Balancing, such as integration with Google Cloud services like Google Cloud Armor, Cloud CDN, and Identity-Aware Proxy. It also features load balancing algorithms for accurate traffic distribution.Support for Traffic DirectorThe NEG data model is required to use Traffic Director, Google Cloud’s fully managed traffic control plane for service mesh.

Creating a GKE cluster

A cluster consists of at least one cluster master machine and multiple worker machines called nodes. Nodes are Compute Engine virtual machine (VM) instances that run the Kubernetes processes necessary to make them part of the cluster. You deploy applications to clusters, and the applications run on the nodes.

The following command creates a one-node cluster. Replace cluster-name with the name of your cluster:

gcloud container clusters create cluster-name --num-nodes=1

Note: It might take several minutes to finish creating the cluster.

Get authentication credentials for the cluster

After creating your cluster, you need to get authentication credentials to interact with the cluster:

gcloud container clusters get-credentials cluster-name

This command configures kubectl to use the cluster you created.

Deploying an application to the cluster

Now that you have created a cluster, you can deploy a containerized application to it. For this quickstart, you can deploy our example web application, hello-app.

GKE uses Kubernetes objects to create and manage your cluster’s resources. Kubernetes provides the Deployment object for deploying stateless applications like web servers. Service objects define rules and load balancing for accessing your application from the internet.

Creating the Deployment

To run hello-app in your cluster, run the following command:

kubectl create deployment hello-server --image=gcr.io/google-samples/hello-app:1.0

This Kubernetes command, kubectl create deployment, creates a Deployment named hello-server. The Deployment's Pod runs the hello-app container image.

In this command:

• --image specifies a container image to deploy. In this case, the command pulls the example image from a Container Registry bucket, gcr.io/google-samples/hello-app. :1.0 indicates the specific image version to pull. If you don't specify a version, the latest version is used.

Exposing the Deployment

After deploying the application, you need to expose it to the internet so that users can access it. You can expose your application by creating a Service, a Kubernetes resource that exposes your application to external traffic.

To expose your application, run the following kubectl expose command:

kubectl expose deployment hello-server --type LoadBalancer \
  --port 80 --target-port 8080

Passing in the --type LoadBalancer flag creates a Compute Engine load balancer for your container. The --port flag initializes public port 80 to the internet and the --target-port flag routes the traffic to port 8080 of the application.

Load balancers are billed per Compute Engine’s load balancer pricing.

Inspecting and viewing the application

1. Inspect the running Pods by using kubectl get pods:

kubectl get pods

You should see one hello-server Pod running on your cluster.

Inspect the hello-server Service by using kubectl get service:

kubectl get service hello-server

From this command’s output, copy the Service’s external IP address from the EXTERNAL-IP column.

1. Note: You might need to wait several minutes before the Service’s external IP address populates. If the application’s external IP is <pending>, run kubectl get again.
2. View the application from your web browser by using the external IP address with the exposed port:http://external-ip/

You have just deployed a containerized web application to GKE.

Clean up

To avoid incurring charges to your Google Cloud account for the resources used in this quickstart, follow these steps.

Delete the application’s Service by running kubectl delete:

kubectl delete service hello-server

This command deletes the Compute Engine load balancer that you created when you exposed the Deployment.

Delete your cluster by running gcloud container clusters delete:

gcloud container clusters delete cluster-name

Rolling back an update

You can roll back an update using kubectl rollout undo.

You can roll back an in-progress or completed update to its previous revision:

kubectl rollout undo deployment my-deployment

You can also roll back to a specific revision:

kubectl rollout undo deployment my-deployment --to-revision=3

GPU

gcloud container node-pools create pool-name \
  --accelerator type=gpu-type,count=amount \
  --zone compute-zone --cluster cluster-name \
  [--num-nodes 3 --min-nodes 0 --max-nodes 5 --enable-autoscaling]

Writing the sample app

For instructions on creating a Hello World app that runs on GKE, click your language:

GoNode.jsPythonJavaC#PHPRuby

1. Create a new directory named helloworld-gke and change directory into it:

• mkdir helloworld-gke
cd helloworld-gke

1. Create a file named app.py and paste the following code into it:
2. quickstart/python/app.py
3. View on GitHub

• import os
• from flask import Flask
• app = Flask(__name__)
• @app.route('/')
def hello_world():
target = os.environ.get('TARGET', 'World')
return 'Hello {}!\n'.format(target)
• if __name__ == "__main__":
app.run(debug=True,host='0.0.0.0',port=int(os.environ.get('PORT', 8080)))

Containerizing an app with Cloud Build

1. To containerize the sample app, create a new file named Dockerfile in the same directory as the source files, and copy the following content:
2. GoNode.jsPythonJavaC#PHPRuby
3. quickstart/python/Dockerfile
4. View on GitHub

• # Use the official lightweight Python image.
# https://hub.docker.com/_/python
FROM python:3.7-slim
• # Copy local code to the container image.
ENV APP_HOME /app
WORKDIR $APP_HOME
COPY . ./
• # Install production dependencies.
RUN pip install Flask gunicorn
• # Run the web service on container startup. Here we use the gunicorn
# webserver, with one worker process and 8 threads.
# For environments with multiple CPU cores, increase the number of workers
# to be equal to the cores available.
CMD exec gunicorn --bind :$PORT --workers 1 --threads 8 app:app

1. Add a .dockerignore file to ensure local files don't affect the container build process:
2. quickstart/python/.dockerignore
3. View on GitHub

• Dockerfile
README.md
*.pyc
*.pyo
*.pyd
__pycache__

1. Get your Google Cloud project ID:

• gcloud config get-value project

1. Build your container image using Cloud Build, which is similar to running docker build and docker push, but it happens on Google Cloud. Replace project-id with your Google Cloud ID:

• gcloud builds submit — tag gcr.io/project-id/helloworld-gke .

1. The image is stored in Container Registry.

Creating a Kubernetes Engine cluster

A GKE cluster is a managed set of Compute Engine virtual machines that operate as a single GKE cluster. This tutorial uses a single node.

1. Create the cluster. Replace your-gcp-zone with the Google Cloud zone where you want to host your cluster. For a complete list, see Geography and regions.

• gcloud container clusters create helloworld-gke \
  — num-nodes 1 \
  — enable-basic-auth \
  — issue-client-certificate \
  — zone your-gcp-zone

1. Note: A region contains one or more zones. Using a region instead of a zone for the --zone option (for example, us-central1 instead of us-central1-b) creates a node in each zone within the region.Note: The default scope is set to --scopes=gke-default. For a full list of available scopes, see OAuth 2.0 scopes for Google APIs.
2. Verify that you have access to the cluster. The following command lists the nodes in your container cluster which are up and running and indicates that you have access to it.

• kubectl get nodes

1. If you run into errors, refer to the Kubernetes Troubleshooting guide

Deploying to GKE

To deploy your app to the GKE cluster you created, you need two Kubernetes objects.

1. A Deployment to define your app.
2. A Service to define how to access your app.

Deploy an app

The app has a frontend server that handles the web requests. You define the cluster resources needed to run the frontend in a new file called deployment.yaml. These resources are described as a Deployment. You use Deployments to create and update a ReplicaSet and its associated pods.

1. Create the deployment.yaml file in the same directory as your other files and copy the following content, replacing $GCLOUD_PROJECT with your Google Cloud project ID:
2. quickstart/deployment.yaml
3. View on GitHub

• # This file configures the hello-world app which serves public web traffic.
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: helloworld-gke
spec:
replicas: 1
selector:
matchLabels:
app: hello
template:
metadata:
labels:
app: hello
spec:
containers:
- name: hello-app
# Replace $GCLOUD_PROJECT with your project ID
image: gcr.io/$GCLOUD_PROJECT/helloworld-gke:latest
# This app listens on port 8080 for web traffic by default.
ports:
- containerPort: 8080
env:
- name: PORT
value: "8080"

1. Deploy the resource to the cluster:

• kubectl apply -f deployment.yaml

1. Track the status of the Deployment:

• kubectl get deployments

1. The Deployment is complete, when all of the AVAILABLE deployments are READY.

• NAME READY UP-TO-DATE AVAILABLE AGE hello-deployment 1/1 1 1 20s

1. If the Deployment has a mistake, run kubectl apply -f deployment.yaml again to update the Deployment with any changes.
2. After the Deployment is complete, you can see the pods that the Deployment created:

• kubectl get pods

Deploy a Service

Services provide a single point of access to a set of pods. While it’s possible to access a single pod, pods are ephemeral and can only be accessed reliably by using a Service address. In your Hello World app, the “hello” Service defines a load balancer to access the hello-app pods from a single IP address. This Service is defined in the service.yaml file.

1. Create the file service.yaml in the same directory as your other source files with the following content:
2. quickstart/service.yaml
3. View on GitHub

• # The hello service provides a load-balancing proxy over the hello-app
# pods. By specifying the type as a 'LoadBalancer', Kubernetes Engine will
# create an external HTTP load balancer.
apiVersion: v1
kind: Service
metadata:
name: hello
spec:
type: LoadBalancer
selector:
app: hello
ports:
- port: 80
targetPort: 8080

1. The pods are defined separately from the Service that uses the pods. Kubernetes uses labels to select the pods that a Service addresses. With labels, you can have a Service that addresses pods from different replica sets and have multiple Services that point to an individual pod.
2. Create the Hello World Service:

• kubectl apply -f service.yaml

1. Get the Service’s external IP address:

• kubectl get services

1. It can take up to 60 seconds to allocate the IP address. The external IP address is listed under the column EXTERNAL-IP for the hello Service.

• NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE hello LoadBalancer 10.22.222.222 35.111.111.11 80:32341/TCP 1m kubernetes ClusterIP 10.22.222.1 <none> 443/TCP 20m

View a deployed app

You have now deployed all the resources needed to run the Hello World app on GKE. Use the external IP address from the previous step to load the app in your web browser, and see your running app!

# Example cURL call to your running application on GKE (external IP address of service)
curl 35.111.111.11
Hello World!

Clean up

To avoid incurring charges to your Google Cloud account for the resources used in this quickstart, follow these steps.

You are charged for the Compute Engine instances running in your cluster, as well as for the container image in Container Registry.

Delete the project

Deleting your Cloud project stops billing for all the resources used within that project.

• Everything in the project is deleted. If you used an existing project for this tutorial, when you delete it, you also delete any other work you’ve done in the project.
• Custom project IDs are lost. When you created this project, you might have created a custom project ID that you want to use in the future. To preserve the URLs that use the project ID, such as an appspot.com URL, delete selected resources inside the project instead of deleting the whole project.

1. In the Cloud Console, go to the Manage resources page.
2. Go to the Manage resources page
3. In the project list, select the project that you want to delete and then click Delete delete.
4. In the dialog, type the project ID and then click Shut down to delete the project.

Delete your cluster and container

If you want to keep your project but only delete the resources used in this tutorial, delete your cluster and image.

To delete a cluster using the gcloud command-line tool, run the following command:

gcloud container clusters delete helloworld-gke

Note: For more information, refer to the documentation on Deleting a cluster.

To delete an image from one of your Container Registry repositories, run the following command:

gcloud container images delete gcr.io/project-id/helloworld-gke

Note: For more information, refer to the documentation on Managing images.

gke

single-zone cluster

gcloud container clusters create cluster-name \
    --zone compute-zone
optional
  --cluster-version version
  --release-channel channel

multi-zonal cluster

gcloud container clusters create cluster-name \
    --zone compute-zone \
    --node-locations compute-zone,compute-zone,[...]

regional cluster

(three zones with three nodes each, which is default):

gcloud container clusters create my-regional-cluster \
    --num-nodes 2 \
    --region us-west1

private cluster

Access to the master

In private clusters, the master has a private and public endpoint. There are three configuration combinations to control access to the cluster endpoints.

• Public endpoint access disabled. This creates a private cluster with no client access to the public endpoint.
• Public endpoint access enabled, master authorized networks enabled. This creates a private cluster with limited access to the public endpoint.
• Public endpoint access enabled, master authorized networks disabled. This creates a private cluster with unrestricted access to the public endpoint.

See Access to cluster endpoints for an overview of the differences between the above configuration options.

Run the following command:

gcloud container clusters create private-cluster-0 \
    --create-subnetwork name=my-subnet-0 \
    --enable-master-authorized-networks \
    --enable-ip-alias \
    --enable-private-nodes \
    --enable-private-endpoint \
    --master-ipv4-cidr 172.16.0.32/28 \
    --no-enable-basic-auth \
    --no-issue-client-certificate

where:

• --create-subnetwork name=my-subnet-0 causes GKE to automatically create a subnet named my-subnet-0.
• --enable-master-authorized-networks specifies that access to the public endpoint is restricted to IP address ranges that you authorize.
• --enable-ip-alias makes the cluster VPC-native.
• --enable-private-nodes indicates that the cluster's nodes do not have external IP addresses.
• --enable-private-endpoint indicates that the cluster is managed using the private IP address of the master API endpoint.
• --master-ipv4-cidr 172.16.0.32/28 specifies an RFC 1918 range for the master. This setting is permanent for this cluster. The use of non RFC 1918 reserved IPs is also supported (beta).
• --no-enable-basic-auth indicates to disable basic auth for the cluster.
• --no-issue-client-certificate disables issuing a client certificate.

Using Cloud Shell to access a private cluster

In your Cloud Shell command-line window, use dig to find the external IP address of your Cloud Shell:

dig +short myip.opendns.com @resolver1.opendns.com

Add the external address of your Cloud Shell to your cluster’s list of master authorized networks:

gcloud container clusters update private-cluster-1 \
    --zone us-central1-c \
    --enable-master-authorized-networks \
    --master-authorized-networks existing-auth-nets,shell-IP/32

1. where:

• existing-auth-nets is your existing list of master authorized networks.You can find your master authorized networks in the console or by running the following command:

gcloud container clusters describe private-cluster-1 --format "flattened(masterAuthorizedNetworksConfig.cidrBlocks[])"

• shell-IP is the external IP address of your Cloud Shell.Get credentials, so that you can use kubectl to access the cluster:

gcloud container clusters get-credentials private-cluster-1 \
--zone us-central1-a \
--project project-id

where project-id is your project ID.Now you can use kubectl, in Cloud Shell, to access your private cluster. For example:

kubectl get nodes

Cluster administration overview

In Google Kubernetes Engine, you configure a cluster’s configuration and characteristics using Google Cloud tools and APIs, including the gcloud command-line tool and the Google Cloud Console. These tasks include creating, updating, and deleting clusters, adding or removing nodes, and controlling who can access the cluster using Identity and Access Management.

To control the cluster’s internal behavior, you use the Kubernetes API and the kubectl command-line interface. You can also configure many aspects of a cluster's behavior using the Google Cloud Console.

Warning: Do not manually edit or delete iptables rules or other node-level settings that GKE manages. The node may become unreachable or unintentionally exposed when manual changes revert to the cluster's declarative configuration.

Basic cluster administration

Basic cluster administration tasks are specific to GKE clusters on Google Cloud Platform and typically do not involve the Kubernetes system itself; you perform these tasks entirely by using the Cloud Console, the gcloud command-line interface, or the GKE API.

Cluster and node upgrades

By default, clusters and node pools are upgraded automatically. You can learn more about configuring how upgrades work on each cluster, including when they can and cannot occur.

Cluster-level configuration

Cluster-level configuration tasks include creating and deleting GKE clusters and nodes. You can control when cluster maintenance tasks can occur, configure cluster-level autoscaling, and enable or disable logging and monitoring for your cluster.

Node configuration

GKE offers a range of options for your cluster’s nodes. For example, you can create one or more node pools; node pools are groups of nodes within your cluster that share a common configuration. Your cluster must have at least one node pool, and a node pool called default is created when you create the cluster.

You can set other node options on a per-pool basis, including:

• Automatic repairs
• Preemptible VMs
• Local SSDs
• Minimum CPU platform

Configuring cluster networking

Another aspect of cluster administration is to enable and control various networking features for your cluster. Most networking features are set at cluster creation: when you create a cluster using a GCP interface, you must enable the networking features that you want to use. Some of these features might require further configuration using Kubernetes interfaces, such as the kubectl command-line interface.

For example, to enable network policy enforcement on your GKE cluster, you must first enable the feature using Cloud Console or gcloud command-line tool. Then, you specify the actual network policy rules using the Kubernetes network policy API or kubectl command-line interface.

See the following guide for information on the specifics of enabling networking features on GKE clusters:

• Internal load balancing
• Alias IPs
• IP masquerade agent
• Network policy

Configuring cluster security

GKE contains a mix of Google Cloud-specific and Kubernetes security features that you can use with your cluster. You can manage Google Cloud-level security, such as Identity and Access Management (IAM), via Google Cloud interfaces like the Cloud Console. You manage intra-cluster security features, such as role-based access control, using Kubernetes APIs and other interfaces.

The following security features are specific to Google Cloud:

• IAM
• IP rotation
• Master authorized networks

Intra-cluster Kubernetes security features you can use on GKE include:

• Role-based access control

Viewing your clusters

gcloudConsole

To view a specific cluster, run the following command:

gcloud container clusters describe cluster-name

To view all clusters in your default zone:

gcloud container clusters list

Setting a default cluster for gcloud

To set a default cluster for gcloud commands, run the following command:

gcloud config set container/cluster cluster-name

Configuring cluster access for kubectl

This page explains how to configure cluster access for the kubectl command-line tool in Google Kubernetes Engine.

Overview

If you run multiple clusters within your Google Cloud project, you need to choose which cluster kubectl talks to. You can set a default cluster for kubectl by setting the current context in Kubernetes' kubeconfig file. Additionally, you can run kubectl commands against a specific cluster using the --cluster flag.

The following sections explain how kubeconfig works, how to set a default cluster for kubectl, and how to run individual kubectl commands against a specific cluster.