Kubernetes/GKE - Revision history

Christoph: /* Deployments */

2021-09-09T06:57:59Z

‎Deployments

Christoph: /* About Roles and RoleBindings */

2020-02-29T11:52:43Z

‎About Roles and RoleBindings

Christoph: /* RBAC */

2020-02-29T11:51:26Z

‎RBAC

Christoph: /* Working with Kubernetes Engine Secrets and ConfigMaps */

2020-02-29T11:49:40Z

‎Working with Kubernetes Engine Secrets and ConfigMaps

Christoph: /* Secrets */

2020-02-29T11:48:52Z

‎Secrets

Christoph: /* StatefulSets */

2020-02-29T11:48:10Z

‎StatefulSets

Christoph: /* Creating Services and Ingress Resources */

2020-02-29T11:45:18Z

‎Creating Services and Ingress Resources

Christoph: /* Restrict outgoing traffic from the Pods */

2020-02-29T11:40:20Z

‎Restrict outgoing traffic from the Pods

Christoph: /* Managing node pools */

2020-02-29T11:36:36Z

‎Managing node pools

Christoph: /* Configure autoscaling on the cluster */

2020-02-29T11:33:00Z

‎Configure autoscaling on the cluster

@@ Line 43: / Line 43: @@
 </pre>
-The output should look like the example. Your output might not be an exact match but it will show that the current revision has rolled back to nginx:1.7.9.
+The output should look like the example. Your output might not be an exact match but it will show that the current revision has rolled back to <code>nginx:1.7.9</code>.
 <pre>
@@ Line 62: / Line 62: @@
 ===Perform a canary deployment===
-A canary deployment is a separate deployment used to test a new version of your application. A single service targets both the canary and the normal deployments. And it can direct a subset of users to the canary version to mitigate the risk of new releases. The manifest file nginx-canary.yaml that is provided for you deploys a single pod running a newer version of nginx than your main deployment. In this task, you create a canary deployment using this new deployment file.
+A canary deployment is a separate deployment used to test a new version of your application. A single service targets both the canary and the normal deployments. And it can direct a subset of users to the canary version to mitigate the risk of new releases. The manifest file <code>nginx-canary.yaml</code> that is provided for you deploys a single pod running a newer version of Nginx than your main deployment. In this task, you create a canary deployment using this new deployment file.
 <pre>
 apiVersion: apps/v1
@@ Line 89: / Line 89: @@
 </pre>
-The manifest for the nginx Service you deployed in the previous task uses a label selector to target the Pods with the app: nginx label. Both the normal deployment and this new canary deployment have the app: nginx label. Inbound connections will be distributed by the service to both the normal and canary deployment Pods. The canary deployment has fewer replicas (Pods) than the normal deployment, and thus it is available to fewer users than the normal deployment.
+The manifest for the Nginx Service you deployed in the previous task uses a label selector to target the Pods with the <code>app: nginx</code> label. Both the normal deployment and this new canary deployment have the <code>app: nginx</code> label. Inbound connections will be distributed by the service to both the normal and canary deployment Pods. The canary deployment has fewer replicas (Pods) than the normal deployment, and thus it is available to fewer users than the normal deployment.
 * Create the canary deployment based on the configuration file.
@@ Line 101: / Line 101: @@
 </pre>
-Switch back to the browser tab that is connected to the external LoadBalancer service ip and refresh the page. You should continue to see the standard "Welcome to nginx" page.
+Switch back to the browser tab that is connected to the external LoadBalancer service IP and refresh the page. You should continue to see the standard "Welcome to nginx" page.
 Switch back to the Cloud Shell and scale down the primary deployment to 0 replicas.
@@ Line 113: / Line 113: @@
 </pre>
-Switch back to the browser tab that is connected to the external LoadBalancer service ip and refresh the page. You should continue to see the standard "Welcome to nginx" page showing that the Service is automatically balancing traffic to the canary deployment.
+Switch back to the browser tab that is connected to the external LoadBalancer service IP and refresh the page. You should continue to see the standard "Welcome to nginx" page showing that the Service is automatically balancing traffic to the canary deployment.
 Note: Session affinity
