Kubernetes basics and hands on exercise

© 2017 Cloud Technology Experts INC. All rights reserved.
KUBERNETES BASIC OBJECTS & DEMO
Damian Igbe
damianigbe@cloudtechnologyexperts.com

Cloud Technology Experts
Agenda
● Quick Kubernetes Concepts
● Kubernetes Architecture
● Kubernetes Fundamental Objects
● Demo
● Conclusion,Q&A & Meetup business

Scheduling: Decide where my containers should run
Lifecycle and health: Keep my containers running despite failures
Scaling: Make sets of containers bigger or smaller
Naming and discovery: Find where my containers are now
Load balancing: Distribute traffic across a set of containers
Storage volumes: Provide data to containers
Logging and monitoring: Track what’s happening with my containers
Debugging and introspection: Enter or attach to containers
Identity and authorization: Control who can do things to my containers
Container Orchestration

Want to automate orchestration for velocity & scale
Diverse workloads and use cases demand still more functionality
● Rolling updates and blue/green deployments
● Application secret and configuration distribution
● Continuous integration and deployment
● Batch processing
● Scheduled execution
...
A composable, extensible Platform is needed

Greek for “Helmsman”; also the root of the
words “governor” and “cybernetic”
• Infrastructure for containers
• Schedules, runs, and manages containers
on virtual and physical machines
• Platform for automating deployment,
scaling, and operations
Kubernetes

• Inspired and informed by Google’s
experiences and internal systems
• 100% Open source, written in Go
• One of the top 4 open source software
projects with highest velocity and
contribution
Kubernetes

Drive current state → desired state
Observed state is truth
Act independently
• choreography rather than
orchestration
Recurring pattern in the system
Kubernetes Control Loop

KUBERNETES ARCHITECTURE

Cluster Components
Master/Controller
● API Server (kube-apiserver)
● Scheduler (kube-scheduler)
● Controller manager (kube-controller-manager)
● etcd (stores cluster state)
Node
● Kubelet (“node agent”)
● Kube-proxy
● Container Runtime (Docker,rkt)

Kubernetes Architecture

Architecture: Master Node
Master Node (“Control Plane”)
kube-apiserver
- Point of interaction with the cluster
- Exposes http endpoint
kube-controller-manager
- Responsible for most of the important stuff
- Interacts with the api server to retrieve cluster state
- Responsible for configuring networking
- Allocates node CIDRs
- Ensures correct number of pods are running
- Reacts to Nodes being added / deleted
- Manages Service Accounts and security tokens
kube-scheduler
- Schedules newly created pods to a Node

Architecture: Master Node
Master Node (“Control Plane”)
Etcd
- Stores the state of the cluster
- Doesn’t necessarily have to be co-located with other components
- Must be backed up in a production scenario

Architecture: Worker Node
kubelet
● Agent for running Pods
● Mounts volumes for Pods where required
● Reports the status of Pods back to rest of system
kube-proxy
● Enforces network rules on each Node (uses iptables)
● Responsible for forwarding packets to correct destination

KUBERNETES FUNDAMENTAL OBJECTS

Kubernetes Fundamental Objects
● Pods
● Label/Selectors
● Replica Sets/Replication Controllers
● Deployments
● Services
● *ConfigMaps/Secrets*

Pod
● A pod is one or more containers
● Ensures co-location / shared fate
● Pods are scheduled, then do not move between nodes
● Containers share resources within the pod:
○ Volumes
○ Network / IP
○ Namespace
○ CPU / Memory allocations

A pod manifest file in Yaml
apiVersion: v1
kind: Pod
metadata:
name: redis-nginx
labels:
app: web
spec:
containers:
- name: redis
image: redis
ports:
- containerPort: 6379
- name: nginx
image: nginx
ports:

