The document outlines a comprehensive overview of Kubernetes, covering topics such as container recall, Kubernetes architecture, and key concepts such as pods, deployments, and services. It also discusses Kubernetes' role in automating container management and provides insights into important features like RBAC, networking, and storage solutions. Additionally, it includes demos on setting up a Kubernetes cluster and deploying applications like WordPress, along with practical commands for resource management.

1. BAO HUYNH
Site Reliabity Engineering

2. I. CONTAINER RECALL
II. KUBERNETES – A RISING HERO
III. K8S ARCHITECTURE
IV. KEY CONCEPTS
V. DEMOS
AGENDA

3. AGENDA
I. CONTAINER RECALL
○ Microservice & Container approach
○ Docker
II. KUBERNETES – A RISING HERO
III. K8S ARCHITECTURE
IV. KEY CONCEPTS
V. DEMOS

4. I.CONTAINER RECALL

5. I.CONTAINER RECALL

6. I.CONTAINER RECALL
CaaS (Container as a Servicer)

7. AGENDA
I. DOCKER RECALL
II. KUBERNETES – A RISING HERO
o Kuber-what ?
o Why Kuberenetes
III. K8S ARCHITECTURE
IV. KEY CONCEPTS

8. “Kubernetes is an open-source platform for :
- automating deployment
- scaling
- operations of containers
across cluster of host
à providing container-centric infrastructure”
- from Kubernetes’ father with love -
II.KUBERNETES – A RISING HERO

9. II.KUBERNETES – A RISING HERO

10. II.KUBERNETES – A RISING HERO
/ CU-BÉ NÉ-ĐỊT /

11. II.KUBERNETES – A RISING HERO

12. II.KUBERNETES – A RISING HERO

13. KUBERNETES, WHY ?
VM1
# ssh root@VM1
# docker run nginx –p 8080:80 …
VM2
# ssh root@VM2
# docker run nginx –p 8080:80 …
…...
…...
…...
II.KUBERNETES – A RISING HERO

14. KUBERNETES, WHY ?

15. • Deployment/Provision one or multiple containers
• Replicas of containers on multihost
• Data volumes for persistent storage management
• Multihost Overlay networking
• ……..
KUBERNETES, WHY ?
II.KUBERNETES – A RISING HERO

16. AGENDA
I. DOCKER RECALL
II. KUBERNETES – A RISING HERO
III. K8S ARCHITECTURE
○ Master node
○ Worker node
○ Additional Services
IV. KEY CONCEPTS
V. DEMOS

18. Master (Control plane for Kubernetes)
● kube-API Server: gatekeeper to handle HTTP request
between control plan & workers.
● kube-Scheduler: evaluates workload and place it on a
matching resource
● kube-Cluster controller: manages all core component
control loops:
- Monitors the cluster state via the apiserver
- Steers the cluster towards the desired state with
cloud-provider (AWS, GCP, Azure,..) component.
● etcd: provide highly available key-value database
III. K8S ARCHITECTURE

19. ● the ‘place’, where pod/containers run on,
care ‘workload’ of cluster
● Daemon:
- kubelet: managing pod lifecycle on its
host + interact with APIServer (master)
- kube-proxy: load balancing/connection
forwarding between pods.
Nodes/Workers
III. K8S ARCHITECTURE

20. § Kube-dns - Provides cluster wide DNS Services. Services
are resolvable to <service>.<namespace>.svc.cluster.local.
§ Heapster - Metrics Collector for kubernetes cluster, used by
some resources: Horizontal Pod Autoscaler or Dashboard
Metrics,…
§ Kube-dashboard - A general purpose web based UI for
kubernetes.
III. K8S ARCHITECTURE
Additional Services

21. AGENDA
I. DOCKER RECALL
II. KUBERNETES – A RISING HERO
III. K8S ARCHITECTURE
IV. KEY CONCEPTS
○ Pod/Deloyment/Service
○ Storage
○ ConfigMap/Secret
○ Authentication and Identity with RBAC
○ Networking
V. DEMOS

22. POD *
DEPLOYEMENT *
SERVICE *

23. Pod - A pod is the smallest unit of work/management
resource within Kubernetes.
Pods comprise of:
IV. KEY CONCEPTS (Pod)

24. Pod - example manisfest
IV. KEY CONCEPTS (Pod)

25. ReplicationController – keeps track of pod replicas and their
lifecycle.
ReplicaSet - Next Generation ReplicationController. Supports
set-based selectors.
IV. KEY CONCEPTS (Deployement)

26. Deployment
§ Type of replicaton - backed by ReplicaSets
§ Keeps track of state change history
§ Provides scaling/update/rollback functionality
IV. KEY CONCEPTS (Deployement)