-The Service configuration used in the lab does not ensure that all requests from a single client will always connect to the same Pod. Each request is treated separately and can connect to either the normal nginx deployment or to the nginx-canary deployment. This potential to switch between different versions may cause problems if there are significant changes in functionality in the canary release. To prevent this you can set the sessionAffinity field to ClientIP in the specification of the service if you need a client's first request to determine which Pod will be used for all subsequent connections.
+The Service configuration used in the lab does not ensure that all requests from a single client will always connect to the same Pod. Each request is treated separately and can connect to either the normal Nginx deployment or to the nginx-canary deployment. This potential to switch between different versions may cause problems if there are significant changes in functionality in the canary release. To prevent this you can set the <code>sessionAffinity</code> field to <code>ClientIP</code> in the specification of the service if you need a client's first request to determine which Pod will be used for all subsequent connections.
 For example:

@@ Line 3,205: / Line 3,205: @@
 Before you can create a Role, your account must have the permissions granted in the role being assigned. For cluster administrators, this can be easily accomplished by creating the following RoleBinding to grant your own user account the cluster-admin role.
-To grant the Username 1 account cluster-admin privileges, run the following command, replacing [USERNAME_1_EMAIL] with the email address of the Username 1 account:
+To grant the Username 1 account cluster-admin privileges, run the following command, replacing <code>[USERNAME_1_EMAIL]</code> with the email address of the Username 1 account:
 <pre>
 $ kubectl create clusterrolebinding cluster-admin-binding --clusterrole cluster-admin --user [USERNAME_1_EMAIL]

@@ Line 2,940: / Line 2,940: @@
 nodes
 persistentvolumes
-</pred>
+</pre>
 ===Kubernetes Control Plane Security===
@@ Line 2,949: / Line 2,949: @@
    --start-credential-rotation
 </pre>
 * Complete credential rotation:
 <pre>
@@ Line 2,954: / Line 2,955: @@
    --complete-credential-rotation
 </pre>
 * Initiate IP rotation:
 <pre>
@@ Line 2,959: / Line 2,961: @@
    --start-ip-rotation
 </pre>
 * Complete IP rotation:
 <pre>

@@ Line 2,424: / Line 2,424: @@
 ===Working with Kubernetes Engine Secrets and ConfigMaps===
-; Set up Cloud Pub/Sub and deploy an application to read from the topic===
+; Set up Cloud Pub/Sub and deploy an application to read from the topic
 * Set the environment variables for the pub/sub components.

@@ Line 2,366: / Line 2,366: @@
    --from-literal password=1234
 </pre>
 * Create a Secret using files:
 <pre>
@@ Line 2,372: / Line 2,373: @@
    --from-file=./password.txt
 </pre>
 * Create a Secret using naming keys:
 $ kubectl create secret generic demo \
    --from-file=User=./username.txt \

@@ Line 2,232: / Line 2,232: @@
 Stateful sets are useful for stateful applications. Stateful sets run and maintain a set of pods just like deployments do. A stateful set object defines the desired state and its controller achieves it. However, unlike deployments, stateful sets maintain a persistent identity for each pod. Each pod in a stateful set maintains a persistent identity and has an ordinal index with the relevant pod name, a stable hostname and stably identified persistent storage that is linked to the ordinal index.
