Cont0519

Copyright © 2011 LOGTEL
Introduction to Docker
and Kubernetes (K8S)
Samuel Dratwa
Samuel.dratwa@gmail.com

About the Copyright
This documentation is protected by Copyright © 2017 LOGTEL,
32 Shacham St., Petah Tikva, 49170, Israel. World rights reserved.
The possession and use of this documentation is subjected to the
restrictions contained in this license.
No part of this documentation may be stored in a retrieval system,
transmitted or reproduced in any way, including but not limited to
photocopy, photograph, magnetic or other record, without the prior
agreement and written permission of LOGTEL.
Participants of this seminar are entitled to keep their copy of this
documentation for references purposes only.
2

Contents
 Introduction to Docker, Containers, and Micro-services
 Why do we need it and what’s the difference from VM
 Docker components
 Docker lifecycle
 Micro services
 Use Cases – Docker in the telecom world
 Hands-on
 Introduction to K8S
 Pods (vs. containers)
 Application lifecycle
 (auto) Scaling
 Scale up/down
 Load balancing

April 10th 2015 – Amazon start to push Docker (!)

MultiplicityofGoods
Multipilicityof
methodsfor
transporting/storing
DoIworryabout
howgoodsinteract
(e.g.coffeebeans
nexttospices)
CanItransportquickly
andsmoothly
(e.g.fromboattotrain
totruck)
Cargo Transport Pre-1960

? ? ? ? ? ? ?
? ? ? ? ? ? ?
? ? ? ? ? ? ?
? ? ? ? ? ? ?
? ? ? ? ? ? ?
? ? ? ? ? ? ?
A matrix from hell

MultiplicityofGoods
Multiplicityof
methodsfor
transporting/storing
DoIworryabout
howgoodsinteract
(e.g.coffeebeans
nexttospices)
CanItransport
quicklyandsmoothly
(e.g.fromboatto
traintotruck)
Solution: Intermodal Shipping Container
…in between, can be loaded and
unloaded, stacked, transported
efficiently over long distances,
and transferred from one mode
of transport to another
A standard container that is
loaded with virtually any
goods, and stays sealed until
it reaches final delivery.

Static website
Web frontend
User DB
Queue Analytics DB
Background workers
API endpoint
nginx 1.5 + modsecurity + openssl + bootstrap 2
postgresql + pgv8 + v8
hadoop + hive + thrift + OpenJDK
Ruby + Rails + sass + Unicorn
Redis + redis-sentinel
Python 3.0 + celery + pyredis + libcurl + ffmpeg + libopencv + nodejs +
phantomjs
Python 2.7 + Flask + pyredis + celery + psycopg + postgresql-client
Development VM
QA server
Public Cloud
Disaster recovery
Contributor’s laptop
Production Servers
The ChallengeMultiplicityofStacks
Multiplicityof
hardware
environments
Production Cluster
Customer Data Center
Doservicesandapps
interact
appropriately?
CanImigrate
smoothlyand
quickly?

The Matrix From Hell
Static website
Web frontend
Background workers
User DB
Analytics DB
Queue
Development
VM
QA Server
Single Prod
Server
Onsite
Cluster
Public Cloud
Contributor’s
laptop
Customer
Servers
? ? ? ? ? ? ?
? ? ? ? ? ? ?
? ? ? ? ? ? ?
? ? ? ? ? ? ?
? ? ? ? ? ? ?
? ? ? ? ? ? ?

Static website Web frontendUser DB Queue Analytics DB
Development
VM
QA server Public Cloud Contributor’s
laptop
Docker is a shipping container system for
code
MultiplicityofStacks
Multiplicityof
hardware
environments
Production
Cluster
Customer Data
Center
Doservicesandapps
interact
appropriately?
CanImigrate
smoothlyandquickly
…that can be manipulated using
standard operations and run
consistently on virtually any
hardware platform
An engine that enables any
payload to be encapsulated
as a lightweight, portable,
self-sufficient container…

Docker’s mission is to
build tools of mass innovation

