Deploying Kubernetes in the Enterprise (IBM #Think2019 #7678 Tech Talk)

Let's Talk Deploying Kubernetes in the
Enterprise
—
Jake Kitchener
IBM
Michael Elder
IBM
Dr. Brad Topol
IBM
Think 2019 / IKS and Istio / Feb 17, 2019 / © 2019 IBM Corporation

IBM’s statementsregarding itsplans, directions, andintent are subject to change or withdrawal without
notice andat IBM’s sole discretion.
Information regarding potential future productsisintended to outline our general product direction andit
should not be reliedon in making a purchasing decision.
The information mentionedregarding potential future productsisnot a commitment, promise, or legal
obligation to deliver any material, code or functionality. Information about potential future productsmaynot
be incorporatedinto any contract.
The development, release, and timing of anyfuture featuresor functionalitydescribedfor our products
remainsat our sole discretion.
Performance isbasedon measurementsandprojectionsusing standard IBM benchmarksin a controlled
environment. The actual throughput or performance that anyuser will experience will vary depending upon
manyfactors, including considerations such as the amount of multiprogramming in the user’sjobstream,
the I/O configuration, the storage configuration, andthe workloadprocessed. Therefore, no assurance can
be given that an individual user will achieve results similar to those statedhere.
2
Please note

3Think 2019 / IKS and Istio / Feb 17, 2019 / © 2019 IBM Corporation
Kubernetes Architecture
API
UI
CLI
Kubernetes
Master
Worker Node 1
Worker Node 2
Worker Node 3
Worker Node n
Registry
• Etcd
• API Server
• Controller Manager Server
• Scheduler ServerThink 2019 / IKS and Istio / Feb 17, 2019 / © 2019 IBM Corporation

Kubernetes Architecture
API
UI
CLI
Kubernetes
Master
Worker Node 1
Worker Node 2
Worker Node 3
Worker Node n
Registry
• Etcd
• API Server
• Controller Manager
Server
• Scheduler Server
Nodes – hosts that run
Kubernetes applications
Master nodes:
• Controls and manages the cluster
• Kubectl (command line)
• REST API (communication with workers)
• Schedulingand replication logic
Worker nodes:
• Hosts the K8s services
• Kubelet (K8s agent that accepts
commands from the master)
• Kubeproxy (network proxy service
responsible for routingactivities for
inbound or ingress traffic)
• Docker host

Kubernetes Pods
• Collection of application containers and volumes
running in the same execution environment
• Smallest deployable unit in a Kubernetes Cluster
• Applications in the same pod
• Share IP Address and port space
• Share the same hostname
• Can communicate usingnative IPC
• Can share mounted storage
• Applications in different pods
• Have different IP Addresses
• Have different hostnames
• Pods running on the same node might as well be on
different servers
• When designing pods ask, “Will these containers work
correctly if they land on different machines?”
Pod
Volumes
Containers
IP

Features Provided by
Kubernetes Pods
• Creating, Listing, Deleting Pods
• Run commands in your pod’s
containers with exec
• Copy files to and from containers in
your pods
• Port forwarding from your local
machine to your pod
• Liveness Probes
• Readiness Probes
• Persistent Volume Storage
Create the yaml file specification of your pod
$ vi nginx_pod.yaml
apiVersion: v1
kind: Pod
metadata:
name: nginx
spec:
containers:
- name: nginx
image: nginx:1.7.9
ports:
- containerPort: 80
Create the nginx pod using kubectl
$ kubectl create -f nginx_pod.yaml

Kubernetes Deployments
• Kubernetes Deployments manage the release of
new versions
• Enable you to easily move from one version of
your code to the next version
• Rollouts easily done without downtime
• Health checks used to ensure new version
is operating correctly
• Runs server side
• Safe to kick off from a plane
• Most Deployments use ReplicaSets to provide
availability and rolling update capabilities
• Pods managed by ReplicaSets are
automatically rescheduled under failure
conditions
$ vi nginxdeployment.yaml
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
annotations:
deployment.kubernetes.io/revision: “1”
name: nginx
labels:
app: nginx
spec:
replicas: 3
selector:
matchLabels:
app: nginx
strategy:
rollingUpdate:
maxSurge: 1
maxUnavailable: 1
type: RollingUpdate
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.7.9
ports:
- containerPort: 80
Create the nginx deployment
$ kubectl create -f nginxdeployment.yaml

Kubernetes ReplicaSets
• Kubernetes ReplicaSet is a cluster-wide pod
manager that ensures the proper number of pods
are runningat all times.
• Pods managed by ReplicaSets are automatically
rescheduled under failure conditions
• ReplicaSets are defined via a specification
• Contains name, number of pods, and pod
template
• ReplicaSets identify their replicas via a set of Pod
labels
Create the yaml file specification of your ReplicaSet
$ vi frontend.yaml
apiVersion: apps/v1
kind: ReplicaSet
metadata:
name: frontend
labels:
app: guestbook
tier: frontend
spec:
# this replicas value is default
# modify it according to your case
replicas: 3
selector:
matchLabels:
tier: frontend
matchExpressions:
- {key: tier, operator: In, values: [frontend]}
template:
metadata:
labels:
app: guestbook
tier: frontend
spec:
containers:
- name: php-redis
image: gcr.io/google_samples/gb-frontend:v3
ports:
- containerPort: 80
Create the nginx pod using kubectl
$ kubectl create -f frontend.yaml
Replica Set vN
Replica Set N-1

Kubernetes Service Object
• Kubernetes Service is essentially a load balancer
for a group of replica pods
• Service is assigned a virtual IP called a cluster
IP
• This IP address will load balance across all of
the pods identified by the service’s selector
• Cluster IP Addresses are stable and
appropriate for givingit an IP Address
• Kubernetes provides a DNS service
exposed to Pods running in the cluster
• Readiness checks are built in
• Only ready pods are sent traffic
Create an nginx deployment with 3 replicas
$ kubectl run hazelcast --image=nginx
--replicas=3 --labels="app=hazelcast,env=prod,ver=2”
Create a service for an nginx deployment, which
serves on port 80 and connects to the containers
on port 8000.
$ kubectl expose deployment hazelcast –port=80 –target-
port=8000

Scale a Kubernetes
Deployment
• Scaling a Kubernetes Deployment is very
straightforward
• Update the replicas value in your YAML
specification and use kubectl apply
• $ kubectl apply --f nginx
deployment.yaml
kind: Deployment
metadata:
annotations:
deployment.kubernetes.io/revision: “1”
name: nginx
labels:
app: nginx
spec:
replicas: 6
selector:
matchLabels:
app: nginx
strategy:
rollingUpdate:
maxSurge: 1
maxUnavailable: 1
type: RollingUpdate
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.7.9
ports:
- containerPort: 80
Update the nginx deployment
$ kubectl apply -f nginxdeployment.yaml

Kubernetes Deployment:
Update a
Container Image
• Scaling a Kubernetes Deployment is very straightforward
• Update the image value in your YAML specification
• Add an annotation describing the change in your YAML
specification
• Update the deployment using kubectl apply
• $ kubectl apply --f nginx deployment.yaml
• Useful deployment commands
• kubectl rollout status deployments nginx
• kubectl rollout pause deployments nginx
• kubectl rollout resume deployments nginx
• kubectl rollout history deployment nginx
kind: Deployment
metadata:
annotations:
kubernetes.io/change-cause: “Update nginx to 1.9.10”
name: nginx
labels:
app: nginx
spec:
replicas: 6
selector:
matchLabels:
app: nginx
strategy:
rollingUpdate:
maxSurge: 1
maxUnavailable: 1
type: RollingUpdate
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.9.10
ports:
- containerPort: 80
Update the nginx deployment
$ kubectl apply -f nginxdeployment.yaml

Kubernetes Continuous
Delivery Fundamentals
• Small Batch Changes
• All changes should be incremental and finite
• Source Control all the things
• History of all changes to identify regressions in code or configurations
• Developer access to production-like environments
• Shift-left operational practices
• Expose behaviors for health management, log collection, and change
management earlier in the development process
• Continuous integration of changes
• All changes built and deployed together on an ongoing basis
• Highly automated testing/validation with continuous feedback

Kubernetes Networking
• Cluster (aka Pod) Networking
• Services/kube-proxy/Load Balancers
Ingress
kind: Ingress
metadata:
name: hello-ingress
spec:
rules:
- host: hello-app.com
http:
paths:
- path: /
backend:
serviceName: hello-svc
servicePort: 80
Network Security Policy
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-redis
namespace: teama
spec:
podSelector: {}
policyTypes:
- Egress
egress:
- to:
- ipBlock:
cidr: 10.10.126.48/28
ports:
- protocol: TCP
port: 6379

Kubernetes Storage
• Node Scope
• emptyDir
• hostPath
• local
• Cluster Scope
• PersistentVolume
• PersistentVolumeClaim
• Volume Plugins
Persistent Volume Claims
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: mypvc
labels:
billingType: "hourly"
region: us-south
zone: dal13
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 24Gi
storageClassName: ibmc-block-silver

Kubernetes User Security
• Authentication
• OIDC Tokens
• ServiceAccount Tokens
• Authorization
• RBAC
• Role
• RoleBinding
• ClusterRole
• ClusterRoleBinding
• Namespaces
• Help to scope access control to a set of
resources in a Kubernetes cluster
---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRole
metadata:
name: viewer
rules:
- apiGroups:
- apps
- extensions
resources:
- deployments
- replicasets
verbs:
- get
- list
- watch
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: cicd-viewer
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: viewer
subjects:
- kind: User
name: IAM#cicd@us.ibm.com
apiGroup: rbac.authorization.k8s.io

Kubernetes Auto-Scaling
• Kubernetes schedulingbased on user provided
resources requests
• Critical for proper scheduling and performance
• Autoscaling tools allow for apps to manage their
own capacity and play by scheduling rules
• Horizontal Pod (demo)
• Vertical Pod
• Cluster Proportional
• Addon-resizer
$ kubectl run hello-app --image=kitch/hello-app:1.0 --
requests='cpu=18m,memory=50Mi' --replicas 3
deployment.apps "hello-app" created
$ kubectl expose deploy hello-app --name hello-svc --
port=80 --target-port=8080
service "hello-svc" exposed
$ kubectl autoscale deploy hello-app --min=1 --max=10 -
-cpu-percent=80
deployment.apps "hello-app" autoscaled
$ kubectl run hello-load --image=alpine --command -- sh
-c 'apk update && apk add curl && while true; do curl
hello-svc; done'
deployment.apps "hello-load" created

Thank you
Jake Kitchener
SeniorTechnicalStaff Member
IBM Cloud Kubernetes Service
@kitch
—
jakek@us.ibm.com
MichaelElder
Distinguished Engineer
IBM Cloud Private
@mdelder
—
mdelder@us.ibm.com
Dr. Brad Topol
Distinguished Engineer
Open Technology & DeveloperAdvocacy
@bradtopol
—
btopol@us.ibm.com

19
®

Deploying Kubernetes in the Enterprise (IBM #Think2019 #7678 Tech Talk)

More Related Content

What's hot (20)

Similar to Deploying Kubernetes in the Enterprise (IBM #Think2019 #7678 Tech Talk) (20)

More from Michael Elder (14)

Recently uploaded (20)

Deploying Kubernetes in the Enterprise (IBM #Think2019 #7678 Tech Talk)