-An ordinal index is just a unique sequential number that is assigned to each pod in the stateful set. This number defines the pod's position in the sets sequence of pods. Deployment, scaling, and updates are ordered using the ordinal index of the pods within a stateful set. For example, if a stateful set named Demo launches three replicas, it will launch pod names Demo-0, Demo-1 and Demo-2 sequentially. This means that all of its predecessors must be running and ready before an action is taken on a newer pod. For example, if Demo-0 is not running and ready, Demo-1 will not be launched. If Demo-0 fails after Demo-1 is running and ready, but before the creation of Demo-2, Demo-2 will not be launched until Demo-0 is relaunched and becomes running and ready. Scaling and ruling updates happen in reverse order. Which means Demo-2 would be changed first. This depends on the pod management policy being set to the default. Ordered ready state. If you want to launch pods in parallel without waiting for the pods to maintain running and ready state, change the pod management policy to parallel. As the name suggests stateful sets are useful for stateful applications. With stable storage, stateful sets use a unique persistent volume claim for each pod. So that each pod can maintain its own individual state. It must have reliable long-term storage to which no other pods write. These persistent volume claims use read write once access mode for applications.
+An ordinal index is just a unique sequential number that is assigned to each pod in the stateful set. This number defines the pod's position in the sets sequence of pods. Deployment, scaling, and updates are ordered using the ordinal index of the pods within a stateful set. For example, if a stateful set named Demo launches three replicas, it will launch pod names Demo-0, Demo-1, and Demo-2 sequentially. This means that all of its predecessors must be running and ready before an action is taken on a newer pod. For example, if Demo-0 is not running and ready, Demo-1 will not be launched. If Demo-0 fails after Demo-1 is running and ready, but before the creation of Demo-2, Demo-2 will not be launched until Demo-0 is relaunched and becomes running and ready. Scaling and ruling updates happen in reverse order. Which means Demo-2 would be changed first. This depends on the pod management policy being set to the default. Ordered ready state. If you want to launch pods in parallel without waiting for the pods to maintain running and ready state, change the pod management policy to parallel. As the name suggests stateful sets are useful for stateful applications. With stable storage, stateful sets use a unique persistent volume claim for each pod. So that each pod can maintain its own individual state. It must have reliable long-term storage to which no other pods write. These persistent volume claims use read write once access mode for applications.
 * StatefulSet Example (with associated Service):

@@ Line 1,349: / Line 1,349: @@
 The ping fails because we are not inside the cluster itself.
-To get inside the cluster, open an interactive session to Bash running from dns-demo-1.
+To get inside the cluster, open an interactive session to Bash running from <code>dns-demo-1</code>.
 <pre>
 $ kubectl exec -it dns-demo-1 /bin/bash
@@ Line 1,363: / Line 1,363: @@
 * Ping dns-demo-2:
 <pre>
-root@dns-demo-1:/# ping dns-demo-2.dns-demo.default.svc.cluster.local -c 3
+root@dns-demo-1:/# ping -c3 dns-demo-2.dns-demo.default.svc.cluster.local
 PING dns-demo-2.dns-demo.default.svc.cluster.local (10.8.2.5) 56(84) bytes of data.
 bytes from dns-demo-2.dns-demo.default.svc.cluster.local (10.8.2.5): icmp_seq=1 ttl=62 time=1.46 ms
@@ Line 1,466: / Line 1,466: @@
 The connection should fail because that service is not exposed outside of the cluster.
-Now, test the Service from ''inside'' the cluster using the interactive shell you have running on the <code>dns-demo-1 Pod</code>. Return to your first Cloud Shell window, which is currently redirecting the STDIN and STDOUT of the <code>dns-demo-1</code> Pod.
+Now, test the Service from ''inside'' the cluster using the interactive shell you have running on the <code>dns-demo-1</code> Pod. Return to your first Cloud Shell window, which is currently redirecting the STDIN and STDOUT of the <code>dns-demo-1</code> Pod.
 * Install curl so you can make calls to web services from the command line:
@@ Line 1,484: / Line 1,484: @@
 ; Convert the service to use NodePort
-In this section, we will convert our existing ClusterIP service to a NodePort service and then retest access to the service from inside and outside the cluster.
+In this section, we will convert our existing <code>ClusterIP</code> service to a <code>NodePort</code> service and then retest access to the service from inside and outside the cluster.
 * Apply a modified version of our previous <code>hello-svc</code> Service manifest:
@@ Line 1,720: / Line 1,720: @@
 You may have to wait for a few minutes for the load balancer to become active, and for the health checks to succeed, before the external address will be displayed. Repeat the command every few minutes to check if the Ingress resource has finished initializing.
