Kubernetes is an open-source container management platform. It has a master-node architecture with control plane components like the API server on the master and node components like kubelet and kube-proxy on nodes. Kubernetes uses pods as the basic building block, which can contain one or more containers. Services provide discovery and load balancing for pods. Deployments manage pods and replicasets and provide declarative updates. Key concepts include volumes for persistent storage, namespaces for tenant isolation, labels for object tagging, and selector matching.
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 ?
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
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
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
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
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
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/
Editor's Notes
https://kubernetes.io/docs/concepts/
프록시를 둬서 중간의 요청을 처리하는 패턴 (Circuit breaker, Service discovery, Client side LB)