Internet (hardware layer)
Servers Desktops Phones Cars Houses Drones
Network
equipment
Public
transit
TVs
Industrial
facilities
Scientific
instrument
s
Financial
system
Programmers
Internet (software layer)
App
App
App
App
App
App
App
App
App
App
App
App
App
App
App
App
App
App
App
App
App
App
App
App
App
App
App
App

Cloud Market
PublicHybridPrivate
IT Pros Devops DevelopersArchitects

Low MTBIAMSH
MTBIAMSH (Mean Time Between Idea And Making Stuff Happen)

Why Developers Care
• Build once…(finally) run anywhere*
• A clean, safe, hygienic and portable runtime environment for your app.
• No worries about missing dependencies, packages and other pain points during
subsequent deployments.
• Run each app in its own isolated container, so you can run various versions of
libraries and other dependencies for each app without worrying
• Automate testing, integration, packaging…anything you can script
• Reduce/eliminate concerns about compatibility on different platforms, either
your own or your customers.
• Cheap, zero-penalty containers to deploy services? A VM without the overhead
of a VM? Instant replay and reset of image snapshots? That’s the power of
Docker
* Almost ;-)

Why Devops Cares?
• Configure once…run anything
• Make the entire lifecycle more efficient, consistent, and repeatable
• Increase the quality of code produced by developers.
• Eliminate inconsistencies between development, test, production, and
customer environments
• Support segregation of duties
• Significantly improves the speed and reliability of continuous
deployment and continuous integration systems
• Because the containers are so lightweight, address significant
performance, costs, deployment, and portability issues normally
associated with VMs

Why it works—separation of concerns
• Dan the Developer
• Worries about what’s “inside”
the container
• His code
• His Libraries
• His Package Manager
• His Apps
• His Data
• All Linux servers look the same
• Oren the Ops Guy
• Worries about what’s “outside”
the container
• Logging
• Remote access
• Monitoring
• Network configuration
• All containers start, stop, copy,
attach, migrate, etc. the same
way

What is OSGi?
• “The dynamic module system for Java”
• Mature 10-year old technology
• Governed by OSGi Alliance: http://www.osgi.org
• Used inside just about all Java-based middleware
• IBM WebSphere, Oracle WebLogic, Red Hat JBoss, Sun GlassFish, Paremus Service Fabric, Eclipse Platform, Apache Geronimo,
(non-exhaustive list)
http://www.osgi.org/wiki/uploads/News/2008_09_16_worldwide_market.pdf
22
JARJAR
Package
Class
Class
Class
Package
Class
Class
Class
Package
Class
Class
Class
Package
Class
Class
Class
Explicit exports
Explicit dependencies

Containers before Docker……

Containers after Docker ……

Docker Containers as a Service Platform
Docker
Toolbox
Docker
Trusted Registry
Docker Universal
Control Plane
Build Ship Run
• “docker push”
with image signing
• Search/browse repos
• Teams-based RBAC
• View signed images
• Deleting tags
• Authentication
• Deploy and scale-out app
• Monitor stats
• Secrets management

App
A
Containers vs. VMs
Hypervisor (Type 2)
Host OS
Server
Guest
OS
Bins/
Libs
App
A’
Guest
OS
Bins/
Libs
App
B
Guest
OS
Bins/
Libs
AppA’
Docker
Host OS
Server
Bins/Libs
AppA
Bins/Libs
AppB
AppB’
AppB’
AppB’
VM
Container
Containers are isolated,
but share OS and, where
appropriate, bins/libraries
Guest
OS
Guest
OS
…result is significantly faster deployment,
much less overhead, easier migration,
faster restart

Why are Docker containers lightweight?
Bins/
Libs
App
A
Original App
(No OS to take
up space, resources,
or require restart)
AppΔ
Bins/
App
A
Bins/
Libs
App
A’
Guest
OS
Bins/
Libs
Modified App
Copy on write
capabilities allow
us to only save the diffs
Between container A
and container
A’
VMs
Every app, every copy of an
app, and every slight modification
of the app requires a new virtual server
App
A
Guest
OS
Bins/
Libs
Copy of
App
No OS. Can
Share bins/libs
App
A
Guest
OS
Guest
OS
VMs Containers

