Finding the persistent disk in the virtual machine
The persistent disk is now available as a block device in the virtual machine instance. Let's take a look.
go to this instance
You found the file, the default name is:
If you want a different device name, when you attach the disk, you would specify the device-name parameter. For example, to specify a device name, when you attach the disk you would use the command:
Formatting and mounting the persistent disk
Once you find the block device, you can partition the disk, format it, and then mount it using the following Linux utilities:
mkfs: creates a filesystem
mount: attaches to a filesystem
Make a mount point:
Next, format the disk with a single ext4 filesystem using the mkfs tool. This command deletes all data from the specified disk:
Last lines of the output.
Now use the mount tool to mount the disk to the instance with the discard option enabled:
Q: Can you prevent the destruction of an attached persistent disk when the instance is deleted?
A: Yes, deselect the option Delete boot disk when instance is deleted when creating an instance
A:Yes, use the –keep-disks option with the gcloud compute instances delete command
Q: For migrating data from a persistent disk to another region, reorder the following steps in which they should be performed:
Unmount file system(s)
Hello Node Kubernetes
push docker image to instance
Create your cluster
Create a cluster with two n1-standard-1 nodes (this will take a few minutes to complete):
Note: You can also create this cluster through the Console, image shown above: Kubernetes Engine > Kubernetes clusters > Create cluster.
It is recommended to create the cluster in the same zone as the storage bucket used by the container registry (see previous step).
Create your pod
A Kubernetes pod is a group of containers tied together for administration and networking purposes. It can contain single or multiple containers. Here you'll use one container built with your Node.js image stored in your private container registry. It will serve content on port 8080.
Create a pod with the kubectl run command (replace PROJECT_ID with your GCP Project ID, found in the console and in the Connection Details section of the lab):
By default, the pod is only accessible by its internal IP within the cluster. In order to make the hello-node container accessible from outside the Kubernetes virtual network, you have to expose the pod as a Kubernetes service.(預設只有內部 IP 可以讀取)
From Cloud Shell you can expose the pod to the public internet with the kubectl expose command combined with the --type="LoadBalancer" flag. This flag is required for the creation of an externally accessible IP:
To find the publicly-accessible IP address of the service, request kubectl to list all the cluster services:
This is the output you should see:
Scale up your service
One of the powerful features offered by Kubernetes is how easy it is to scale your application. Suppose you suddenly need more capacity for your application. You can tell the replication controller to manage a new number of replicas for your pod:
You can request a description of the updated deployment:
You can also list the all pods:
Roll out an upgrade to your service
At some point the application that you've deployed to production will require bug fixes or additional features. Kubernetes helps you deploy a new version to production without impacting your users.
Modify files & rebuild & push
New version image
To do this, use the kubectl edit command. It opens a text editor displaying the full deployment yaml configuration. It isn't necessary to understand the full yaml config right now, just understand that by updating the spec.template.spec.containers.image field in the config you are telling the deployment to update the pods with the new image.
Modify image & save
Run the following to update the deployment with the new image. New pods will be created with the new image and the old pods will be deleted.
While this is happening, the users of your services shouldn't see any interruption. After a little while they'll start accessing the new version of your application. You can find more details on rolling updates in this documentation.
Hopefully with these deployment, scaling, and updated features, once you've set up your Kubernetes Engine cluster, you'll agree that Kubernetes will help you focus on the application rather than the infrastructure.
Set Up Network and HTTP Load Balancers
In this hands-on lab, you'll learn the differences between a network load balancer and a HTTP load balancer, and how to set them up for your applications running on Google Compute Engine virtual machines.
There are several ways you can load balance in Google Cloud Platform. This lab takes you through the setup of the following load balancers.:
To simulate serving from a cluster of machines, create a simple cluster of Nginx web servers to serve static content using Instance Templates and Managed Instance Groups. Instance Templates define the look of every virtual machine in the cluster (disk, CPUs, memory, etc). Managed Instance Groups instantiate a number of virtual machine instances using the Instance Template.
To create the Nginx web server clusters, create the following:
A startup script to be used by every virtual machine instance to setup Nginx server upon startup
An instance template to use the startup script
A target pool
A managed instance group using the instance template
Still in Cloud Shell, create a startup script to be used by every virtual machine instance. This script sets up the Nginx server upon startup:
Create an instance template, which uses the startup script:
Create a target pool. A target pool allows a single access point to all the instances in a group and is necessary for load balancing in the future steps.
Create a managed instance group using the instance template:
Now configure a firewall so that you can connect to the machines on port 80 via the EXTERNAL_IP addresses:
Create a Network Load Balancer
Network load balancing allows you to balance the load of your systems based on incoming IP protocol data, such as address, port, and protocol type. You also get some options that are not available, with HTTP(S) load balancing. For example, you can load balance additional TCP/UDP-based protocols such as SMTP traffic. And if your application is interested in TCP-connection-related characteristics, network load balancing allows your app to inspect the packets, where HTTP(S) load balancing does not.
Create an L3 network load balancer targeting your instance group:
List all Google Compute Engine forwarding rules in your project.
Create a HTTP(s) Load Balancer
HTTP(S) load balancing provides global load balancing for HTTP(S) requests destined for your instances. You can configure URL rules that route some URLs to one set of instances and route other URLs to other instances. Requests are always routed to the instance group that is closest to the user, provided that group has enough capacity and is appropriate for the request. If the closest group does not have enough capacity, the request is sent to the closest group that does have capacity.
Create a target HTTP proxy to route requests to your URL map:
Create a global forwarding rule to handle and route incoming requests. A forwarding rule sends traffic to a specific target HTTP or HTTPS proxy depending on the IP address, IP protocol, and port specified. The global forwarding rule does not support multiple ports.
After creating the global forwarding rule, it can take several minutes for your configuration to propagate.