SlideShare ist ein Scribd-Unternehmen logo
1 von 82
Downloaden Sie, um offline zu lesen
Copyright © 2011 LOGTEL
Introduction to
Kubernetes
Samuel Dratwa
Samuel.dratwa@gmail.com
Copyright © 2011 LOGTEL
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
Copyright © 2011 LOGTEL 3
Copyright © 2011 LOGTEL 4
Copyright © 2011 LOGTEL
 Containers & Kubernetes Recap
 Containers life cycles
 Pods and Descriptors
 Label Selectors
 Services / ingress Services
 Replica Set / Daemon Sets
 Deployments
 Kubernetes concepts
 Resources (and ResourceQuota)
 Application lifecycle
 Networking
 Orchestration
 Hands-On
Agenda – Day 1
5
Copyright © 2011 LOGTEL
 Recap of 1st day and question answering
 Introduction to Rancher
 Creating a Cluster
 Deploying an Application
 Kubernetes concepts
 Rolling updates and rollbacks
 Config Map & Secrets
 Self-healing and auto-scaling applications
 Kubernetes Hands-On
 Updating a Pod
 Using Config Map
 Auto-Scaling
 Helm – concept and architecture
 Final thoughts and conclusions
Agenda – Day 2
6
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
Image layers
Copyright © 2011 LOGTEL
Docker is a “Shipping Container”
10
Copyright © 2011 LOGTEL
What’s missing
11
Copyright © 2011 LOGTEL
Options for Container Cloud Orchestration on Power
12
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
Copyright © 2011 LOGTEL
Source: Shippable.com http://blog.shippable.com/why-the-adoption-of-kubernetes-will-explode-in-2018
kubernetes won the container orchestration war...
Copyright © 2011 LOGTEL
Kubernetes Layout
14
Copyright © 2011 LOGTEL
Swarm
15
Copyright © 2011 LOGTEL
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
16
Copyright © 2011 LOGTEL
 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.
17
Copyright © 2011 LOGTEL
Kubernetes Features
18
Scheduling Affinity/anti-
affinity
Health
monitoring
Failover
Scaling Networking Service
discovery
Coordinated
app upgrades
Copyright © 2011 LOGTEL
Kubernetes Layout
20
Copyright © 2011 LOGTEL
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.
21
Copyright © 2011 LOGTEL
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.
22
Copyright © 2011 LOGTEL
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.
23
Copyright © 2011 LOGTEL
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.
24
Copyright © 2011 LOGTEL 25
Copyright © 2011 LOGTEL
Kubernetes Architecture
26
Copyright © 2011 LOGTEL
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.
}
}
27
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.
Copyright © 2011 LOGTEL
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: ""
28
Copyright © 2011 LOGTEL
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
29
Copyright © 2011 LOGTEL
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
30
Copyright © 2011 LOGTEL
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>
31
Copyright © 2011 LOGTEL
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
32
Copyright © 2011 LOGTEL
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)
33
Copyright © 2011 LOGTEL
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.
34
Copyright © 2011 LOGTEL
Service Example
35
Copyright © 2011 LOGTEL
Basic Cluster
36
 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
Copyright © 2011 LOGTEL 37
Copyright © 2011 LOGTEL 38
Copyright © 2011 LOGTEL
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 .
39
Copyright © 2011 LOGTEL
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
40
Copyright © 2011 LOGTEL
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).
41
Copyright © 2011 LOGTEL
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.
42
Copyright © 2011 LOGTEL
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
43
Copyright © 2011 LOGTEL
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.
44
Copyright © 2011 LOGTEL
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 45
Copyright © 2011 LOGTEL
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
46
Copyright © 2011 LOGTEL
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
47
Copyright © 2011 LOGTEL
ResourceQuota (for namespace)
apiVersion: v1
kind: ResourceQuota
metadata:
name: quota
spec:
hard:
cpu: "20"
memory: 1Gi
pods: "10"
replicationcontrollers: "20"
resourcequotas: "1"
services: "5"
48
Copyright © 2011 LOGTEL
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.
49
Copyright © 2011 LOGTEL
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
Copyright © 2011 LOGTEL
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.
53
Copyright © 2011 LOGTEL
The Pod is the core Kubernetes Component
spec:
template:
spec:
containers:
- name: drupal
image: cr.io/repo/mydrupal:v1
54
 The Pod is the core component of
Kubernetes
 Collection of 1 or more containers
 Each pod should focus on one container,
however sidecar containers can be added
to enhance features of the core
container
Copyright © 2011 LOGTEL
Pods can Handle Scaling and Deployments
 Kubernetes Handles:
 System Performance
 Scale up/down the number of pods based
on CPU load or other criteria
 System Monitoring
 Probes to check the health of each pod
 Any unhealthy ones get killed and new
pod is put into service
 Deployments
 Deploy new versions of the container
 Control traffic to the new pods to test the
new version
 Blue/Green deployments
 Rolling deployments
55
Copyright © 2011 LOGTEL
Kubernetes Services tie together the pods
apiVersion: v1
kind: Service
metadata:
name: drupal
spec:
selector:
app: drupal
ports:
- name: http-port
port: 80
type: LoadBalancer
56
Kubernetes Services are used to control
communications with the pods
 Load balance the requests
 Don’t send traffic to the unhealthy
ones
 Only talk to the correct version
Copyright © 2011 LOGTEL
Services Structure allow multiple Components
 Service architecture allow Kubernetes to
handle things instead of us:
 Service discovery
 Load balancing
 Scaling
 Service discovery allows each pod just
needs to call the name of the service it
wants to talk to
 Services have multiple options
 Session based load balancing
 Single port based services
 External Services
 The Service architecture of Kubernetes can
be scaled up to handle as many services as
you would like for your system
57
Copyright © 2011 LOGTEL
Where Is the Infrastructure?
 You don’t have to worry about the
infrastructure
 The entire design of pods and services
is described with YAML files
 Nothing in deployments, pod
management, service discovery,
monitoring, etc required any
knowledge about how many servers,
IP addresses, load balancers, or
anything else with the infrastructure
 Behind the scenes, Kubernetes is
aware of all of the servers available,
load balancers, application gateways
and will configure them automatically
according to what is in the YAML files
58
Copyright © 2011 LOGTEL
DRUPAL EXAMPLES
59
Copyright © 2011 LOGTEL
Deployment
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: drupal
spec:
template:
spec:
containers:
- name: drupal
image:
cr.io/repo/mydrupal:v1
ports:
containerPort: 80
 Deployment—connects a Pod
with replication control and
rollout management
 Synchronizes app
configuration across instances
 Production deploys are as
simple as updating an image
tag
 No more bouncing apache on
a dozen servers
 Contains a Pod spec
Copyright © 2011 LOGTEL
Autoscaling
apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
spec:
scaleTargetRef:
apiVersion: extensions/v1beta1
kind: Deployment
name: drupal
minReplicas: 2
maxReplicas: 10
targetCPUUtilizationPercentage: 50
 Realizes the promise of the cloud: scales your app in response to
load, in real time
 Kubernetes tracks resource utilization
 Responds by adding or removing pods to the Replica Set
 Kubernetes core supports CPU utilization
 Other resources are available via add-ons
 Pod autoscaling != node autoscaling
 Node autoscaling for GCE and AWS as add-ons
61
Copyright © 2011 LOGTEL
Service
apiVersion: v1
kind: Service
metadata:
name: drupal
spec:
selector:
app: drupal
ports:
- name: http-port
port: 80
type: LoadBalancer
 curl http://drupal/cron.php
 Manages ports and internal IP’s with
domain name resolution
 Opens ports on agent nodes
 Manages load balancing between pods
 Provisions cloud provider load balancer
 Exposes pods to Kubernetes service