Docker engine Architecture……
• Docker Engine
– CLI
– Docker Daemon
– Docker Registry
• Docker Hub
– Cloud service
• Share Applications
• Automate workflows
• Assemble apps from components
• Docker images
• Docker containers

Isolation using Linux kernel features
namespaces
 pid
 mnt
 net
 uts
 ipc
 user
cgroups
 memory
 cpu
 blkio
 devices

Linux Cgroups ……
• Kernel Feature
• Groups of processes
• Control resource allocations
– CPU
– Memory
– Disk
– I/O
• May be nested

• Kernel Feature
• Restrict your view of the system
– Mounts (CLONE_NEWNS)
– UTS (CLONE_NEWUTS)
• uname() output
– IPC (CLONE_NEWIPC)
– PID (CLONE_NEWPID)
– Networks (CLONE_NEWNET)
– User (CLONE_NEWUSER)
• Not supported in Docker yet
• Has privileged/unprivileged modes today
• May be nested
Linux Kernel Namespaces ……

What are the basics of the Docker system?
Source
Code
Repository
Dockerfile
For
A
Docker Engine
Docker
Container
Image
Registry
Build
Docker
Host 2 OS (Linux)
ContainerA
ContainerB
ContainerC
ContainerA
Push
Search
Pull
Run
Host 1 OS (Linux)

Changes and Updates
Docker Engine
Docker
Container
Image
Registry
Docker Engine
Push
Update
Bins/
Libs
App
A
AppΔ
Bins/
Base
Container
Image
Host is now running A’’
Container
Mod A’’
AppΔ
Bins/
Bins/
Libs
App
A
Bins/
Bins/
Libs
App
A’’
Host running A wants to upgrade to A’’.
Requests update. Gets only diffs
Container
Mod A’

Docker for developers / Dockerfile
https://registry.hub.docker.com/_/java/

• Like a Makefile (shell script with keywords)
• Extends from a Base Image
• Results in a new Docker Image
• Imperative, not Declarative
• A Docker file lists the steps needed to build an images
• docker build is used to run a Docker file
• Can define default command for docker run, ports to expose,
etc
Dockerfile ……

docker-compose: running multiple
containers
 Run your stack with one command: docker-compose up
 Describe your stack with one file: docker-compose.yml
web:
build: .
command: python app.py
ports:
- "5000:5000"
volumes:
- .:/code
links:
- redis:redis
redis:
image: redis

docker-machine
docker-machine create -d azure
—azure-subscription-id="c4f51be3-784c-xxx-7c50ad9e1b7c"
--azure-subscription-cert="/Users/pat/.ssh/docker-azure-
cert.pem"
--azure-location="East US"
--azure-size=Small
--azure-username="pat"
pat-docker-machine-n

Docker Hub
Dev & QA
ColleaguesDevelopers
QA
Build & Ship

Docker Trusted Registry … now with Docker Content Trust
Docker
Toolbox
Build Ship
Docker
Trusted Registry

Swarm
Scheduler plugins
Engine
Volumes plugins
Network plugins
Service discovery
plugins
Engine
Volumes plugins
Network plugins
Service discovery
plugins
mesos
flockerglusterfs
weavecalico
consuletcdzookeeper
midokuraciscoazurenuagenetworks
Docker Plugins
Batteries included but removable

Docker
CLI
Docker
CLI
Docker
CLI
Docker Engine

Docker Container Lifecycle
• The Life of a Container
– Conception
• BUILD an Image from a Dockerfile
– Birth
• RUN (create+start) a container
– Reproduction
• COMMIT (persist) a container to a new image
• RUN a new container from an image
– Sleep
• KILL/stop a running container
– Wake
• START a stopped container
– Death
• RM (delete) a stopped container
• Extinction
– RMI a container image (delete image)

MICRO SERVICES

Monolithic App
(Various Components linked together)

MicroServices
separate single purpose services