-Use the External IP address associated with the Ingress resource, and type the following command, substituting [external_IP] with the Ingress resource's external IP address. Be sure to include the /v1 in the URL path:
+Use the External IP address associated with the Ingress resource, and type the following command, substituting [external_IP] with the Ingress resource's external IP address. Be sure to include the <code>/v1</code> in the URL path:
 <pre>
 $ curl 35.244.213.159/v1
@@ Line 1,728: / Line 1,728: @@
 </pre>
-The v1 URL is configured in hello-ingress.yaml to point to the hello-svc NodePort service that directs traffic to the v1 application Pods.
+The v1 URL is configured in <code>hello-ingress.yaml</code> to point to the <code>hello-svc</code> NodePort service that directs traffic to the v1 application Pods.
 Note: GKE might take a few minutes to set up forwarding rules until the Global load balancer used for the Ingress resource is ready to serve your application. In the meantime, you might get errors such as HTTP 404 or HTTP 500 until the load balancer configuration is propagated across the globe.
-* Now, test the v2 URL path from Cloud Shell. Use the External IP address associated with the Ingress resource, and type the following command, substituting [external_IP] with the Ingress resource's external IP address. Be sure to include the /v2 in the URL path.
+* Now, test the v2 URL path from Cloud Shell. Use the External IP address associated with the Ingress resource, and type the following command, substituting <code>[external_IP]</code> with the Ingress resource's external IP address. Be sure to include the <code>/v2</code> in the URL path.
 <pre>
 $ curl [external_IP]/v2
@@ Line 1,744: / Line 1,744: @@
 There are two load balancers listed:
-# One was created for the external IP of the hello-lb-svc service. This typically has a UID style name and is configured to load balance TCP port 80 traffic to the cluster nodes.
+# One was created for the external IP of the <code>hello-lb-svc</code> service. This typically has a UID style name and is configured to load balance TCP port 80 traffic to the cluster nodes.
 # The second was created for the Ingress object and is a full HTTP(S) load balancer that includes host and path rules that match the Ingress configuration. This will have hello-ingress in its name.
 Click the load balancer with hello-ingress in the name. This will display the summary information about the protocols, ports, paths and backend services of the Ingress load balancer.
-The v2 URL is configured in hello-ingress.yaml to point to the hello-lb-svc LoadBalancer service that directs traffic to the v2 application Pods.
+The v2 URL is configured in <code>hello-ingress.yaml</code> to point to the hello-lb-svc LoadBalancer service that directs traffic to the v2 application Pods.
 ==Load balancing objects in GKE==

@@ Line 1,178: / Line 1,178: @@
 ===Restrict outgoing traffic from the Pods===
-You can restrict outgoing (egress) traffic as you do incoming traffic. However, in order to query internal hostnames (such as hello-web) or external hostnames (such as www.example.com), you must allow DNS resolution in your egress network policies. DNS traffic occurs on port 53, using TCP and UDP protocols.
+You can restrict outgoing (egress) traffic as you do incoming traffic. However, in order to query internal hostnames (such as <code>hello-web</code>) or external hostnames (such as <code>www.example.com</code>), you must allow DNS resolution in your egress network policies. DNS traffic occurs on port 53, using TCP and UDP protocols.
-The following NetworkPolicy manifest file defines a policy that permits Pods with the label <code>app: foo</code> to communicate with Pods labeled app: hello on any port number, and allows the Pods labeled app: foo to communicate to any computer on UDP port 53, which is used for DNS resolution. Without the DNS port open, you will not be able to resolve the hostnames:
+The following NetworkPolicy manifest file defines a policy that permits Pods with the label <code>app: foo</code> to communicate with Pods labeled <code>app: hello</code> on any port number, and allows the Pods labeled <code>app: foo</code> to communicate to any computer on UDP port 53, which is used for DNS resolution. Without the DNS port open, you will not be able to resolve the hostnames:
 <pre>
 $ cat << EOF > foo-allow-to-hello.yaml
