Kubernetes basic concept, architecture 쿠버네티스

1. Kubernetes
#1. Intro
조대협 (http://bcho.tistory.com)

2. Agenda
● Container management & Kubernetes
● Concept
● Architecture & component
● Pattern
● Runtime

3. Container
management &
Kubernetes

4. What is Docker?
● Docker is a software platform for building and
running containers.
● The Docker Engine is the container runtime that
builds, runs, and monitors containers.
● It uses underlying Linux kernel features such as
cgroups, namespaces, and copy-on-write
storage.
● Docker Engine is not the only container runtime.
Other runtimes include LXC, systemd-nspawn,
CoreOS rkt, and more.
*Images provided by Docker
others:
LXC
systemd-nspawn
rkt
...

5. Where to we deploy container?
Node
Container
Node Node Node Node
…...
Container
2 CPU, 4GB
Where ?

6. Container mgmt tool trend

7. Kubernetes
● Open source container management solution
● Support multiple environment, including “Your
laptop”, “bare metal”, “OpenStack”, “Google
Cloud”,”Amazon Web Service”, “MS azure”
● Implemented by Go lang

8. Concept

9. General concept
Kubernetes cluster layout
Source : https://www.oreilly.com/webops-perf/free/kubernetes.csp

10. Concept
Component
● It consists of kubernetes cluster.
● It creates object
● Master component, Node component
Object
● Created by component

11. Pod
● Basic building block and the smallest unit
● It can contains 1..N container in it
● Recommend to use 1..2 container per
pod
● It can share IP address and local disk
Pods
Container
Container
Application
Envoy
Zipkin collector
Log collector
(Logstash, fluentd)
Disk volume
Share
Share
Same IP
apiVersion: v1
kind: Pod
metadata:
name: nginx
spec:
containers:
- name: nginx
image: nginx:1.7.9
ports:
- containerPort: 80

12. Service
● Logical set of Pod
● The set of pods targeted by a
service is (usually) determined by
Label Selector
● Service with selector : For
headless services that define
selectors, the endpoints
controller creates Endpoints
kind: Service
apiVersion: v1
metadata:
name: my-service
spec:
selector:
app: MyApp
ports:
- protocol: TCP
port: 80
targetPort: 9376
Service definition with
selector

13. Service
{
"kind": "Service",
"apiVersion": "v1",
"metadata": {
"name": "my-service"
},
"spec": {
"selector": {
"app": "MyApp"
},
"ports": [
{
"protocol": "TCP",
"port": 80,
"targetPort": 9376
}
]
}
}
Pod 1
labels: app=MyApp
port: 9376
Pod 2
labels: app=MyApp
port: 9376
Pod 3
labels: app=MyApp
port: 9376
kube-proxy
Port 80
Port 9376

14. Service
● For headless services that do not define selectors, the endpoints controller
does not create Endpoints records. However, the DNS system looks for and
configures either:
○ CNAME records for ExternalName-type services.
○ A records for any Endpoints that share a name with the service, for all other types.
kind: Service
apiVersion: v1
metadata:
name: my-service
spec:
ports:
- protocol: TCP
port: 80
targetPort: 9376
kind: Endpoints
apiVersion: v1
metadata:
name: my-service
subsets:
- addresses:
- ip: 1.2.3.4
ports:
- port: 9376
Because this service has no selector, the
corresponding Endpoints object will not
be created. You can manually map the
service to your own specific endpoints:

15. Volume
● Local disk at container is ephemeral.
● Volume is persistent disk
● Type of volumes : awsEBS, gcePD,cephfs etc.
● SubPath : one volume can be mounted to multiple path
(Volume /mysql → Mount /var/lib/mysql, volume /html → mount
/var/www/html)
● Volume vs PersistentVolume(PV)

16. Namespace
● Kubernetes namespaces can be seen as a logical entity used to represent cluster resources for
usage of a particular set of users
● example ) Dev,Test,QA,Stating,production etc
# Assign dev context to development namespace
kubectl config set-context dev --namespace=dev --cluster=minikube --user=minikube
# Assign qa context to QA namespace
kubectl config set-context qa --namespace=qa --cluster=minikube --user=minikube
# Assign prod context to production namespace
kubectl config set-context prod --namespace=prod --cluster=minikube --user=minikube
Assign a context to namespace
# Switch to Dev context
kubectl config use-context dev
# Switch to QA context
kubectl config use-context qa
Switch context
kubectl get pods
kubectl get deployments
Run command in a context
Reference : https://dzone.com/articles/the-why-and-how-of-kubernetes-namespaces

17. Namespace
DNS
● When you create a Service, it creates a corresponding DNS entry. This entry is of the form
<service-name>.<namespace-name>.svc.cluster.local
Not all objects are in a Namespace
Most Kubernetes resources (e.g. pods, services, replication controllers, and others) are in some
namespaces. However namespace resources are not themselves in a namespace

18. Label
● Labels are key/value pairs that are attached to objects, such as pods
"metadata": {
"labels": {
"key1" : "value1",
"key2" : "value2"
}
}
environment in (production, qa)
tier notin (frontend, backend)
partition
!partition
environment = production
tier != frontend
Label Selector
Equality based selector
(used by ReplicaController)
Set based selector
(used by ReplicaSet)

19. Replication Controller
● ReplicationController ensures that a
specified number of pod replicas are running
at any one time
● Pod Template : same schema as a pod,
except it is nested and does not have an
apiVersion or kind.
● Replicaset Label :same schema as a pod,
except it is nested and does not have an
apiVersion or kind.
● Replication controller with Service
Multiple ReplicationControllers can sit behind
a single service, so that, for example, some
traffic goes to the old version, and some goes
to the new version.
replication.yaml docs/concepts/workloads/controllers
apiVersion: v1
kind: ReplicationController
metadata:
name: nginx
spec:
replicas: 3
selector:
app: nginx
template:
metadata:
name: nginx
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx
ports:
- containerPort: 80
Pod template
select