Monolithic Architecture
Load Balancer
Monolithic App
Account
Component
Catalog
Component
Recommendation
Component
Customer Service
Component
Database

MicroServices Architecture
Load Balancer
Account
Service
Catalog
Service
Recommendation
Service
Customer Service
Service
Catalog
DB
API Gateway
Customer
DB

Concept -> Service Dependency Graph
Your App/Service
Service X
Service Y
Service Z
Service L
Service M

Why ?
 Faster and simpler deployments and rollbacks
 Independent Speed of Delivery (by different teams)
 Right framework/tool/language for each domain
 Recommendation component using Python?, Catalog
Service in Java ..
 Greater Resiliency
 Fault Isolation
 Better Availability
 If architected right 

Want to learn more?
• www.docker.io:
• Documentation
• Getting started: interactive tutorial, installation instructions, getting
started guide,
• About: Introductory whitepaper: http://www.docker.io/the-whole-
story/
• Github: dotcloud/docker
• IRC: freenode/#docker
• Google groups: groups.google.com/forum/#!forum/docker-
user
• Twitter: follow @docker
• Meetups: Scheduled for Boston, San Francisco, Austin, London, Paris,
Boulder…and Nairobi. https://www.docker.io/meetups/

Does it really fit all ?
•YES

Introduction to
Kubernetes

 Containers & Microservice Recap
 What's missing in Dockers containers ?
 HL Kubernetes as orchestration solution
 Pods (vs. containers)
 Clusters
 Application lifecycle
 (auto) Scaling
 Scale up/down
 Load balancing
 Secrets
 Networking
 hands-on
Agenda
100

App
A
Containers vs. VMs
Hypervisor (Type 2)
Host OS
Server
Gue
st
OS
Bin
s/
Libs
App
A’
Gue
st
OS
Bin
s/
Libs
App
B
Gue
st
OS
Bin
s/
Libs
AppA’
Docker
Host OS
Server
Bins/Li
bs
AppA
Bins/Libs
AppB
AppB’
AppB’
AppB’
VM
Container
Containers are isolated,
but share OS and, where
appropriate, bins/libraries
Gue
st
OS
Gue
st
OS
…result is significantly faster
deployment, much less
overhead, easier migration,
faster restart

Why are Docker containers lightweight?
Bin
s/
Libs
App
A
Original App
(No OS to take
up space, resources,
or require restart)
AppΔ
Bins/
App
A
Bin
s/
Libs
App
A’
Gue
st
OS
Bin
s/
Libs
Modified App
Copy on write
capabilities allow
us to only save
the diffs
Between
container A and
container
A’
VMs
Every app, every copy of an
app, and every slight modification
of the app requires a new virtual server
App
A
Gue
st
OS
Bin
s/
Libs
Copy of
App
No OS. Can
Share bins/libs
App
A
Gue
st
OS
Gue
st
OS
VMs Containers

Docker is a “Shipping Container”
104

What’s missing
105

Options for Container Cloud Orchestration on Power
106
Docker Swarm/Datacenter KubernetesMesos
Docker Inc GoogleMesosphere
• Strengths
• Built-in to Docker 1.12 Engine
• Easy to use for Small Clouds
• Weaknesses
• Full Docker DC not on Power Yet
• Strengths
• Good for Batch and Analytics
• Lots of Apps in Catalog
• Weaknesses
• Less usage in Web Applications
• Requires Marathon Framework for
Web Apps
• Strengths
• Lots of Industry usage and
experience for Web Apps
• Synergy with Other parts of Client
Business for X86 Container Mgmt
• Weaknesses
• Significant Integration of many
components for Production Cloud

Kubernetes Layout
107

Swarm
108

Kubernetes
 Pronounced /koo-ber-nay'-tace/
 A Greek term for “ship master”.
 Developed at/by Google.
 The third iteration of container management.
 Daddy was Omega.
 Grandaddy was Borg.
 Kubernetes is not a PaaS, just orchestration
(Docker is the PaaS)
 Kubernetes built to “planet scale”.
 Google wants us to stop writing Kubernetes and use k8s instead
 100% Open source, written in Go