@@ Line 1,214: / Line 1,214: @@
 ; Validate the egress policy
-* Deploy a new web application called hello-web-2 and expose it internally in the cluster:
+* Deploy a new web application called <code>hello-web-2</code> and expose it internally in the cluster:
 <pre>
 $ kubectl run hello-web-2 --labels app=hello-2 \
@@ Line 1,220: / Line 1,220: @@
 </pre>
-* Run a temporary Pod with the app=foo label and get a shell prompt inside the container:
+* Run a temporary Pod with the <code>app=foo</code> label and get a shell prompt inside the container:
 <pre>
 $ kubectl run test-3 --labels app=foo --image=alpine --restart=Never --rm --stdin --tty
@@ Line 1,238: / Line 1,238: @@
 wget -qO- --timeout=2 http://hello-web-2:8080
 </pre>
-This fails because none of the Network policies you have defined allow traffic to Pods labelled app: hello-2.
+This fails because none of the Network policies you have defined allow traffic to Pods labelled <code>app: hello-2</code>.
-* Verify that the Pod cannot establish connections to external websites, such as www.example.com:
+* Verify that the Pod cannot establish connections to external websites, such as <code>www.example.com</code>:
 <pre>
 wget -qO- --timeout=2 http://www.example.com
@@ Line 1,247: / Line 1,247: @@
 <pre>
-/ # ping 8.8.8.8 -c 3
+/ # ping -c3 8.8.8.8
 PING 8.8.8.8 (8.8.8.8): 56 data bytes

@@ Line 656: / Line 656: @@
 To add a taint to each of the newly created nodes, execute the following command.
-You can use the temp=true label to apply this change across all the new nodes simultaneously.
+You can use the <code>temp=true</code> label to apply this change across all the new nodes simultaneously.
 <pre>
 $ kubectl taint node -l temp=true nodetype=preemptible:NoExecute
@@ Line 671: / Line 671: @@
 To allow application Pods to execute on these tainted nodes, you must add a tolerations key to the deployment configuration.
-Edit the web.yaml file to add the following key in the template's spec section:
+Edit the <code>web.yaml</code> file to add the following key in the template's <code>spec</code> section:
 <pre>
 tolerations:
@@ Line 695: / Line 695: @@
 </pre>
-To force the web deployment to use the new node-pool add a nodeSelector key in the template's spec section. This is parallel to the tolerations key you just added.
+To force the web deployment to use the new node-pool add a <code>nodeSelector</code> key in the template's spec section. This is parallel to the tolerations key you just added.
 <pre>
       nodeSelector:
          temp: "true"
 </pre>
-Note: GKE adds a custom label to each node called cloud.google.com/gke-nodepool that contains the name of the node-pool that the node belongs to. This key can also be used as part of a nodeSelector to ensure Pods are only deployed to suitable nodes.
+Note: GKE adds a custom label to each node called <code>cloud.google.com/gke-nodepool</code>, which contains the name of the node-pool that the node belongs to. This key can also be used as part of a <code>nodeSelector</code> to ensure Pods are only deployed to suitable nodes.
-The full web.yaml deployment should now look as follows.
+The full <code>web.yaml</code> deployment should now look as follows:
 <pre>
 apiVersion: extensions/v1beta1
@@ Line 737: / Line 737: @@
 </pre>
-If you have problems editing this file successfully you can use the pre-prepared sample file called web-tolerations.yaml instead.
+If you have problems editing this file successfully, you can use the pre-prepared sample file called <code>web-tolerations.yaml</code> instead.
 * Get the list of Pods:
@@ Line 746: / Line 746: @@
 </pre>
-To confirm the change, inspect the running web Pod(s) using the following command
+To confirm the change, inspect the running web Pod(s) using the following command:
 <pre>
 $ kubectl describe pods -l run=web
 </pre>
-A Tolerations section with nodetype=preemptible in the list should appear near the bottom of the (truncated) output.
+A Tolerations section with <code>nodetype=preemptible</code> in the list should appear near the bottom of the (truncated) output.
 <pre>
 ...