discovery
62
Copyright © 2011 LOGTEL
External Service
kind: Service
apiVersion: v1
metadata:
name: mysql-service
spec:
type: ExternalName
externalName:
mysql.example.com
ports:
- port: 3306
 Use RDS and provider services when possible
 No need to hard code external services in your application
 Adds an external resource to Kubernetes service discovery
63
Copyright © 2011 LOGTEL
Deployment: Configuration Management
apiVersion: extensions/v1beta1
kind: Deployment
spec:
replicas: 2
template:
spec:
containers:
- name: drupal
image: cr.io/repo/mydrupal:v1
ports:
containerPort: 80
env:
- name: DB_HOSTNAME
value: mysql-service
- name: DB_PASSWORD
valueFrom:
secretKeyRef:
name: mysql-service-secrets
key: password
imagePullSecrets:
- name: registrykey
64
* $databases['default']['default'] = array(
* 'driver' => 'sqlite',
* 'database' =>
'/path/to/databasefilename',
* );
* @endcode
*/
$databases['default']['default'] = array(
'driver' => 'mysql',
'database' => 'mydrupaldb',
'username' => getenv('DB_USERNAME'),
'password' => getenv('DB_PASSWORD'),
'host' => getenv('DB_HOSTNAME'),
);
/**
* Access control for update.php script.
*
* If you are updating your Drupal installation
using
* are not logged in using either an account
with the
* updates" permission or the site
maintenance account
* created during installation), you will need
Copyright © 2011 LOGTEL
Deployment: Volumes
apiVersion: extensions/v1beta1
kind: Deployment
spec:
replicas: 2
template:
spec:
containers:
- name: drupal
image: cr.io/repo/mydrupal:v1
ports:
containerPort: 80
volumeMounts:
- name: my-drupal-volume
mountPath: /drupal-
7.56/sites/files
volumes:
- name: my-drupal-volume
azureFile:
secretName: azure-storage-
secret
shareName: <pre-existing-file-
 Manages networked drives across
containers and VM’s
 volumeMounts sets the mount
path and references a named
volume
 Volumes can be defined as
 Pre-created named volumes
 Dynamically provisioned
Persistent Volume Claims
65
Copyright © 2011 LOGTEL 66
The end ;-)
Samuel.dratwa@gmail.com
Copyright © 2011 LOGTEL 67
Copyright © 2011 LOGTEL
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
68
Azure App Service
Quickly build, deploy, and scale web apps
Preview - now supports Windows Server containers
Introduction to Kubernetes
Fundamentals of Windows containers
and Windows container-based web
apps on Azure App Service
Azure Container Instances (ACI)
THR2206 - Run a serverless Kubernetes
cluster by bridging AKS and ACI
through the Virtual-Kubelet
Azure Kubernetes Service (AKS)
Fully managed Kubernetes orchestration service
Auto patching, auto scaling, auto updates
Use the full Kubernetes ecosystem (100% upstream)
Deeply integrated with Azure Dev Tools and services
Service Fabric
Windows and Linux Containers
Stateless and stateful microservices
Deploy on Azure, Azure Stack and on-premises
Service Fabric Mesh
Fully managed microservices platform, built on Service Fabric
Windows and Linux Containers
Optimizing
for microservice
development
Tracking multiple
deployment pipelines
while maintaining agile
updates
Focusing on business
logic instead of
microservice platform
maintenance
Dealing with the
complexity
of network communications
Monitoring and
governance at overarching
and granular levels
Achieving reliable state
and data consistency
without latency issues
Running highly
secure
applications at
scale
</>
.NET
</>
Optimizing
for microservice
development
Tracking multiple
deployment pipelines while
maintaining agile updates
Focusing on business logic
instead of microservice
platform maintenance
Dealing with the complexity
of interactions and network
communications
Monitoring and
governance at overarching
and granular levels
Achieving reliable state
and data consistency
without latency issues
Running highly
secure applications
at scale
Build Deploy Operate
Flexible
infrastructure
Lifecycle
managemen
t
24/7
availability &
performance
Elastic
scalabilit
y
Microservice
and
container
orchestratio
n
Security &
complianc
e
Health &
monitorin
g
Challenges
</>
Azure Service Fabric
.NET
</>
Build and deploy containers and microservices on Windows and Linux, at any scale, on any cloud
Programming
Models
Dev & Ops
Tooling
Orchestration Lifecycle
Management
Health &
Monitoring
Always On
Availability
Auto
Scaling
AzureOn-premises infrastructureAny cloudDev machine
Service Fabric: cloud application platform
Build OperateDeploy
Azure Service Fabric offerings
Bring your own infrastructure
Service Fabric
Standalone
On-premisesAny cloud
Dev machine
Dedicated Azure clusters
Azure
Service Fabric
Azure
Service Fabric Mesh
Serverless microservices
Service Fabric
Full Control Fully managed
Azure Service Fabric offerings
Bring your own infrastructure
Service Fabric
Standalone
On-premisesAny cloud
Dev machine
Dedicated Azure clusters
Azure
Service Fabric
Azure
Service Fabric Mesh
Serverless microservices
Virtual machines
OS patching
Runtime upgrades
Capacity planning
Network and
storage
Micro-billing
App deployment
You
Azure
Responsibility
Cluster capacity
Network and
storage
App deployment
Virtual machines
OS patching
Runtime
upgrades
Hardware
OS patching
Runtime upgrades
Cluster capacity
Network and storage
App deployment
Migrate existing applications as-is to the
cloud, including using containers, to reduce
cost and enable DevOps deployments
New applications conceived and built
with the cloud in mind using
microservices architecture
Azure Service Fabric is designed for mission-critical services
Power BI
Dynamic
s365
Intune
Cortana Skype for
business
Cosmos DB
IoT Hub
Event Hub
SQL Database
Azure
Monitor
Core
Azure
Services
Archive
Storage
Visual Studio
Team
Services
Stream
Analytics
Azure
Database for
PostgreSQL
Azure Database
for MySQL
Azure
Container
Registry
Event Grid

Weitere ähnliche Inhalte

Was ist angesagt?

OpenNebula Interoperability and Portability DMTF 2011
OpenNebula Interoperability and Portability  DMTF 2011OpenNebula Interoperability and Portability  DMTF 2011
OpenNebula Interoperability and Portability DMTF 2011Ignacio M. Llorente
 
Open source sdn controllers comparison
Open source sdn controllers comparisonOpen source sdn controllers comparison
Open source sdn controllers comparisonYashaswi Jain
 
Open nebula leading innovation in cloud computing management
Open nebula   leading innovation in cloud computing managementOpen nebula   leading innovation in cloud computing management
Open nebula leading innovation in cloud computing managementIgnacio M. Llorente
 
Innovation in cloud computing architectures with open nebula
Innovation in cloud computing architectures with open nebulaInnovation in cloud computing architectures with open nebula
Innovation in cloud computing architectures with open nebulaIgnacio M. Llorente
 
SDN 101: Software Defined Networking Course - Sameh Zaghloul/IBM - 2014
SDN 101: Software Defined Networking Course - Sameh Zaghloul/IBM - 2014SDN 101: Software Defined Networking Course - Sameh Zaghloul/IBM - 2014
SDN 101: Software Defined Networking Course - Sameh Zaghloul/IBM - 2014SAMeh Zaghloul
 
20120524 cern data centre evolution v2
20120524 cern data centre evolution v220120524 cern data centre evolution v2
20120524 cern data centre evolution v2Tim Bell
 
Connecting Docker for Cloud IaaS (Speech at CSDN-Oct18
Connecting Docker for Cloud IaaS (Speech at CSDN-Oct18Connecting Docker for Cloud IaaS (Speech at CSDN-Oct18
Connecting Docker for Cloud IaaS (Speech at CSDN-Oct18DaoliCloud Ltd
 
Midokura OpenStack Day Korea Talk: MidoNet Open Source Network Virtualization...
Midokura OpenStack Day Korea Talk: MidoNet Open Source Network Virtualization...Midokura OpenStack Day Korea Talk: MidoNet Open Source Network Virtualization...
Midokura OpenStack Day Korea Talk: MidoNet Open Source Network Virtualization...Dan Mihai Dumitriu
 
ISC Cloud 2013 - Cloud Architectures for HPC – Industry Case Studies
 ISC Cloud 2013 - Cloud Architectures for HPC – Industry Case Studies ISC Cloud 2013 - Cloud Architectures for HPC – Industry Case Studies
ISC Cloud 2013 - Cloud Architectures for HPC – Industry Case StudiesOpenNebula Project
 
StarlingX - Project Onboarding
StarlingX - Project OnboardingStarlingX - Project Onboarding
StarlingX - Project OnboardingShuquan Huang
 
Open Stack Cloud Services
Open Stack Cloud ServicesOpen Stack Cloud Services
Open Stack Cloud ServicesSaurabh Gupta
 
Serverless Patterns by Jesse Butler
Serverless Patterns by Jesse ButlerServerless Patterns by Jesse Butler
Serverless Patterns by Jesse ButlerOracle Developers
 
Akraino and Edge Computing
Akraino and Edge ComputingAkraino and Edge Computing
Akraino and Edge ComputingLiz Warner
 
Constantino vazquez open nebula cloud case studies
Constantino vazquez   open nebula cloud case studiesConstantino vazquez   open nebula cloud case studies
Constantino vazquez open nebula cloud case studiesCloudExpoEurope
 
Presentatie Cisco NetApp Proact over FlexPod
Presentatie Cisco NetApp Proact over FlexPodPresentatie Cisco NetApp Proact over FlexPod
Presentatie Cisco NetApp Proact over FlexPodProact Netherlands B.V.
 
ONP 2.1 platforms maximize VNF interoperability
ONP 2.1 platforms maximize VNF interoperabilityONP 2.1 platforms maximize VNF interoperability
ONP 2.1 platforms maximize VNF interoperabilityPaul Stevens
 

Was ist angesagt? (20)

The State of Linux Containers
The State of Linux ContainersThe State of Linux Containers
The State of Linux Containers
 
OpenNebula Interoperability and Portability DMTF 2011
OpenNebula Interoperability and Portability  DMTF 2011OpenNebula Interoperability and Portability  DMTF 2011
OpenNebula Interoperability and Portability DMTF 2011
 
Open source sdn controllers comparison
Open source sdn controllers comparisonOpen source sdn controllers comparison
Open source sdn controllers comparison
 
Open nebula leading innovation in cloud computing management
Open nebula   leading innovation in cloud computing managementOpen nebula   leading innovation in cloud computing management
Open nebula leading innovation in cloud computing management
 
NFV_vCPE
NFV_vCPENFV_vCPE
NFV_vCPE
 
Network Virtualization
Network VirtualizationNetwork Virtualization
Network Virtualization
 
Innovation in cloud computing architectures with open nebula
Innovation in cloud computing architectures with open nebulaInnovation in cloud computing architectures with open nebula
Innovation in cloud computing architectures with open nebula
 
Network Virtualization
Network Virtualization Network Virtualization
Network Virtualization
 
SDN 101: Software Defined Networking Course - Sameh Zaghloul/IBM - 2014
SDN 101: Software Defined Networking Course - Sameh Zaghloul/IBM - 2014SDN 101: Software Defined Networking Course - Sameh Zaghloul/IBM - 2014
SDN 101: Software Defined Networking Course - Sameh Zaghloul/IBM - 2014
 
20120524 cern data centre evolution v2
20120524 cern data centre evolution v220120524 cern data centre evolution v2
20120524 cern data centre evolution v2
 
Connecting Docker for Cloud IaaS (Speech at CSDN-Oct18
Connecting Docker for Cloud IaaS (Speech at CSDN-Oct18Connecting Docker for Cloud IaaS (Speech at CSDN-Oct18
Connecting Docker for Cloud IaaS (Speech at CSDN-Oct18
 
Midokura OpenStack Day Korea Talk: MidoNet Open Source Network Virtualization...
Midokura OpenStack Day Korea Talk: MidoNet Open Source Network Virtualization...Midokura OpenStack Day Korea Talk: MidoNet Open Source Network Virtualization...
Midokura OpenStack Day Korea Talk: MidoNet Open Source Network Virtualization...
 
ISC Cloud 2013 - Cloud Architectures for HPC – Industry Case Studies
 ISC Cloud 2013 - Cloud Architectures for HPC – Industry Case Studies ISC Cloud 2013 - Cloud Architectures for HPC – Industry Case Studies
ISC Cloud 2013 - Cloud Architectures for HPC – Industry Case Studies
 
StarlingX - Project Onboarding
StarlingX - Project OnboardingStarlingX - Project Onboarding
StarlingX - Project Onboarding
 
Open Stack Cloud Services
Open Stack Cloud ServicesOpen Stack Cloud Services
Open Stack Cloud Services
 
Serverless Patterns by Jesse Butler
Serverless Patterns by Jesse ButlerServerless Patterns by Jesse Butler
Serverless Patterns by Jesse Butler
 
Akraino and Edge Computing
Akraino and Edge ComputingAkraino and Edge Computing
Akraino and Edge Computing
 
Constantino vazquez open nebula cloud case studies
Constantino vazquez   open nebula cloud case studiesConstantino vazquez   open nebula cloud case studies
Constantino vazquez open nebula cloud case studies
 
Presentatie Cisco NetApp Proact over FlexPod
Presentatie Cisco NetApp Proact over FlexPodPresentatie Cisco NetApp Proact over FlexPod
Presentatie Cisco NetApp Proact over FlexPod
 
ONP 2.1 platforms maximize VNF interoperability
ONP 2.1 platforms maximize VNF interoperabilityONP 2.1 platforms maximize VNF interoperability
ONP 2.1 platforms maximize VNF interoperability
 

Ähnlich wie Introduction to Kubernetes

Managing containers on Oracle Cloud by Jamal Arif
Managing containers on Oracle Cloud by Jamal ArifManaging containers on Oracle Cloud by Jamal Arif
Managing containers on Oracle Cloud by Jamal ArifOracle Developers
 
Federated Kubernetes: As a Platform for Distributed Scientific Computing
Federated Kubernetes: As a Platform for Distributed Scientific ComputingFederated Kubernetes: As a Platform for Distributed Scientific Computing
Federated Kubernetes: As a Platform for Distributed Scientific ComputingBob Killen
 
Develop and deploy Kubernetes applications with Docker - IBM Index 2018
Develop and deploy Kubernetes  applications with Docker - IBM Index 2018Develop and deploy Kubernetes  applications with Docker - IBM Index 2018
Develop and deploy Kubernetes applications with Docker - IBM Index 2018Patrick Chanezon
 
Sumo Logic Cert Jam - Advanced Metrics with Kubernetes
Sumo Logic Cert Jam - Advanced Metrics with KubernetesSumo Logic Cert Jam - Advanced Metrics with Kubernetes
Sumo Logic Cert Jam - Advanced Metrics with KubernetesSumo Logic
 
Kubernetes for Java developers
Kubernetes for Java developersKubernetes for Java developers
Kubernetes for Java developersRobert Barr
 
prodops.io k8s presentation
prodops.io k8s presentationprodops.io k8s presentation
prodops.io k8s presentationProdops.io
 
01 - VMUGIT - Lecce 2018 - Fabio Rapposelli, VMware
01 - VMUGIT - Lecce 2018 - Fabio Rapposelli, VMware01 - VMUGIT - Lecce 2018 - Fabio Rapposelli, VMware
01 - VMUGIT - Lecce 2018 - Fabio Rapposelli, VMwareVMUG IT
 
Using Docker container technology with F5 Networks products and services
Using Docker container technology with F5 Networks products and servicesUsing Docker container technology with F5 Networks products and services
Using Docker container technology with F5 Networks products and servicesF5 Networks
 
Kubernetes day 2 Operations
Kubernetes day 2 OperationsKubernetes day 2 Operations
Kubernetes day 2 OperationsPaul Czarkowski
 
Introduction to containers, k8s, Microservices & Cloud Native
Introduction to containers, k8s, Microservices & Cloud NativeIntroduction to containers, k8s, Microservices & Cloud Native
Introduction to containers, k8s, Microservices & Cloud NativeTerry Wang
 
KubernetesPPT.pptx
KubernetesPPT.pptxKubernetesPPT.pptx
KubernetesPPT.pptxRyuzaki360
 
Building Cloud-Native Applications with Kubernetes, Helm and Kubeless
Building Cloud-Native Applications with Kubernetes, Helm and KubelessBuilding Cloud-Native Applications with Kubernetes, Helm and Kubeless
Building Cloud-Native Applications with Kubernetes, Helm and KubelessBitnami
 
Zero-to-Hero: Running Postgres in Kubernetes
Zero-to-Hero: Running Postgres in KubernetesZero-to-Hero: Running Postgres in Kubernetes
Zero-to-Hero: Running Postgres in KubernetesEDB
 
Dev opsec dockerimage_patch_n_lifecyclemanagement_
Dev opsec dockerimage_patch_n_lifecyclemanagement_Dev opsec dockerimage_patch_n_lifecyclemanagement_
Dev opsec dockerimage_patch_n_lifecyclemanagement_kanedafromparis
 
Kubernetes for Serverless - Serverless Summit 2017 - Krishna Kumar
Kubernetes for Serverless  - Serverless Summit 2017 - Krishna KumarKubernetes for Serverless  - Serverless Summit 2017 - Krishna Kumar
Kubernetes for Serverless - Serverless Summit 2017 - Krishna KumarCodeOps Technologies LLP
 
Why kubernetes for Serverless (FaaS)
Why kubernetes for Serverless (FaaS)Why kubernetes for Serverless (FaaS)
Why kubernetes for Serverless (FaaS)Krishna-Kumar
 
DevOps Days Boston 2017: Real-world Kubernetes for DevOps
DevOps Days Boston 2017: Real-world Kubernetes for DevOpsDevOps Days Boston 2017: Real-world Kubernetes for DevOps
DevOps Days Boston 2017: Real-world Kubernetes for DevOpsAmbassador Labs
 
Introduction to KubeDirector - SF Kubernetes Meetup
Introduction to KubeDirector - SF Kubernetes MeetupIntroduction to KubeDirector - SF Kubernetes Meetup
Introduction to KubeDirector - SF Kubernetes MeetupBlueData, Inc.
 
Docker Application to Scientific Computing
Docker Application to Scientific ComputingDocker Application to Scientific Computing
Docker Application to Scientific ComputingPeter Bryzgalov
 
Implementing DevOps – How it came to the fore, its key elements and example d...
Implementing DevOps – How it came to the fore, its key elements and example d...Implementing DevOps – How it came to the fore, its key elements and example d...
Implementing DevOps – How it came to the fore, its key elements and example d...Barton George
 

Ähnlich wie Introduction to Kubernetes (20)

Managing containers on Oracle Cloud by Jamal Arif
Managing containers on Oracle Cloud by Jamal ArifManaging containers on Oracle Cloud by Jamal Arif
Managing containers on Oracle Cloud by Jamal Arif
 
Federated Kubernetes: As a Platform for Distributed Scientific Computing
Federated Kubernetes: As a Platform for Distributed Scientific ComputingFederated Kubernetes: As a Platform for Distributed Scientific Computing
Federated Kubernetes: As a Platform for Distributed Scientific Computing
 
Develop and deploy Kubernetes applications with Docker - IBM Index 2018
Develop and deploy Kubernetes  applications with Docker - IBM Index 2018Develop and deploy Kubernetes  applications with Docker - IBM Index 2018
Develop and deploy Kubernetes applications with Docker - IBM Index 2018
 
Sumo Logic Cert Jam - Advanced Metrics with Kubernetes
Sumo Logic Cert Jam - Advanced Metrics with KubernetesSumo Logic Cert Jam - Advanced Metrics with Kubernetes
Sumo Logic Cert Jam - Advanced Metrics with Kubernetes
 
Kubernetes for Java developers
Kubernetes for Java developersKubernetes for Java developers
Kubernetes for Java developers
 
prodops.io k8s presentation
prodops.io k8s presentationprodops.io k8s presentation
prodops.io k8s presentation
 
01 - VMUGIT - Lecce 2018 - Fabio Rapposelli, VMware
01 - VMUGIT - Lecce 2018 - Fabio Rapposelli, VMware01 - VMUGIT - Lecce 2018 - Fabio Rapposelli, VMware
01 - VMUGIT - Lecce 2018 - Fabio Rapposelli, VMware
 
Using Docker container technology with F5 Networks products and services
Using Docker container technology with F5 Networks products and servicesUsing Docker container technology with F5 Networks products and services
Using Docker container technology with F5 Networks products and services
 
Kubernetes day 2 Operations
Kubernetes day 2 OperationsKubernetes day 2 Operations
Kubernetes day 2 Operations
 
Introduction to containers, k8s, Microservices & Cloud Native
Introduction to containers, k8s, Microservices & Cloud NativeIntroduction to containers, k8s, Microservices & Cloud Native
Introduction to containers, k8s, Microservices & Cloud Native
 
KubernetesPPT.pptx
KubernetesPPT.pptxKubernetesPPT.pptx
KubernetesPPT.pptx
 
Building Cloud-Native Applications with Kubernetes, Helm and Kubeless
Building Cloud-Native Applications with Kubernetes, Helm and KubelessBuilding Cloud-Native Applications with Kubernetes, Helm and Kubeless
Building Cloud-Native Applications with Kubernetes, Helm and Kubeless
 
Zero-to-Hero: Running Postgres in Kubernetes
Zero-to-Hero: Running Postgres in KubernetesZero-to-Hero: Running Postgres in Kubernetes
Zero-to-Hero: Running Postgres in Kubernetes
 
Dev opsec dockerimage_patch_n_lifecyclemanagement_
Dev opsec dockerimage_patch_n_lifecyclemanagement_Dev opsec dockerimage_patch_n_lifecyclemanagement_
Dev opsec dockerimage_patch_n_lifecyclemanagement_
 
Kubernetes for Serverless - Serverless Summit 2017 - Krishna Kumar
Kubernetes for Serverless  - Serverless Summit 2017 - Krishna KumarKubernetes for Serverless  - Serverless Summit 2017 - Krishna Kumar
Kubernetes for Serverless - Serverless Summit 2017 - Krishna Kumar
 
Why kubernetes for Serverless (FaaS)
Why kubernetes for Serverless (FaaS)Why kubernetes for Serverless (FaaS)
Why kubernetes for Serverless (FaaS)
 
DevOps Days Boston 2017: Real-world Kubernetes for DevOps
DevOps Days Boston 2017: Real-world Kubernetes for DevOpsDevOps Days Boston 2017: Real-world Kubernetes for DevOps
DevOps Days Boston 2017: Real-world Kubernetes for DevOps
 
Introduction to KubeDirector - SF Kubernetes Meetup
Introduction to KubeDirector - SF Kubernetes MeetupIntroduction to KubeDirector - SF Kubernetes Meetup
Introduction to KubeDirector - SF Kubernetes Meetup
 
Docker Application to Scientific Computing
Docker Application to Scientific ComputingDocker Application to Scientific Computing
Docker Application to Scientific Computing
 
Implementing DevOps – How it came to the fore, its key elements and example d...
Implementing DevOps – How it came to the fore, its key elements and example d...Implementing DevOps – How it came to the fore, its key elements and example d...
Implementing DevOps – How it came to the fore, its key elements and example d...
 

Mehr von Samuel Dratwa

Artificial Intelligence (and the telecom industry)
Artificial Intelligence (and the telecom industry)Artificial Intelligence (and the telecom industry)
Artificial Intelligence (and the telecom industry)Samuel Dratwa
 
IoT (and M2M and WoT) From the Operators (CSP) perspective
IoT (and M2M and WoT) From the Operators (CSP) perspectiveIoT (and M2M and WoT) From the Operators (CSP) perspective
IoT (and M2M and WoT) From the Operators (CSP) perspectiveSamuel Dratwa
 
Introduction to Cloud Computing 2021
Introduction to Cloud Computing 2021Introduction to Cloud Computing 2021
Introduction to Cloud Computing 2021Samuel Dratwa
 
Is kubernetes a good choice for orchestration
Is kubernetes a good choice for orchestrationIs kubernetes a good choice for orchestration
Is kubernetes a good choice for orchestrationSamuel Dratwa
 
Telecom Abbreviations
Telecom AbbreviationsTelecom Abbreviations
Telecom AbbreviationsSamuel Dratwa
 
מונחים טכנולוגים למנהלי הדרכה באמדוקס
מונחים טכנולוגים למנהלי הדרכה באמדוקסמונחים טכנולוגים למנהלי הדרכה באמדוקס
מונחים טכנולוגים למנהלי הדרכה באמדוקסSamuel Dratwa
 
Basic networking 07-2012
Basic networking 07-2012Basic networking 07-2012
Basic networking 07-2012Samuel Dratwa
 
רשתות חברתיות ככלי מידע עסקי 2012
רשתות חברתיות ככלי מידע עסקי 2012רשתות חברתיות ככלי מידע עסקי 2012
רשתות חברתיות ככלי מידע עסקי 2012Samuel Dratwa
 
Web 2.0 (and the telecom industry)
Web 2.0 (and the telecom industry)Web 2.0 (and the telecom industry)
Web 2.0 (and the telecom industry)Samuel Dratwa
 
רשתות חברתיות ומידע עסקי - או למה צריך להיות שם
רשתות חברתיות ומידע עסקי - או למה צריך להיות שםרשתות חברתיות ומידע עסקי - או למה צריך להיות שם
רשתות חברתיות ומידע עסקי - או למה צריך להיות שםSamuel Dratwa
 

Mehr von Samuel Dratwa (13)

Artificial Intelligence (and the telecom industry)
Artificial Intelligence (and the telecom industry)Artificial Intelligence (and the telecom industry)
Artificial Intelligence (and the telecom industry)
 
IoT (and M2M and WoT) From the Operators (CSP) perspective
IoT (and M2M and WoT) From the Operators (CSP) perspectiveIoT (and M2M and WoT) From the Operators (CSP) perspective
IoT (and M2M and WoT) From the Operators (CSP) perspective
 
Introduction to Cloud Computing 2021
Introduction to Cloud Computing 2021Introduction to Cloud Computing 2021
Introduction to Cloud Computing 2021
 
Is kubernetes a good choice for orchestration
Is kubernetes a good choice for orchestrationIs kubernetes a good choice for orchestration
Is kubernetes a good choice for orchestration
 
Telecom Abbreviations
Telecom AbbreviationsTelecom Abbreviations
Telecom Abbreviations
 
מונחים טכנולוגים למנהלי הדרכה באמדוקס
מונחים טכנולוגים למנהלי הדרכה באמדוקסמונחים טכנולוגים למנהלי הדרכה באמדוקס
מונחים טכנולוגים למנהלי הדרכה באמדוקס
 
Amdocs ai s1
Amdocs ai s1Amdocs ai s1
Amdocs ai s1
 
Basic networking 07-2012
Basic networking 07-2012Basic networking 07-2012
Basic networking 07-2012
 
רשתות חברתיות ככלי מידע עסקי 2012
רשתות חברתיות ככלי מידע עסקי 2012רשתות חברתיות ככלי מידע עסקי 2012
רשתות חברתיות ככלי מידע עסקי 2012
 
NGN & IMS
NGN & IMSNGN & IMS
NGN & IMS
 
The future telecom
The future telecomThe future telecom
The future telecom
 
Web 2.0 (and the telecom industry)
Web 2.0 (and the telecom industry)Web 2.0 (and the telecom industry)
Web 2.0 (and the telecom industry)
 
רשתות חברתיות ומידע עסקי - או למה צריך להיות שם
רשתות חברתיות ומידע עסקי - או למה צריך להיות שםרשתות חברתיות ומידע עסקי - או למה צריך להיות שם
רשתות חברתיות ומידע עסקי - או למה צריך להיות שם
 

Kürzlich hochgeladen

KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCost
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCostKubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCost
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCostMatt Ray
 
Nanopower In Semiconductor Industry.pdf
Nanopower  In Semiconductor Industry.pdfNanopower  In Semiconductor Industry.pdf
Nanopower In Semiconductor Industry.pdfPedro Manuel
 
Artificial Intelligence & SEO Trends for 2024
Artificial Intelligence & SEO Trends for 2024Artificial Intelligence & SEO Trends for 2024
Artificial Intelligence & SEO Trends for 2024D Cloud Solutions
 
VoIP Service and Marketing using Odoo and Asterisk PBX
VoIP Service and Marketing using Odoo and Asterisk PBXVoIP Service and Marketing using Odoo and Asterisk PBX
VoIP Service and Marketing using Odoo and Asterisk PBXTarek Kalaji
 
Introduction to Matsuo Laboratory (ENG).pptx
Introduction to Matsuo Laboratory (ENG).pptxIntroduction to Matsuo Laboratory (ENG).pptx
Introduction to Matsuo Laboratory (ENG).pptxMatsuo Lab
 
9 Steps For Building Winning Founding Team
9 Steps For Building Winning Founding Team9 Steps For Building Winning Founding Team
9 Steps For Building Winning Founding TeamAdam Moalla
 
UiPath Community: AI for UiPath Automation Developers
UiPath Community: AI for UiPath Automation DevelopersUiPath Community: AI for UiPath Automation Developers
UiPath Community: AI for UiPath Automation DevelopersUiPathCommunity
 
Empowering Africa's Next Generation: The AI Leadership Blueprint
Empowering Africa's Next Generation: The AI Leadership BlueprintEmpowering Africa's Next Generation: The AI Leadership Blueprint
Empowering Africa's Next Generation: The AI Leadership BlueprintMahmoud Rabie
 
COMPUTER 10 Lesson 8 - Building a Website
COMPUTER 10 Lesson 8 - Building a WebsiteCOMPUTER 10 Lesson 8 - Building a Website
COMPUTER 10 Lesson 8 - Building a Websitedgelyza
 
UiPath Solutions Management Preview - Northern CA Chapter - March 22.pdf
UiPath Solutions Management Preview - Northern CA Chapter - March 22.pdfUiPath Solutions Management Preview - Northern CA Chapter - March 22.pdf
UiPath Solutions Management Preview - Northern CA Chapter - March 22.pdfDianaGray10
 
How Accurate are Carbon Emissions Projections?
How Accurate are Carbon Emissions Projections?How Accurate are Carbon Emissions Projections?
How Accurate are Carbon Emissions Projections?IES VE
 
COMPUTER 10: Lesson 7 - File Storage and Online Collaboration
COMPUTER 10: Lesson 7 - File Storage and Online CollaborationCOMPUTER 10: Lesson 7 - File Storage and Online Collaboration
COMPUTER 10: Lesson 7 - File Storage and Online Collaborationbruanjhuli
 
Igniting Next Level Productivity with AI-Infused Data Integration Workflows
Igniting Next Level Productivity with AI-Infused Data Integration WorkflowsIgniting Next Level Productivity with AI-Infused Data Integration Workflows
Igniting Next Level Productivity with AI-Infused Data Integration WorkflowsSafe Software
 
UiPath Platform: The Backend Engine Powering Your Automation - Session 1
UiPath Platform: The Backend Engine Powering Your Automation - Session 1UiPath Platform: The Backend Engine Powering Your Automation - Session 1
UiPath Platform: The Backend Engine Powering Your Automation - Session 1DianaGray10
 
Building AI-Driven Apps Using Semantic Kernel.pptx
Building AI-Driven Apps Using Semantic Kernel.pptxBuilding AI-Driven Apps Using Semantic Kernel.pptx
Building AI-Driven Apps Using Semantic Kernel.pptxUdaiappa Ramachandran
 
UiPath Studio Web workshop series - Day 7
UiPath Studio Web workshop series - Day 7UiPath Studio Web workshop series - Day 7
UiPath Studio Web workshop series - Day 7DianaGray10
 
OpenShift Commons Paris - Choose Your Own Observability Adventure
OpenShift Commons Paris - Choose Your Own Observability AdventureOpenShift Commons Paris - Choose Your Own Observability Adventure
OpenShift Commons Paris - Choose Your Own Observability AdventureEric D. Schabell
 
Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...
Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...
Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...DianaGray10
 
Meet the new FSP 3000 M-Flex800™
Meet the new FSP 3000 M-Flex800™Meet the new FSP 3000 M-Flex800™
Meet the new FSP 3000 M-Flex800™Adtran
 

Kürzlich hochgeladen (20)

KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCost
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCostKubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCost
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCost
 
Nanopower In Semiconductor Industry.pdf
Nanopower  In Semiconductor Industry.pdfNanopower  In Semiconductor Industry.pdf
Nanopower In Semiconductor Industry.pdf
 
201610817 - edge part1
201610817 - edge part1201610817 - edge part1
201610817 - edge part1
 
Artificial Intelligence & SEO Trends for 2024
Artificial Intelligence & SEO Trends for 2024Artificial Intelligence & SEO Trends for 2024
Artificial Intelligence & SEO Trends for 2024
 
VoIP Service and Marketing using Odoo and Asterisk PBX
VoIP Service and Marketing using Odoo and Asterisk PBXVoIP Service and Marketing using Odoo and Asterisk PBX
VoIP Service and Marketing using Odoo and Asterisk PBX
 
Introduction to Matsuo Laboratory (ENG).pptx
Introduction to Matsuo Laboratory (ENG).pptxIntroduction to Matsuo Laboratory (ENG).pptx
Introduction to Matsuo Laboratory (ENG).pptx
 
9 Steps For Building Winning Founding Team
9 Steps For Building Winning Founding Team9 Steps For Building Winning Founding Team
9 Steps For Building Winning Founding Team
 
UiPath Community: AI for UiPath Automation Developers
UiPath Community: AI for UiPath Automation DevelopersUiPath Community: AI for UiPath Automation Developers
UiPath Community: AI for UiPath Automation Developers
 
Empowering Africa's Next Generation: The AI Leadership Blueprint
Empowering Africa's Next Generation: The AI Leadership BlueprintEmpowering Africa's Next Generation: The AI Leadership Blueprint
Empowering Africa's Next Generation: The AI Leadership Blueprint
 
COMPUTER 10 Lesson 8 - Building a Website
COMPUTER 10 Lesson 8 - Building a WebsiteCOMPUTER 10 Lesson 8 - Building a Website
COMPUTER 10 Lesson 8 - Building a Website
 
UiPath Solutions Management Preview - Northern CA Chapter - March 22.pdf
UiPath Solutions Management Preview - Northern CA Chapter - March 22.pdfUiPath Solutions Management Preview - Northern CA Chapter - March 22.pdf
UiPath Solutions Management Preview - Northern CA Chapter - March 22.pdf
 
How Accurate are Carbon Emissions Projections?
How Accurate are Carbon Emissions Projections?How Accurate are Carbon Emissions Projections?
How Accurate are Carbon Emissions Projections?
 
COMPUTER 10: Lesson 7 - File Storage and Online Collaboration
COMPUTER 10: Lesson 7 - File Storage and Online CollaborationCOMPUTER 10: Lesson 7 - File Storage and Online Collaboration
COMPUTER 10: Lesson 7 - File Storage and Online Collaboration
 
Igniting Next Level Productivity with AI-Infused Data Integration Workflows
Igniting Next Level Productivity with AI-Infused Data Integration WorkflowsIgniting Next Level Productivity with AI-Infused Data Integration Workflows
Igniting Next Level Productivity with AI-Infused Data Integration Workflows
 
UiPath Platform: The Backend Engine Powering Your Automation - Session 1
UiPath Platform: The Backend Engine Powering Your Automation - Session 1UiPath Platform: The Backend Engine Powering Your Automation - Session 1
UiPath Platform: The Backend Engine Powering Your Automation - Session 1
 
Building AI-Driven Apps Using Semantic Kernel.pptx
Building AI-Driven Apps Using Semantic Kernel.pptxBuilding AI-Driven Apps Using Semantic Kernel.pptx
Building AI-Driven Apps Using Semantic Kernel.pptx
 
UiPath Studio Web workshop series - Day 7
UiPath Studio Web workshop series - Day 7UiPath Studio Web workshop series - Day 7
UiPath Studio Web workshop series - Day 7
 
OpenShift Commons Paris - Choose Your Own Observability Adventure
OpenShift Commons Paris - Choose Your Own Observability AdventureOpenShift Commons Paris - Choose Your Own Observability Adventure
OpenShift Commons Paris - Choose Your Own Observability Adventure
 
Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...
Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...
Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...
 
Meet the new FSP 3000 M-Flex800™
Meet the new FSP 3000 M-Flex800™Meet the new FSP 3000 M-Flex800™
Meet the new FSP 3000 M-Flex800™
 

Introduction to Kubernetes

  • 1. Copyright © 2011 LOGTEL Introduction to Kubernetes Samuel Dratwa Samuel.dratwa@gmail.com
  • 2. Copyright © 2011 LOGTEL 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
  • 3. Copyright © 2011 LOGTEL 3
  • 4. Copyright © 2011 LOGTEL 4
  • 5. Copyright © 2011 LOGTEL  Containers & Kubernetes Recap  Containers life cycles  Pods and Descriptors  Label Selectors  Services / ingress Services  Replica Set / Daemon Sets  Deployments  Kubernetes concepts  Resources (and ResourceQuota)  Application lifecycle  Networking  Orchestration  Hands-On Agenda – Day 1 5
  • 6. Copyright © 2011 LOGTEL  Recap of 1st day and question answering  Introduction to Rancher  Creating a Cluster  Deploying an Application  Kubernetes concepts  Rolling updates and rollbacks  Config Map & Secrets  Self-healing and auto-scaling applications  Kubernetes Hands-On  Updating a Pod  Using Config Map  Auto-Scaling  Helm – concept and architecture  Final thoughts and conclusions Agenda – Day 2 6
  • 7. 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
  • 8. 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
  • 10. Copyright © 2011 LOGTEL Docker is a “Shipping Container” 10
  • 11. Copyright © 2011 LOGTEL What’s missing 11
  • 12. Copyright © 2011 LOGTEL Options for Container Cloud Orchestration on Power 12 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
  • 13. Copyright © 2011 LOGTEL Source: Shippable.com http://blog.shippable.com/why-the-adoption-of-kubernetes-will-explode-in-2018 kubernetes won the container orchestration war...
  • 14. Copyright © 2011 LOGTEL Kubernetes Layout 14
  • 15. Copyright © 2011 LOGTEL Swarm 15
  • 16. Copyright © 2011 LOGTEL 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 16
  • 17. Copyright © 2011 LOGTEL  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. 17
  • 18. Copyright © 2011 LOGTEL Kubernetes Features 18
  • 20. Copyright © 2011 LOGTEL Kubernetes Layout 20
  • 21. Copyright © 2011 LOGTEL 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. 21
  • 22. Copyright © 2011 LOGTEL 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. 22
  • 23. Copyright © 2011 LOGTEL 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. 23
  • 24. Copyright © 2011 LOGTEL 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. 24
  • 25. Copyright © 2011 LOGTEL 25
  • 26. Copyright © 2011 LOGTEL Kubernetes Architecture 26
  • 27. Copyright © 2011 LOGTEL 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. } } 27 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.
  • 28. Copyright © 2011 LOGTEL 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: "" 28
  • 29. Copyright © 2011 LOGTEL 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 29
  • 30. Copyright © 2011 LOGTEL 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 30
  • 31. Copyright © 2011 LOGTEL 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> 31
  • 32. Copyright © 2011 LOGTEL 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 32
  • 33. Copyright © 2011 LOGTEL 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) 33
  • 34. Copyright © 2011 LOGTEL 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. 34
  • 35. Copyright © 2011 LOGTEL Service Example 35
  • 36. Copyright © 2011 LOGTEL Basic Cluster 36  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
  • 37. Copyright © 2011 LOGTEL 37
  • 38. Copyright © 2011 LOGTEL 38
  • 39. Copyright © 2011 LOGTEL 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 . 39
  • 40. Copyright © 2011 LOGTEL 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 40
  • 41. Copyright © 2011 LOGTEL 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). 41
  • 42. Copyright © 2011 LOGTEL 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. 42
  • 43. Copyright © 2011 LOGTEL 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 43
  • 44. Copyright © 2011 LOGTEL 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. 44
  • 45. Copyright © 2011 LOGTEL 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 45
  • 46. Copyright © 2011 LOGTEL 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 46
  • 47. Copyright © 2011 LOGTEL 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 47
  • 48. Copyright © 2011 LOGTEL ResourceQuota (for namespace) apiVersion: v1 kind: ResourceQuota metadata: name: quota spec: hard: cpu: "20" memory: 1Gi pods: "10" replicationcontrollers: "20" resourcequotas: "1" services: "5" 48
  • 49. Copyright © 2011 LOGTEL 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. 49
  • 50. Copyright © 2011 LOGTEL 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 ✗ ✗
  • 51. Windows Server Container Architecture Source: Microsoft
  • 52. 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
  • 53. Copyright © 2011 LOGTEL 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. 53
  • 54. Copyright © 2011 LOGTEL The Pod is the core Kubernetes Component spec: template: spec: containers: - name: drupal image: cr.io/repo/mydrupal:v1 54  The Pod is the core component of Kubernetes  Collection of 1 or more containers  Each pod should focus on one container, however sidecar containers can be added to enhance features of the core container
  • 55. Copyright © 2011 LOGTEL Pods can Handle Scaling and Deployments  Kubernetes Handles:  System Performance  Scale up/down the number of pods based on CPU load or other criteria  System Monitoring  Probes to check the health of each pod  Any unhealthy ones get killed and new pod is put into service  Deployments  Deploy new versions of the container  Control traffic to the new pods to test the new version  Blue/Green deployments  Rolling deployments 55
  • 56. Copyright © 2011 LOGTEL Kubernetes Services tie together the pods apiVersion: v1 kind: Service metadata: name: drupal spec: selector: app: drupal ports: - name: http-port port: 80 type: LoadBalancer 56 Kubernetes Services are used to control communications with the pods  Load balance the requests  Don’t send traffic to the unhealthy ones  Only talk to the correct version
  • 57. Copyright © 2011 LOGTEL Services Structure allow multiple Components  Service architecture allow Kubernetes to handle things instead of us:  Service discovery  Load balancing  Scaling  Service discovery allows each pod just needs to call the name of the service it wants to talk to  Services have multiple options  Session based load balancing  Single port based services  External Services  The Service architecture of Kubernetes can be scaled up to handle as many services as you would like for your system 57
  • 58. Copyright © 2011 LOGTEL Where Is the Infrastructure?  You don’t have to worry about the infrastructure  The entire design of pods and services is described with YAML files  Nothing in deployments, pod management, service discovery, monitoring, etc required any knowledge about how many servers, IP addresses, load balancers, or anything else with the infrastructure  Behind the scenes, Kubernetes is aware of all of the servers available, load balancers, application gateways and will configure them automatically according to what is in the YAML files 58
  • 59. Copyright © 2011 LOGTEL DRUPAL EXAMPLES 59
  • 60. Copyright © 2011 LOGTEL Deployment apiVersion: extensions/v1beta1 kind: Deployment metadata: name: drupal spec: template: spec: containers: - name: drupal image: cr.io/repo/mydrupal:v1 ports: containerPort: 80  Deployment—connects a Pod with replication control and rollout management  Synchronizes app configuration across instances  Production deploys are as simple as updating an image tag  No more bouncing apache on a dozen servers  Contains a Pod spec
  • 61. Copyright © 2011 LOGTEL Autoscaling apiVersion: autoscaling/v1 kind: HorizontalPodAutoscaler spec: scaleTargetRef: apiVersion: extensions/v1beta1 kind: Deployment name: drupal minReplicas: 2 maxReplicas: 10 targetCPUUtilizationPercentage: 50  Realizes the promise of the cloud: scales your app in response to load, in real time  Kubernetes tracks resource utilization  Responds by adding or removing pods to the Replica Set  Kubernetes core supports CPU utilization  Other resources are available via add-ons  Pod autoscaling != node autoscaling  Node autoscaling for GCE and AWS as add-ons 61
  • 62. Copyright © 2011 LOGTEL Service apiVersion: v1 kind: Service metadata: name: drupal spec: selector: app: drupal ports: - name: http-port port: 80 type: LoadBalancer  curl http://drupal/cron.php  Manages ports and internal IP’s with domain name resolution  Opens ports on agent nodes  Manages load balancing between pods  Provisions cloud provider load balancer  Exposes pods to Kubernetes service discovery 62
  • 63. Copyright © 2011 LOGTEL External Service kind: Service apiVersion: v1 metadata: name: mysql-service spec: type: ExternalName externalName: mysql.example.com ports: - port: 3306  Use RDS and provider services when possible  No need to hard code external services in your application  Adds an external resource to Kubernetes service discovery 63
  • 64. Copyright © 2011 LOGTEL Deployment: Configuration Management apiVersion: extensions/v1beta1 kind: Deployment spec: replicas: 2 template: spec: containers: - name: drupal image: cr.io/repo/mydrupal:v1 ports: containerPort: 80 env: - name: DB_HOSTNAME value: mysql-service - name: DB_PASSWORD valueFrom: secretKeyRef: name: mysql-service-secrets key: password imagePullSecrets: - name: registrykey 64 * $databases['default']['default'] = array( * 'driver' => 'sqlite', * 'database' => '/path/to/databasefilename', * ); * @endcode */ $databases['default']['default'] = array( 'driver' => 'mysql', 'database' => 'mydrupaldb', 'username' => getenv('DB_USERNAME'), 'password' => getenv('DB_PASSWORD'), 'host' => getenv('DB_HOSTNAME'), ); /** * Access control for update.php script. * * If you are updating your Drupal installation using * are not logged in using either an account with the * updates" permission or the site maintenance account * created during installation), you will need
  • 65. Copyright © 2011 LOGTEL Deployment: Volumes apiVersion: extensions/v1beta1 kind: Deployment spec: replicas: 2 template: spec: containers: - name: drupal image: cr.io/repo/mydrupal:v1 ports: containerPort: 80 volumeMounts: - name: my-drupal-volume mountPath: /drupal- 7.56/sites/files volumes: - name: my-drupal-volume azureFile: secretName: azure-storage- secret shareName: <pre-existing-file-  Manages networked drives across containers and VM’s  volumeMounts sets the mount path and references a named volume  Volumes can be defined as  Pre-created named volumes  Dynamically provisioned Persistent Volume Claims 65
  • 66. Copyright © 2011 LOGTEL 66 The end ;-) Samuel.dratwa@gmail.com
  • 67. Copyright © 2011 LOGTEL 67
  • 68. Copyright © 2011 LOGTEL 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 68
  • 69. Azure App Service Quickly build, deploy, and scale web apps Preview - now supports Windows Server containers
  • 71. Fundamentals of Windows containers and Windows container-based web apps on Azure App Service
  • 72. Azure Container Instances (ACI) THR2206 - Run a serverless Kubernetes cluster by bridging AKS and ACI through the Virtual-Kubelet
  • 73. Azure Kubernetes Service (AKS) Fully managed Kubernetes orchestration service Auto patching, auto scaling, auto updates Use the full Kubernetes ecosystem (100% upstream) Deeply integrated with Azure Dev Tools and services
  • 74. Service Fabric Windows and Linux Containers Stateless and stateful microservices Deploy on Azure, Azure Stack and on-premises
  • 75. Service Fabric Mesh Fully managed microservices platform, built on Service Fabric Windows and Linux Containers
  • 76. Optimizing for microservice development Tracking multiple deployment pipelines while maintaining agile updates Focusing on business logic instead of microservice platform maintenance Dealing with the complexity of network communications Monitoring and governance at overarching and granular levels Achieving reliable state and data consistency without latency issues Running highly secure applications at scale </> .NET </>
  • 77. Optimizing for microservice development Tracking multiple deployment pipelines while maintaining agile updates Focusing on business logic instead of microservice platform maintenance Dealing with the complexity of interactions and network communications Monitoring and governance at overarching and granular levels Achieving reliable state and data consistency without latency issues Running highly secure applications at scale Build Deploy Operate Flexible infrastructure Lifecycle managemen t 24/7 availability & performance Elastic scalabilit y Microservice and container orchestratio n Security & complianc e Health & monitorin g Challenges </> Azure Service Fabric .NET </> Build and deploy containers and microservices on Windows and Linux, at any scale, on any cloud
  • 78. Programming Models Dev & Ops Tooling Orchestration Lifecycle Management Health & Monitoring Always On Availability Auto Scaling AzureOn-premises infrastructureAny cloudDev machine Service Fabric: cloud application platform Build OperateDeploy
  • 79. Azure Service Fabric offerings Bring your own infrastructure Service Fabric Standalone On-premisesAny cloud Dev machine Dedicated Azure clusters Azure Service Fabric Azure Service Fabric Mesh Serverless microservices Service Fabric Full Control Fully managed
  • 80. Azure Service Fabric offerings Bring your own infrastructure Service Fabric Standalone On-premisesAny cloud Dev machine Dedicated Azure clusters Azure Service Fabric Azure Service Fabric Mesh Serverless microservices Virtual machines OS patching Runtime upgrades Capacity planning Network and storage Micro-billing App deployment You Azure Responsibility Cluster capacity Network and storage App deployment Virtual machines OS patching Runtime upgrades Hardware OS patching Runtime upgrades Cluster capacity Network and storage App deployment
  • 81. Migrate existing applications as-is to the cloud, including using containers, to reduce cost and enable DevOps deployments New applications conceived and built with the cloud in mind using microservices architecture
  • 82. Azure Service Fabric is designed for mission-critical services Power BI Dynamic s365 Intune Cortana Skype for business Cosmos DB IoT Hub Event Hub SQL Database Azure Monitor Core Azure Services Archive Storage Visual Studio Team Services Stream Analytics Azure Database for PostgreSQL Azure Database for MySQL Azure Container Registry Event Grid

Hinweis der Redaktion

  1. https://rawgit.com/kubernetes/dashboard/master/src/deploy/kubernetes-dashboard.yaml
  2. https://kubernetes.io/
  3. https://github.com/kubernetes/kubernetes.github.io/blob/master/docs/user-guide/pods/pod-spec-common.yaml
  4. It’s important to note that the containers run on VMs in (most) public clouds, which is why node auto-scaling is important. I would expect Azure to eventually provide node auto-scaling. Examples of Kubernetes as a service: StackPointCloud (which is what I tried) and the new KUBE2GO (“Run Kubernetes Anywhere. Instantly. Free.”).
  5. Source: https://azure.microsoft.com/en-us/blog/new-windows-server-containers-and-azure-support-for-docker/
  6. Firewall image licensed through Creative Commons license
  7. While the Pod is the atomic unit of the Kubernetes resource model, you’ll almost never deal with Pods directly. Instead we use deployments. A Deployment is effectively a dynamic set of pods with replication control and rollout management. The core of a Deployment is actually a Pod spec. As you can see here we have defined a single container in our pod, specifying an image stored in private container registry. Additionally we specified the credentials for accessing the container registry using a Kubernetes secret. This allows us to keep credentials out of source control but still keep them secure and available for our application. Finally a Deployment allows us to specify how many copies of a Pod should be running at a time. Having a fixed number of replicas is useful, but the real strength of an orchestration tool is in dynamic scailing.
  8. Autoscaling really is the ultimate promise of cloud hosting—elastic databases, elastic storage, and now, elasticity for you application Kubernetes provides auto-scaling via a Horizontal Pod Auto-scaler. Kubernetes tracks CPU utilization of the agent nodes and responds by scaling the replica set up or down. In this example we have created a pod autoscaler for our Drupal deployment. The auto scaler acts on any kubernetes resources matching the attributes in the target reference. So here we’re targeting any deployment resource with the name “drupal”. And instructing kubernetes to schedule an additional pod every time CPU utilization exceeds 50%, up to 10 copies. Right now, kubernetes core only supports CPU utilization as a trigger, but other measures are available as add-ons. But a word of caution. Pod autoscaling is not the same as scaling your VM set. That functionality is available as add-ons for GCE and AWS.
  9. At this point we have anywhere between 2 and 10 copies of our Drupal pod running on at most as many nodes. We need a way to direct traffic to the correct nodes, and once there, to the correct container. This is where a service comes in. Just like the autoscaler, a service targets resources based on metadata. Here we target our drupal pods, specifying port 80 And finally, instruct kubernetes to provision an elastic load balancer from the cloud provider, configuring all the rules necessary to load balance across the set of nodes. This gets us external access to our loadbalacned drupal cluster via a dynamically provisioned IP on the load balancer, as well as including the service name in the Kubernetes cluster-internal DNS service. In this case, “drupal” becomes a valid hostname for any pod in the cluster, allowing us to, say, trigger cron from another pod without knowing which nodes the drupal pods are running on.
  10. Another use for Kubernetes service discovery is providing DNS resolution for external services. The most common use for a Drupal application would be accessing a Relational Database Service. With this configuration, drupal can access the database with the hostname `mysql-service`. First off, databases. They’re crucial part of any Drupal site, and it’s tempting to go ahead and add MySQL to your cluster But, when it comes to persisting data, nothing is simple Kubernets provides the building blocks to run a stateful set of pods But it comes down to individual cloud provider support if the data disk can be reliably identified by kubernetes and consistently attached. In our experience, whenever possible, use the Relational Database Server provided by your cloud host
  11. http://omerio.com/2016/01/02/getting-started-with-kubernetes-on-google-container-engine/
  12. 74