109

 Kubernetes is an open-source system for automating
deployment, scaling, and management of containerized
applications.
 Planet Scale
 Designed on the same principles that allows Google to run billions
of containers a week, Kubernetes can scale without increasing your
ops team.
 Never Outgrow
 Whether testing locally or running a global enterprise, Kubernetes
flexibility grows with you to deliver your applications consistently
and easily no matter how complex your need is
 Run Anywhere
 on-premise, hybrid, or public cloud infrastructure, letting you
effortlessly move workloads to where it matters to you. 110

Kubernetes Features
111

Kubernetes Layout
112

Master
 API Server—nearly all the components on the master and nodes accomplish
their respective tasks by making API calls. These are handled by the API Server
running on the master.
 Etcd—Etcd is a service whose job is to keep and replicate the current
configuration and run state of the cluster. It is implemented as a lightweight
distributed key-value store and was developed inside the CoreOS project.
 Scheduler and Controller Manager—These processes schedule containers
(actually pods) onto target nodes. They also make sure that the correct numbers
of these pods are running at all times.
113

Node
 Kubelet - A special background process (daemon) that runs on each node
whose job is to respond to commands from the master to create, destroy, and
monitor the containers on that host.
 Proxy - This is a simple network proxy that’s used to separate the IP address of
a target container from the name of the service it provides.
 cAdvisor (optional) - Container Advisor is a special daemon that collects,
aggregates, processes, and exports information about running containers. This
information includes information about resource isolation, historical usage, and
key network statistics.
114

Pods
 A pod is a collection of containers and volumes that are
bundled and scheduled together because they share a
common resource, usually a filesystem or IP address.
115

Why not just run multiple programs
in a single (Docker) container?
 Transparency. Making the containers within the pod
visible to the infrastructure enables the infrastructure to
provide services to those containers, such as process
management and resource monitoring. This facilitates a
number of conveniences for users.
 Decoupling software dependencies. The individual
containers may be versioned, rebuilt and redeployed
independently. Kubernetes may even support live updates
of individual containers someday.
 Ease of use. Users don’t need to run their own process
managers, worry about signal and exit-code propagation,
etc.
 Efficiency. Because the infrastructure takes on more
responsibility, containers can be lighter weight.
116

Kubernetes Architecture
118

Descriptors
apiVersion: v1
kind: Pod
metadata:
name: ""
labels:
name: ""
namespace: ""
annotations: []
generateName: ""
spec:
? "// See 'The spec schema' for
details."
: ~
{
"kind": "Pod",
"apiVersion": "v1",
"metadata": {
"name": "",
"labels": {
"name": ""
},
"generateName": "",
"namespace": "",
"annotations": []
},
"spec": {
// See 'The spec schema' for details.
}
}
119
YAML is the clear winner. Especially in the context of Shannon’s Information Theory.
The same density of information can be transmitted in less lines with YAML.

Pod Spec
spec:
containers:
-
args:
- ""
command:
- ""
env:
-
name: ""
value: ""
image: ""
imagePullPolicy: ""
name: ""
ports:
-
containerPort: 0
name: ""
protocol: ""
resources:
cpu: ""
memory: ""
restartPolicy: ""
volumes:
-
emptyDir:
medium: ""
name: ""
secret:
secretName: ""
120

Pod spec example
apiVersion: v1
kind: Pod
metadata:
name: redis-django
labels:
app: web
spec:
containers:
- name: key-value-store
image: redis
ports:
- containerPort: 6379
- name: frontend
image: django
ports:
- containerPort: 8000
121

The Pod Lifecycle in a Cluster
Let’s say you want to fire up a pod. With kubectl you would:
1. Make a Pod request to the API server using a local pod
definition file.
2. The API server saves the info for the pod in ETCD.
3. The scheduler finds the unscheduled pod and schedules it
to a node.
4. Kubelet sees the pod scheduled and fires up Docker.
5. Docker runs the container.
 The entire lifecycle state of the pod is stored in ETCD.
Most of the things in Kubernetes are built on top of
Pods
122