@@ Line 764: / Line 764: @@
 The output confirms that the Pods will tolerate the taint value on the new preemptible nodes, and thus that they can be scheduled to execute on those nodes.
-To force the web application to scale out again scale the loadgen deployment back to four replicas.
+To force the web application to scale out again, scale the loadgen deployment back to four replicas:
 <pre>
 $ kubectl scale deployment loadgen --replicas 4
 </pre>
-You could scale just the web application directly but using the loadgen app will allow you to see how the different taint, toleration and nodeSelector settings that apply to the web and loadgen applications affect which nodes they are scheduled on.
+You could scale just the web application directly but using the loadgen app will allow you to see how the different taint, toleration and <code>nodeSelector</code> settings that apply to the web and loadgen applications affect which nodes they are scheduled on.
-Get the list of Pods using thewide output format to show the nodes running the Pods
+Get the list of Pods using the wide output format to show the nodes running the Pods:
 <pre>
 $ kubectl get pods -o wide
 </pre>
-This shows that the loadgen app is running only on default-pool nodes while the web app is running only the preemptible nodes in temp-pool-1.
+This shows that the loadgen app is running only on <code>default-pool</code> nodes while the web app is running only the preemptible nodes in <code>temp-pool-1</code>.
 The taint setting prevents Pods from running on the preemptible nodes so the loadgen application only runs on the default pool. The toleration setting allows the web application to run on the preemptible nodes and the nodeSelector forces the web application Pods to run on those nodes.

@@ Line 498: / Line 498: @@
 </pre>
-; Inspect the HorizontalPodAutoscaler object
+; Inspect the ''Horizontal Pod Autoscaler'' object
-The kubectl autoscale command you used in the previous task creates a HorizontalPodAutoscaler object that targets a specified resource, called the scale target, and scales it as needed. The autoscaler periodically adjusts the number of replicas of the scale target to match the average CPU utilization that you specify when creating the autoscaler.
+The kubectl auto-scale command you used in the previous task creates a HorizontalPodAutoscaler object that targets a specified resource, called the scale target, and scales it as needed. The auto-scaler periodically adjusts the number of replicas of the scale target to match the average CPU utilization that you specify when creating the auto-scaler.
-* To get the list of HorizontalPodAutoscaler resources, execute the following command:
+* To get the list of ''Horizontal Pod Autoscaler'' resources, execute the following command:
 <pre>
 $ kubectl get hpa
@@ Line 509: / Line 509: @@
 </pre>
-* To inspect the configuration of HorizontalPodAutoscaler in YAML form, execute the following command:
+* To inspect the configuration of ''Horizontal Pod Autoscaler'' in YAML form, execute the following command:
 <pre>
 $ kubectl describe horizontalpodautoscaler web
 Name:                                                  web
 Namespace:                                             default
@@ Line 537: / Line 536: @@
 You need to create a heavy load on the web application to force it to scale out. You create a configuration file that defines a deployment of four containers that run an infinite loop of HTTP queries against the sample application web server.
-You create the load on your web application by deploying the loadgen application using the loadgen.yaml file that has been provided for you.
+You create the load on your web application by deploying the loadgen application using the <code>loadgen.yaml</code> file that has been provided for you.
 <pre>
 apiVersion: apps/v1
@@ Line 570: / Line 569: @@
 </pre>
-* Inspect HorizontalPodAutoscaler:
+* Inspect the ''Horizontal Pod Autoscaler'':
 <pre>
 $ kubectl get hpa
@@ Line 579: / Line 578: @@
 Once the loadgen Pod starts to generate traffic, the web deployment CPU utilization begins to increase. In the example output, the targets are now at 35% CPU utilization compared to the 1% CPU threshold.
-* After a few minutes, inspect the HorizontalPodAutoscaler again:
+* After a few minutes, inspect the ''Horizontal Pod Autoscaler'' again:
 <pre>
 $ kubectl get hpa