In this lab you will complete a series of tasks to ensure your Kubernetes cluster is functioning correctly.
In this section you will verify the ability to encrypt secret data at rest.
Create a generic secret:
kubectl create secret generic kubernetes-the-hard-way \
--from-literal="mykey=mydata"
Print a hexdump of the kubernetes-the-hard-way
secret stored in etcd:
gcloud compute ssh controller-0 \
--command "sudo ETCDCTL_API=3 etcdctl get \
--endpoints=https://127.0.0.1:2379 \
--cacert=/etc/etcd/ca.pem \
--cert=/etc/etcd/kubernetes.pem \
--key=/etc/etcd/kubernetes-key.pem\
/registry/secrets/default/kubernetes-the-hard-way | hexdump -C"
(*) You might need to install hexdump; apt-get install bsdmainutils
output
00000000 2f 72 65 67 69 73 74 72 79 2f 73 65 63 72 65 74 |/registry/secret|
00000010 73 2f 64 65 66 61 75 6c 74 2f 6b 75 62 65 72 6e |s/default/kubern|
00000020 65 74 65 73 2d 74 68 65 2d 68 61 72 64 2d 77 61 |etes-the-hard-wa|
00000030 79 0a 6b 38 73 3a 65 6e 63 3a 61 65 73 63 62 63 |y.k8s:enc:aescbc|
00000040 3a 76 31 3a 6b 65 79 31 3a 7b 8e 59 78 0f 59 09 |:v1:key1:{.Yx.Y.|
00000050 e2 6a ce cd f4 b6 4e ec bc 91 aa 87 06 29 39 8d |.j....N......)9.|
00000060 70 e8 5d c4 b1 66 69 49 60 8f c0 cc 55 d3 69 2b |p.]..fiI`...U.i+|
00000070 49 bb 0e 7b 90 10 b0 85 5b b1 e2 c6 33 b6 b7 31 |I..{....[...3..1|
00000080 25 99 a1 60 8f 40 a9 e5 55 8c 0f 26 ae 76 dc 5b |%..`[email protected]..&.v.[|
00000090 78 35 f5 3e c1 1e bc 21 bb 30 e2 0c e3 80 1e 33 |x5.>...!.0.....3|
000000a0 90 79 46 6d 23 d8 f9 a2 d7 5d ed 4d 82 2e 9a 5e |.yFm#....].M...^|
000000b0 5d b6 3c 34 37 51 4b 83 de 99 1a ea 0f 2f 7c 9b |].<47QK....../|.|
000000c0 46 15 93 aa ba 72 ba b9 bd e1 a3 c0 45 90 b1 de |F....r......E...|
000000d0 c4 2e c8 d0 94 ec 25 69 7b af 08 34 93 12 3d 1c |......%i{..4..=.|
000000e0 fd 23 9b ba e8 d1 25 56 f4 0a |.#....%V..|
000000ea
The etcd key should be prefixed with k8s:enc:aescbc:v1:key1
, which indicates the aescbc
provider was used to encrypt the data with the key1
encryption key.
In this section you will verify the ability to create and manage Deployments.
Create a deployment for the nginx web server:
kubectl run nginx --image=nginx
List the pod created by the nginx
deployment:
kubectl get pods -l run=nginx
output
NAME READY STATUS RESTARTS AGE
nginx-65899c769f-xkfcn 1/1 Running 0 15s
In this section you will verify the ability to access applications remotely using port forwarding.
Retrieve the full name of the nginx
pod:
POD_NAME=$(kubectl get pods -l run=nginx -o jsonpath="{.items[0].metadata.name}")
Forward port 8080
on your local machine to port 80
of the nginx
pod:
kubectl port-forward $POD_NAME 8080:80
output
Forwarding from 127.0.0.1:8080 -> 80
Forwarding from [::1]:8080 -> 80
In a new terminal make an HTTP request using the forwarding address:
curl --head http://127.0.0.1:8080
output
HTTP/1.1 200 OK
Server: nginx/1.13.12
Date: Mon, 14 May 2018 13:59:21 GMT
Content-Type: text/html
Content-Length: 612
Last-Modified: Mon, 09 Apr 2018 16:01:09 GMT
Connection: keep-alive
ETag: "5acb8e45-264"
Accept-Ranges: bytes
Switch back to the previous terminal and stop the port forwarding to the nginx
pod:
Forwarding from 127.0.0.1:8080 -> 80
Forwarding from [::1]:8080 -> 80
Handling connection for 8080
^C
In this section you will verify the ability to retrieve container logs.
Print the nginx
pod logs:
kubectl logs $POD_NAME
output
127.0.0.1 - - [14/May/2018:13:59:21 +0000] "HEAD / HTTP/1.1" 200 0 "-" "curl/7.52.1" "-"
In this section you will verify the ability to execute commands in a container.
Print the nginx version by executing the nginx -v
command in the nginx
container:
kubectl exec -ti $POD_NAME -- nginx -v
output
nginx version: nginx/1.13.12
In this section you will verify the ability to expose applications using a Service.
Expose the nginx
deployment using a NodePort service:
kubectl expose deployment nginx --port 80 --type NodePort
The LoadBalancer service type can not be used because your cluster is not configured with cloud provider integration. Setting up cloud provider integration is out of scope for this tutorial.
Retrieve the node port assigned to the nginx
service:
NODE_PORT=$(kubectl get svc nginx \
--output=jsonpath='{range .spec.ports[0]}{.nodePort}')
Create a firewall rule that allows remote access to the nginx
node port:
- GCP
gcloud compute firewall-rules create kubernetes-the-hard-way-allow-nginx-service \
--allow=tcp:${NODE_PORT} \
--network kubernetes-the-hard-way
- AWS
aws ec2 authorize-security-group-ingress \
--group-id $kubernetes_internal_id \
--protocol tcp \
--port $NODE_PORT \
--cidr 0.0.0.0/0
Retrieve the external IP address of a worker instance:
- GCP
EXTERNAL_IP=$(gcloud compute instances describe worker-0 \
--format 'value(networkInterfaces[0].accessConfigs[0].natIP)')
- AWS
EXTERNAL_IP=$(aws ec2 describe-instances \
--filter Name=vpc-id,Values=$vpcId \
--filter Name=tag:Name,Values=worker-0 \
--query 'Reservations[].Instances[].PublicIpAddress' \
--output text)
Make an HTTP request using the external IP address and the nginx
node port:
curl -I http://${EXTERNAL_IP}:${NODE_PORT}
output
HTTP/1.1 200 OK
Server: nginx/1.13.12
Date: Mon, 14 May 2018 14:01:30 GMT
Content-Type: text/html
Content-Length: 612
Last-Modified: Mon, 09 Apr 2018 16:01:09 GMT
Connection: keep-alive
ETag: "5acb8e45-264"
Accept-Ranges: bytes
This section will verify the ability to run untrusted workloads using gVisor.
Create the untrusted
pod:
cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
name: untrusted
annotations:
io.kubernetes.cri.untrusted-workload: "true"
spec:
containers:
- name: webserver
image: gcr.io/hightowerlabs/helloworld:2.0.0
EOF
In this section you will verify the untrusted
pod is running under gVisor (runsc) by inspecting the assigned worker node.
Verify the untrusted
pod is running:
kubectl get pods -o wide
output
NAME READY STATUS RESTARTS AGE IP NODE
busybox-68654f944b-djjjb 1/1 Running 0 5m 10.200.0.2 worker-0
nginx-65899c769f-xkfcn 1/1 Running 0 4m 10.200.1.2 worker-1
untrusted 1/1 Running 0 10s 10.200.0.3 worker-0
Get the node name where the untrusted
pod is running:
- GCP
INSTANCE_NAME=$(kubectl get pod untrusted --output=jsonpath='{.spec.nodeName}')
- AWS
INSTANCE_NAME=$(kubectl get pod untrusted --output=jsonpath='{.spec.nodeName}')
ip=$(echo ${INSTANCE_NAME} | sed 's/-/_/' | awk '{print "ip_"$1}')
SSH into the worker node:
- GCP
gcloud compute ssh ${INSTANCE_NAME}
- AWS
ssh -l ubuntu ${!ip}
List the containers running under gVisor:
sudo runsc --root /run/containerd/runsc/k8s.io list
output
I0514 14:03:56.108368 14988 x:0] ***************************
I0514 14:03:56.108548 14988 x:0] Args: [runsc --root /run/containerd/runsc/k8s.io list]
I0514 14:03:56.108730 14988 x:0] Git Revision: 08879266fef3a67fac1a77f1ea133c3ac75759dd
I0514 14:03:56.108787 14988 x:0] PID: 14988
I0514 14:03:56.108838 14988 x:0] UID: 0, GID: 0
I0514 14:03:56.108877 14988 x:0] Configuration:
I0514 14:03:56.108912 14988 x:0] RootDir: /run/containerd/runsc/k8s.io
I0514 14:03:56.109000 14988 x:0] Platform: ptrace
I0514 14:03:56.109080 14988 x:0] FileAccess: proxy, overlay: false
I0514 14:03:56.109159 14988 x:0] Network: sandbox, logging: false
I0514 14:03:56.109238 14988 x:0] Strace: false, max size: 1024, syscalls: []
I0514 14:03:56.109315 14988 x:0] ***************************
ID PID STATUS BUNDLE CREATED OWNER
3528c6b270c76858e15e10ede61bd1100b77519e7c9972d51b370d6a3c60adbb 14766 running /run/containerd/io.containerd.runtime.v1.linux/k8s.io/3528c6b270c76858e15e10ede61bd1100b77519e7c9972d51b370d6a3c60adbb 2018-05-14T14:02:34.302378996Z
7ff747c919c2dcf31e64d7673340885138317c91c7c51ec6302527df680ba981 14716 running /run/containerd/io.containerd.runtime.v1.linux/k8s.io/7ff747c919c2dcf31e64d7673340885138317c91c7c51ec6302527df680ba981 2018-05-14T14:02:32.159552044Z
I0514 14:03:56.111287 14988 x:0] Exiting with status: 0
Get the ID of the untrusted
pod:
POD_ID=$(sudo crictl -r unix:///var/run/containerd/containerd.sock \
pods --name untrusted -q)
Get the ID of the webserver
container running in the untrusted
pod:
CONTAINER_ID=$(sudo crictl -r unix:///var/run/containerd/containerd.sock \
ps -p ${POD_ID} -q)
Use the gVisor runsc
command to display the processes running inside the webserver
container:
sudo runsc --root /run/containerd/runsc/k8s.io ps ${CONTAINER_ID}
output
I0514 14:05:16.499237 15096 x:0] ***************************
I0514 14:05:16.499542 15096 x:0] Args: [runsc --root /run/containerd/runsc/k8s.io ps 3528c6b270c76858e15e10ede61bd1100b77519e7c9972d51b370d6a3c60adbb]
I0514 14:05:16.499597 15096 x:0] Git Revision: 08879266fef3a67fac1a77f1ea133c3ac75759dd
I0514 14:05:16.499644 15096 x:0] PID: 15096
I0514 14:05:16.499695 15096 x:0] UID: 0, GID: 0
I0514 14:05:16.499734 15096 x:0] Configuration:
I0514 14:05:16.499769 15096 x:0] RootDir: /run/containerd/runsc/k8s.io
I0514 14:05:16.499880 15096 x:0] Platform: ptrace
I0514 14:05:16.499962 15096 x:0] FileAccess: proxy, overlay: false
I0514 14:05:16.500042 15096 x:0] Network: sandbox, logging: false
I0514 14:05:16.500120 15096 x:0] Strace: false, max size: 1024, syscalls: []
I0514 14:05:16.500197 15096 x:0] ***************************
UID PID PPID C STIME TIME CMD
0 1 0 0 14:02 40ms app
I0514 14:05:16.501354 15096 x:0] Exiting with status: 0
Next: Cleaning Up