kubectl create - Create a resource from a file
// Create a service using the definition in example-service.yaml.
$ kubectl create -f example-service.yaml
// Create a replication controller using the definition in example-controller.yaml.
$ kubectl create -f example-controller.yaml
// Create the objects that are defined in any .yaml, .yml, or .json file within the <directory>
directory.
$ kubectl create -f <directory>
123

Labels
 A label is a key-value pair that is assigned to objects in k8s.
 Pods, services, etc
 Labels can be used to organize and to select subsets of objects
 Labels can be attached to objects at creation time and subsequently added and modified at
any time
124

Label Selectors
 Two kinds of label selectors
 equality-based (IS/IS NOT)
 tier = frontend
 tier != frontend
 tier != frontend, game = super-shooter-2
 set-based (IN/NOT IN)
 environment in (production, qa)
 tier notin (frontend, backend)
125

Services
 A Kubernetes Service is an abstraction which defines a logical set of Pods and a
policy by which to access them
 The set of pods gathered by a Service is determined by a label selector
 A service is a long-lived, well-known endpoint that points to a set of pods in a
cluster. It consists of three things:
 external IP address (known as a portal, or sometimes a portal IP)
 port
 label selector.
126

Service Example
127

Basic Cluster
128
 When you launch a cluster, you get some built in services.
 Each one of these has their own endpoints and / or UIs.
 They run on the master directly though you could schedule
them across the cluster or other masters.
 To find the endpoints type: kubectl cluster-info

Heapster
 Heapster is a cluster-wide aggregator of monitoring and event data. It supports Kubernetes
natively and works on all Kubernetes setups, including our Deis Workflow setup. Heapster runs
as a pod in the cluster, similar to how any other Kubernetes application would run.
 The Heapster pod discovers all nodes in the cluster and queries usage information from each
node's Kubelet—the on-machine Kubernetes agent. The Kubelet itself fetches the data from
cAdvisor.
 Heapster groups the information by pod along with the relevant labels. This data is then pushed
to a configurable backend for storage and visualization.
129

InfluxDB & Grafana
 InfluxDB is an open source database written in Go specifically to handle time series data with
high availability and high performance requirements. It exposes an easy to use API to write and
fetch time series data. Heapster is set up to use InfluxDB as the storage backend by default on
most Kubernetes clusters.
 Grafana is the data visualization component in our monitoring setup. It is available out of the box
in a Kubernetes cluster. The default dashboard displays resource usage of the cluster and the
pods inside of it. This dashboard can easily be customized and expanded.
 InfluxDB and Grafana already run in pods exposing themselves as Kubernetes services, making it
easy for Heapster to discover them. With all of this already in place, there is minimal setup
required to get things up and running.
130

The base – container & spec
 The only required field in spec is containers.
it requires (mandatory only) two entries
 name
 image
 Part of the spec is for all containers in a pod:
 restartPolicy
 Volumes
 The spec is very extensible by design
 Specs don’t do anything by themselves;
for that you need a pod .
133

Pods
 Pods are just collections of containers that share a few things:
 Access to volumes
 Networking
 Are co-located
 Restart together
 Usualy scale togther
 Etc.
 Pods can be run by themselves but have no guarantee to restart or stay running
or scale or do anything useful
134

Ingress Service
 Services point to a Pod or to an external source.
 With Pods a virtual endpoint is created then routed to using the kube-proxy
 For non-pod services a virtual IP in the cluster is used to route externally .
 Ingress Service = AWS API Gateway
 An Ingress Controller sits at the boundary of the cluster and routes requests to Services
 One Ingress Controller can handle multiple domains
 Each route can point to a different Service
 Relies on the creation of an Ingress Controller in the cluster (another service that is not
enabled by default).
135

Daemon sets
 Daemons is an object that ensures that a copy of each Pod runs on each node.
This is commonly used to make sure side-car containers are running across the
cluster.
 If new nodes come up they’ll get a copy of the daemon set and will come up.
 Daemon sets don’t have scaling rules.
136

Pet Sets – Statefull pods
 Introduced 1.3, Pet Sets allow you to create complex microservices across the