20. Replicaset
● ReplicaSet is the next-generation ReplicationController that supports the new set-based label
selector
● Deployment is a higher-level concept that manages ReplicaSets and provides declarative updates to
pods along with a lot of other useful features. Therefore, we recommend using Deployments
instead of directly using ReplicaSets, unless you require custom update orchestration or don’t
require updates at all

21. Deployment
● Deployment is a higher-level API object that updates its underlying Replica Sets and their Pods in
a similar fashion as kubectl rolling-update
● Deployments are recommended if you want this rolling update functionality, because unlike
kubectl rolling-update, they are declarative, server-side, and have additional features.
kubectl run hello-server --image gcr.io/google-samples/hello-app:1.0 --port 8080
This Kubernetes command, kubectl run, creates a new Deployment named hello-server. The Deployment's Pod
runs the hello-app image in its containe
kubectl expose deployment hello-server --type "LoadBalancer"
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

22. Statefulset

23. Daemonset

24. Job

25. Architecture &
Components

26. Kubernetes architecture
Image from : https://kubernetes.io/docs/concepts/architecture/

27. Kubernetes architecture

28. Kubernetes architecture components
Master component
● Master components provide the cluster’s control plane.
● Master components make global decisions about the cluster (for example, scheduling), and
detecting and responding to cluster events (starting up a new pod when a replication controller’s
‘replicas’ field is unsatisfied).
Node component
● Node components run on every node, maintaining running pods and providing the Kubernetes
runtime environment

29. Master component
API Server
● Expose Kubernetes features via API.
● All data are stored in etcd
Etcd
● Distributed K/V store which stores cluster status.
DNS
● Every service receives a DNS name (except headless services) and pods can receive a DNS name
too.

30. Master component
Scheduler
● Schedule (place) container to node based on “Resource requirement”,
“Service requirement”, “Affinity/Anti-affinity”, “HW and SW policy etc)
Controller manager
● Set of controllers (Pod controller, Replication controller, Service controller, Endpoint controller)
It creates & manage objects
○ Node Controller: For checking the cloud provider to determine if a node has been deleted in the cloud after
it stops responding
○ Route Controller: For setting up routes in the underlying cloud infrastructure
○ Service Controller: For creating, updating and deleting cloud provider load balancers
○ Volume Controller: For creating, attaching, and mounting volumes, and interacting with the cloud provider
to orchestrate volumes
● Monitoring cluster status and control the cluster

31. Node component
Kubelet
● An agent that runs on each node in the cluster. It makes sure that containers are running in a pod.
Kube-proxy
● kube-proxy enables the Kubernetes service abstraction by maintaining network rules on the host
and performing connection forwarding
● Expose container traffic like load balancer
● Manage network communication betwe node , pods
Container runtime
● The container runtime is the software that is responsible for running containers
● Docker, rkt, runc and any OCI runtime spec implementation

32. Node component
cAdvisor
● Monitoring agent which gathers container status & performance and send it to apiserver@master
thru kubelet in node

33. Concept
Master component
Node component
Controller
Deployment
ReplicaSet
Pod Service
Expose
Create & manage
Object

34. Design Pattern
for distributed system

35. Ambassador
Create helper services that send network requests on behalf of a consumer service or application. An
ambassador service can be thought of as an out-of-process proxy that is co-located with the client.
Source : https://docs.microsoft.com/en-us/azure/architecture/patterns/ambassador
Deployment pattern : Ambassador services can be deployed as a sidecar to accompany the lifecycle
of a consuming application or service.
Alternatively, if an ambassador is shared by multiple separate processes on a common host, it can
be deployed as a daemon or service.

36. Ambassador for service discovery sample
Source : https://gotocon.com/dl/goto-berlin-
2015/slides/MatthiasLbken_PatternsInAContainerizedWorld.pdf

37. Sidecar
Deploy components of an application into a separate process or container to provide isolation and
encapsulation. This pattern can also enable applications to be composed of heterogeneous
components and technologies.
Source : https://docs.microsoft.com/en-us/azure/architecture/patterns/sidecar
Example : Logging, Proxy etc

38. Adapter
Standardise and normalize output
(ex logging, metric)
출력을 표준화 함으로써, 컨테이너가 업그레이드되어도 통일된 출력 포맷을 유지한다.

39. Single node pattern

40. Runtime

41. Runtime
rkt
● Container runtime engine (cf. docker)
● Derived from coreOS
● More simplified, secure than docker engine
● Rktnetes : Kubernets runtime wich can support rkt (Not matured yet)
Hyper container (https://hypercontainer.io/)
● is a hypervisor-based container, which allows you to launch Docker images
with standard hypervisors (KVM, Xen, etc.) 하이퍼 바이저를 이용하여 컨테이너를 격리
● HyperContainer = Hypervisor + Kernel + Docker Image
Hypernetes
● Hyper container based multi-tenant support Kubernetes

42. Runtime
Kubespray
● Support baremetal deployment
● https://kubernetes.io/docs/getting-started-guides/kubespray/

43. Test environment

44. Kubernetes local environment for testing
● MAC docker Edge edition includes Kubernetes
https://docs.docker.com/docker-for-mac/edge-release-notes/#edge-
releases-of-2018
● Minikube for Mac and windows
https://kubernetes.io/docs/getting-started-guides/minikube/