27. SCALING
IV. KEY CONCEPTS (manual scaling deployment)
kubectl scale deployments/kubernetes-bootcamp --replicas=4

28. IV. KEY CONCEPTS (Deployement update 1/3)

29. IV. KEY CONCEPTS (Deployement update 2/3)

30. IV. KEY CONCEPTS (Deployement rollback 3/3)

31. DaemonSet - Pod will run on all
healthy nodes (Bypasses default
schedule)
Use case: Ideal for cluster wide
services such as log forwarding, or
health monitoring.
IV. KEY CONCEPTS (DaemonSet)

32. IV. KEY CONCEPTS (Deployment Summary)
Node Scope Scaling/Update/
Rollback
Label-Selector
support
ReplicationController One/Multiple/All No No
ReplicationSet One/Multiple/All No Yes
Deployment One/Multiple/All Yes Yes
DaemonSet All (mandatory)
(by pass scheduler)
No Yes

33. Service
● Logical set of Pods (and ways to access them)
● Four major Service Types:
○ CluterIP – internal access only
○ NodePort – external access via port on host
(mapping port containter = port on host)
○ LoadBalancer – external access via a
loadBalancer static IP (created by AWS, GCP,…
○ ExternalName - used to references endpoints
OUTSIDE the cluster by providing a static
internally referenced DNS name.
IV. KEY CONCEPTS (Service)

34. Put things together (Pod + Deployment + Service)

35. IV. KEY CONCEPTS (Pod/Deployement/Service)

36. LABEL &
SELECTOR

37. Ø Label - Key-value pairs that are used to identify,
describe and group together related sets of objects.
Ø Selector - Selectors use labels to filter/select objects.
Support 2 kinds of selection:
● Equality-based selector: (=, ==, !=)
● Set-based selector: ( In, NotIn, Exists, DoesNotExist )
IV. KEY CONCEPTS (labels & selector)

38. IV. KEY CONCEPTS (labels & selector)

39. Labels:
app: nginx
tier: frontned
Annotations
description: “nginx frontend”
Selector:
app: nginx
tier: frontend
IV. KEY CONCEPTS (labels & selector)
Equality-based selectors

40. Set-based selectors
Valid Operators:
● In
● NotIn
● Exists
● DoesNotExist
Supported Objects with set-
based selectors:
● Job
● Deployment
● ReplicaSet
● DaemonSet
● PersistentVolumeClaims
IV. KEY CONCEPTS (labels & selector)

41. STORAGE

42. Volume - Storage that is tied to the Pod
Lifecycle, consumable by one/more
containers within the pod (local resource)
IV. KEY CONCEPTS (Storage)

43. PersistentVolume (PV) -
represents a external
resource (linked to a backing
storage resource: NFS,
GCEPersistentDisk, EFS,..).
Lifecycle are provisioned
ahead of time &
independently from a pod.
IV. KEY CONCEPTS (Storage)

44. PersistentVolumeClaim
● mapping PV to pod’s storage.
● PVCs are scoped to namespaces
● Supports accessModes like PVs
IV. KEY CONCEPTS (Volume-Claim)

45. ● Abstraction on top of
Persisten Volume with
configuration
● Uses an external system
defined by the provisioner to
dynamically consume and
allocate storage.
● Storage Class Fields
○ Provisioner
○ Parameters
○ reclaimPolicy
IV. KEY CONCEPTS (Storage class)

47. CONFIGMAP
&
SECRET

48. ConfigMap - shared variable/value between pods.
Could be retrieved by 2 ways:
q Pod’s Environment variable
q Volume mount
Secret - Functionally identical to ConfigMaps, but stored
encoded as base64, and encrypted at rest (if configured).
IV. KEY CONCEPTS (ConfigMap/Secret)

49. ● Can be used in Pod Config:
○ Injected as a file in Volume Mount
○ Passed as an environment variable
IV. KEY CONCEPTS (ConfigMap/Secret)

50. AUTHENTICATION
WITH RBAC
(role-based access control)

51. K8S AUTHENTICATION MODEL
ServiceAccount
(defined at Pod)
RoleBinding/
ClusterRoleBinding
Role/
ClusterRole
API Server
Pod’s Token
(Authencate via RBAC plugin)
(Who-will-do)(What-to-do)
(ex: HTTP request
GET,POST,PUSH,DELETE
MASTER NODE
WORKER NODE
transfer
IV. KEY CONCEPTS (RBAC)

52. Architecture
Overview

53. Who
am I
???
Why
am I
here
???

54. [Cluster]Role
● Manage Resource
Permissions
● Resources: target
(pods/deployment/…)
● Verbs: actions
(get/list/watch/…)
IV. KEY CONCEPTS (RBAC)

55. ● Mapping permission
of [Cluster]Role to
specific subjects:
○ User
○ Group
○ ServiceAccount
[Cluster]RoleBinding
IV. KEY CONCEPTS (RBAC)

56. IV. KEY CONCEPTS (RBAC)

58. 1) All Pods can communicate with all other Pods without NAT
2) All nodes can communicate with all Pods (and vice-versa) without NAT.
3) The IP that a Pod sees itself as is the same IP that others see it as.
- from Kubernetes’ mother with love -
IV. KEY CONCEPTS (Networking)