cluster.
 They have the ability to set dependency on other containers.
 They require:
 A stable hostname, available in DNS
 An ordinal index
 Stable storage: linked to the ordinal & hostname
 It is used for statefull pods
137

Replcia Set
 A Replication Controller (deprecated) was the best way to run Pods.
 You set a number of pods to run and the Replication Controller made sure that the number
was running across the cluster.
 Rolling updates could be performed by starting a new Replication Controller and scaling up.
 A Replica Set differs from the Replication Controller because it can be updated.
 If you update the Replica Set template you can fire and update and automatically roll
changes
 Rollbacks are also built in.
 Replica Set are not designed to be used directly.
For that you need Deployments.
138

replication controller ReplicaSet
apiVersion: v1
kind: ReplicationController
metadata:
name: rcweb
labels:
name: rcweb
spec:
replicas: 4
selector:
app: rcweb
phase: production
template:
metadata:
labels:
app: rcweb
role: frontend
phase: production
name: rcwebpod
spec:
containers:
- name: staticweb 139

Deployments, The king of the hill
 A Deployment controls the running state of Pods and Replica Sets.
 In k8s it is the primary object you should be manipulating.
 Deployments have:
 History
 Rolling updates
 Pausing updates
 Roll-backs
140

A Virtual Cluster in Your Cluster
 A namespace as an isolated section of a cluster.
 It’s a virtual cluster in your cluster.
 Each cluster can have multiple namespaces.
 The root services have their own.
 Namespaces are in network isolation from each other and
can (are normally) used to house different environments on
the same cluster.
 resources (pods, services, replication controllers, etc.)
 policies (who can or cannot perform actions in their community)
 constraints (quota, etc.)
 Kubernetes starts with two initial namespaces:
 default - The default namespace for objects with no other
namespace.
 kube-system - The namespace for objects created by the
Kubernetes system
141

ResourceQuota (for namespace)
apiVersion: v1
kind: ResourceQuota
metadata:
name: quota
spec:
hard:
cpu: "20"
memory: 1Gi
pods: "10"
replicationcontrollers: "20"
resourcequotas: "1"
services: "5"
142

ConfigMap
 ConfigMap is a resource available in kubernetes for managing
application configuration.
 The goal is to decouple the app configuration from the image content
in order to keep the container portable and k8s agnostic.
 ConfigMap are key value pairs of configuration data.
143

Kubernetes on public clouds
 Availability on the major cloud providers:
 There are a variety of CLI tools available
 automate deployment of Kubernetes
 enable production-quality Kubernetes clusters on AWS & other
clouds to be deployed quickly & easily
 some include node auto-scaling
 Also third-party companies providing Kubernetes-as-a-
Service on multiple public clouds
Native support Node auto-scaling
Google ✔ ✔
Azure ✔ ✗
AWS ✗ ✗

Windows Server Container Architecture
Source: Microsoft

Windows Server Node in Kubernetes
kubelet kube-proxy
Kubernetes
Master
Components
(unchanged)
Kubectl
(unchanged)
Windows Server 2016 Node
docker
Infra
container POD
container
Infra
container POD
container

Standalone
 Minikube
 https://github.com/kubernetes/minikube
 Runs a Kubernetes node on top of your favorite (probably Virtualbox) VM.
 Lots of involvement from the K8s community.
 Kube-solo
 https://github.com/TheNewNormal/kube-solo-osx
 Uses the Corectl app to run a Kube VM
 Also has a multi-node version.
147

Google demo
 gcloud container clusters create example-cluster
 kubectl run hello-node --image=gcr.io/google-samples/node-hello:1.0 --
port=8080
 kubectl expose deployment hello-node --type="LoadBalancer"
 kubectl cluster-info
 kubectl config view
 kubectl get pods
 kubectl get service
 gcloud container clusters describe example-cluster
150

Cont0519

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a Cont0519

Similar a Cont0519 (20)

Más de Samuel Dratwa

Más de Samuel Dratwa (13)

Último

Último (20)

Cont0519