Label/Selectors
● Labels are arbitrary metadata
● Attachable to nearly all API objects
e.g.: Pods, ReplicationControllers, Services...
● Simple key=value pairs
● Can be queried with selectors
● The only grouping mechanism
○ pods under a ReplicationController
○ pods in a Service
○ capabilities of a node (constraints

Example of Labels
● release=stable, release=beta, Release=alpha
● environment=dev, environment=qa,
environment=prod
● tier=frontend, tier=backend,
tier=middleware
● partition=customer1, partition=customer2

Pod manifest showing labels
apiVersion: v1
kind: Pod
metadata:
name: redis-nginx
labels:
app: web
env: test
spec:
containers:
- name: redis
image: redis
ports:
- name: nginx
image: nginx
ports:

Labels are queryable metadata - selectors can do the queries:
● Equality based:
○ environment = production
○ tier != frontend
○ combinations: tier != frontend, version = 1.0.0
● Set based:
○ environment in (production, pre-production)
○ tier notin (frontend, backend)
○ partition or !partition
Label Selectors

● Define the number of replicas of a pod
● Will scheduled across all applicable nodes
● Can change replica value to scale up/down
● Which pods are scaled depends on RC selector
● Labels and selectors are used for grouping
● Can do quite complex things with RCs and labels
Replication Controllers

A RC manifest file in Yaml
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

Replica Set is the next-generation Replication Controller. The only
difference between a Replica Set and a Replication Controller right
now is the selector support. Replica Set supports the new set-based
selector which allow filtering keys according to a set of values:
● In
● Notin
● exists (only the key identifier)
For example:
● environment in (production, qa)
● tier notin (frontend, backend)
● partition
● !partition
Replica Set

A RS manifest file in Yaml
apiVersion: extensions/v1beta1
kind: ReplicaSet
metadata:
name: nginx
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
name: nginx
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx
ports:
- containerPort: 80

A Deployment is responsible for creating and updating instances of
your application
● Create a Deployment to bring up Pods and a
replica set. Deployment->ReplicatSet->Pods
● Check the status of a Deployment to see if it
succeeds or not.
● Later, update that Deployment to recreate the
Pods (for example, to use a new image).
● Rollback to an earlier Deployment revision if
the current Deployment isn’t stable.
Deployments

A Deployment manifest file in Yaml
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: deploy1
spec:
selector:
matchLabels:
app: nginx
replicas: 4
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: containercm1
image: nginx
ports:
- containerPort: 80
env:
- name: weatherseasons
valueFrom:
configMapKeyRef:
name: weathervariable
key: weather

defines a logical set of Pods and a policy by which to access them
● As Pods are ephemeral, we can't depend on Pod IPs
● Services find pods that match certain selection criteria
● Services can load balance between multiple Pods
● Services can have a single IP that doesn’t change
● Services are used for service Discovery
Services

● A group of pods that act as one == Service
○ group == selector
● Defines access policy
○ ClusterIP, LoadBalanced, NodePort
● Gets a stable virtual IP and Port
○ Called the service portal
○ Also a DNS name
○ On prem additional loadbalancer is needed
● VIP is captured by kube-proxy
○ Watches the service consistency
○ Updates when backend changes
Services

apiVersion: v1
kind: Service
metadata:
name: railsapp
spec:
type: NodePort
selector:
app: nginx
ports:
- name: http
nodePort: 30002
port: 80
protocol: TCP
Services Manifest

DEPLOYMENTS AND SERVICES:
Demo with kubernetes Guestbook app

Q & A

Meetup Goals/Vision
● Focus of the meetup will be on CNCF Hosted Applications
(Kubernetes, Prometheus, Fluentd, gRPC,Linkerd, Opentracing,
rkt, containerd,CNI, CoreDNS)
● Also around Cloud Native Microservices apps, Devops, Docker
containers
● This is inline with CNCF goals of community education and
dissemination of information
● Hope to conduct Free Kubernetes Training but will discuss
with CNCF for sponsorship opportunities
● 2 speeches per meetup or 1 depending on the presentation?
● Online meetup streaming?

Announcements
● Kubecon and CloudNative Conference. December 6-8th.
https://www.cncf.io/event/cloudnativecon-north-america-2017/
● Ambassadors
https://www.cncf.io/people/ambassadors/
● Beta Certifications
https://www.cncf.io/blog/2017/06/15/sign-kubernetes-beta-certification-exam/
● Free Kubernetes Training
https://www.edx.org/course/introduction-kubernetes-linuxfoundationx-lfs158x
https://www.udacity.com/course/scalable-microservices-with-kubernetes--ud615
● Follow on twitter/linkedin

Damian Igbe, PhD
● PhD in Computer science
● Linux Systems Administration
● Technical Trainer by trade
● Kubernetes Certified Administrator
● Kubernetes Doc team contributor
● CTO of Cloud Technology Experts

Kubernetes basics and hands on exercise

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie Kubernetes basics and hands on exercise

Ähnlich wie Kubernetes basics and hands on exercise (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Kubernetes basics and hands on exercise