59. IV. KEY CONCEPTS (Networking)
Containers talks in same Pod:
+ Use the same ClusterIP
+ Communicate via IPC/not via network

60. IV. KEY CONCEPTS (Networking)
Pods talks in
same Node

61. IV. KEY CONCEPTS (Networking)
Pods talks in Kubernetes cluster (1/3)
1) All Pods can
communicate with
all other Pods
without NAT

62. Pods talks in Kubernetes cluster (2/3)
IV. KEY CONCEPTS (Networking)

63. IV. KEY CONCEPTS (Networking)
Pods talks in Kubernetes cluster (3/3)

64. IV. KEY CONCEPTS (Networking)

65. AGENDA
I. DOCKER RECALL
II. KUBERNETES – A RISING HERO
III. K8S ARCHITECTURE
IV. KEY CONCEPTS
V. DEMOS
○ Horizontal Pod Autoscaling (HPA)
○ Wordpress webpage

66. IV. DEMO (HPA)
Demand
Capacity
Time
Resources
Autoscaling
Resources

67. IV. DEMO (HPA)
Kubelet daemon on each node
collect information metrics
(RAM,CPU,..) about pods
à Sent back to Metrics Server
(on Master node) for making
decision (scale-up/scale-down)

68. AGENDA
I. DOCKER RECALL
II. KUBERNETES – A RISING HERO
III. K8S ARCHITECTURE
IV. KEY CONCEPTS
V. DEMOS
○ Horizontal Pod Autoscaling (HPA)
○ Wordpress webpage

69. ● Setup Kubernetes cluster on AWS EC2,
including etcds, master, workers (nodes)
● Deploy a WordPress site on Kubernetes
with default page at /
● Use Ingress for load balancing in
Kubernetes
● User request http://<dns_site>/careers, the
browser will be redirected to default page
(at /)
IV. DEMO (webpage requirement)

70. q AWS as cloud-provider
q Kubernetes cluster setup (master/workers)
q Wordpress container (deploy on all worker)
Backend storage for wordpress (EFS volume1)
q Mysql container as database
Backend storage for mysql (EFS volume2)
q Ingress/Ingress controller for loadbalancing & path-
based routing
IV. DEMO (webpage analysis)

72. QUESTIONS &
a little ANSWERS

74. # Deploy resources through manifest
kubectl create -f <name_of_manifeset>
Ex: kubectl create -f nginx.yaml
# Delete resource trough manifest
kubectl delete -f <name_of_manifeset>
Ex: kubectl delete -f nginx.yaml
# List resource on specific namespace,
# if not specify (--namespace=default) will be used.
kubectl get pods --namespace=foo
deployments
rolebindings
……..
# Get running logs of specific pod
kubectl logs <name_of_pod>
# Get details of resource (endpoint, configuration, container, resource usage,..)
kubectl describe pods <name_of_pod> --namespace=foo
deployments <name_of_deployment>
rolebindings <name_of_rolebindings>
Common kubectl command (1/3)

75. # Check the status of control plan (master node)
kubectl get componentstatuses
# Get ALL pods/deployement/services/nodes
kb get ingress,nodes,pods,services,deployments --all-namespaces
kb get all --all-namespaces
# Export information about pods/deployment/services/nodes into YAML,JSON,...
kubectl get nodes -o yaml | grep ExternalIP -C 1
kubectl get pods -o yaml | grep podIP
# Export information with COLUMN Customization
kubectl get po -o custom-columns=POD:metadata.name,NODE:spec.nodeName --sort-by
spec.nodeName -n kube-system
# View resource usage on each pod/node
kubectl top pods/nodes
Common kubectl command (2/3)

76. Common kubectl command (3/3)
# Attach to container & run specific cmd inside it
kubectl exec -it <name_of_pod> <linux_cmd_to_run>
Ex: kubectl exec –it nginx_app_axere1234 curl 10.20.30.40:443
kubectl exec –it nginx_app_adfb987 bash à login to shell of container
# Rolling Update
kubectl set image deployment/nginx-deployment nginx-container=nginx:1.15.4
# Checkstatus of rolling Update
kubectl rollout status deployment/nginx-deployment
# Rollout/Rollback to previous state
kubectl rollout undo deployment/nginx-deployment
# Get health-check of Kubernetes Cluster
kops validate cluster