Natively clouded Journey

FullStack Developers IL
A “NATIVELY CLOUD” JOURNEY
UP AND RUNNING WITH KUBERNETES
Haggai Philip Zagury | DevOps Group & Tech Lead @ Tikal Knowledge

Tikal Knowledge
TIKAL INTRO
WHO WE ARE ?
▸ Tikal helps ISV’s in Israel & abroad in their technological
challenges.
▸ Our Engineers are Fullstack Developers with expertise in
Android, DevOps, Java, JS, Python, ML
▸ We are passionate about technology and specialise in
OpenSource technologies.
▸ Our Tech and Group leaders help establish & enhance
existing software teams with innovative & creative
thinking.
https://www.meetup.com/full-stack-developer-il/

Tikal Knowledge
TIKAL INTRO
FULLSTACK TECH RADAR DAY
▸ 15.5.2019
▸ Technological tracks
▸ Android
▸ DevOps
▸ Frontend
▸ Backend
▸ ML

FullStack Developers Israel
SELF INTRODUCTION
▸ My open thinking and open techniques
ideology is driven by Open Source
technologies and the collaborative manner
deﬁning my M.O.
▸ My solution driven approach is strongly
based on hands-on and deep understanding
of Operating Systems, Applications stacks
and Software languages, Networking, Cloud
in general and today more an more Cloud
Native solutions.
▸ Technologies:
▸ Linux { just pick a ﬂavour …}
▸ *Scripting
▸ Git
▸ Python/Go
▸ Cloud { public/private/hybrid }
▸ Docker
▸ Kubernetes 
HAGGAI PHILIP ZAGURY - DEVOPS ARCHITECT AND GROUP TECH LEAD

UP AND RUNNING WITH KUBERNETES
WHICH PATH TO CHOOSE ?
▸ 3 years ago, it was kubeadm and that’s it !
▸ No KaaS
▸ Steep learning curve [ ! || ? ]
▸ OnPrem / OnCloud / Hybrid Cloud
▸ Co-exist alongside existing Infra, migration path
▸ is k8s ready for production ?
▸ k8s alone isn’t enough -> k8s ecosystem

Tikal Knowledge
KUBERNETES - HOW TO APPROACH?
I ASKED MYSELF IN RETROSPECTIVE … HOW TO MASTER KUBERNETES [IMHO] ?
▸ A few motivating quotes …
▸ Life is really simple, but we
insist on making it complicated.
▸ If you see with innocent eyes,
everything is divine.
▸ KISS - Keep It Stupid Simple !

Tikal Knowledge
WHATAPPROACHTOTAKE?

Tikal Knowledge
TOP DOWN - APPLICATION ASPECT
▸ Namespace
▸ Service
▸ Deployment
▸ StatefulSet
▸ Replication controller
▸ …
▸ … a.k.a The Application Aspect
| https://github.com/octo-technology/kubernetes-icons |

Tikal Knowledge
BOTTOM UP - THE INFRASTRUCTURE APPROACH
K8s API Server: Kubernetes API.
Scheduler: In charge of ensuring Pods
placement.
Controller Manager: Kubernetes
controller manager.
Cloud Controller Manager: Optional
and External Cloud controller
(experimental).
Kubelet: The kubelet is the primary
“node agent” that runs on each node.
Kube-proxy: The Kubernetes network proxy runs on each node. This
reflects services as defined in the Kubernetes API on each node.
Node: Worker machine in Kubernetes
cluster.
Master: Kubernetes Control Plane.
ETCD: Kubernetes’s backing store.
a.k.a The Infrastructure Aspect
| https://github.com/octo-technology/kubernetes-icons |

Tikal Knowledge
SO WHICH ONE IS IT ?
WHATAPPROACHTOTAKE?

Tikal Knowledge
THE SHORT ANSWER:
▸ Both (eventually …)

Tikal Knowledge
THE SHORT ANSWER:
▸ newbie

Tikal Knowledge
THE SHORT ANSWER:
▸ newbie vs. veteran

Tikal Knowledge
THE SHORT ANSWER:
▸ How well do you know:
▸ Linux

Tikal Knowledge
THE SHORT ANSWER:
▸ Linux
▸ Networking

Tikal Knowledge
THE SHORT ANSWER:
▸ Linux
▸ Networking
▸ Containers

Tikal Knowledge
THE SHORT ANSWER:
▸ Linux
▸ Networking
▸ Containers
▸ Experience

Tikal Knowledge
KUBERNETES 101 | THE APPLICATION ASPECT
GETTING STARTED …
▸ You have an application
▸ Hopefully a micro service (not a wannabe)
▸ Containerised and ready for deployment

Tikal Knowledge
CONTAINERS ON K8S … RUNNING YOUR FIRST APP
▸ Containerised and ready for deployment
▸ It matures enough for kubernetes …

Tikal Knowledge
KUBERNETES 101 | GETTING STARTED
AND START DEPLOYING MICRO SERVICES
demo-app

Tikal Knowledge
MICRO SERVICES WRAPPED BY DEPLOYMENT RESOURCE DEFINITION
demo-app

Tikal Knowledge
MICRO SERVICES IN CONTAINERS NEED DEPLOYMENTS
demo-app

Tikal Knowledge
demo-app
demo-app.default

Tikal Knowledge
demo-app
demo-app.default.cluster.local

Tikal Knowledge
kubectl - “the new shell”
▸ docker run -d --name demo-app shelleg/demo-nodejs-http-server
▸ kubectl run —-expose —-image=shelleg/demo-nodejs-http-server  
--port=8080 demo-app 
 
deployment.apps "demo-app" created
▸ kubectl get pod 
NAME READY STATUS RESTARTS AGE 
demo-app-5656cc6f5-84d5t 1/1 Running 0 1m

KNOWING NOTHIN’ WE JUST CREATED 5 RESOURCE DEFINITIONS …
▸ kubectl get --export deployment demo-app
-o yaml > demo-app-deployment.yaml
1 apiVersion: extensions/v1beta1
2 kind: Deployment
3 metadata:
4 annotations:
5 deployment.kubernetes.io/revision: "1"
6 creationTimestamp: null
7 generation: 1
8 labels:
9 run: demo-app
10 name: demo-app
11 selfLink: /apis/extensions/v1beta1/namespaces/default/deployments/demo-app
12
29
30
Label

EXPORT AN APP DEFINITION
▸ kubectl get --export deployment demo-app -o
yaml > demo-app-deployment.yaml
12 spec:
13 replicas: 2
14 selector:
15 matchLabels:
16 run: demo-app
17 strategy:
18 rollingUpdate:
19 maxSurge: 1
20 maxUnavailable: 1
21 type: RollingUpdate
Proportional scaling !
Scale
Z
scale strategy
Replication Controller

22 template:
23 metadata:
25 labels:
26 run: demo-app
Label
Label
Label
Label
Label
Labels Labels Labels

27 spec:
28 containers:
29 - image: shelleg/demo-nodejs-http-server
30 imagePullPolicy: Always
31 name: demo-app
32 ports:
33 - containerPort: 8080
34 protocol: TCP
35 resources: {}
36 terminationMessagePath: /dev/termination-log
37 terminationMessagePolicy: File
38 dnsPolicy: ClusterFirst
39 restartPolicy: Always
40 schedulerName: default-scheduler
41 securityContext: {}
42 terminationGracePeriodSeconds: 30
43 status: {}
Label
Label
Label
Label

EXPORT OUR SERVICE DEFINITION
1 apiVersion: v1
2 kind: Service
3 metadata:
5 labels:
6 run: demo-app
7 name: demo-app
8 selfLink: /api/v1/namespaces/default/services/demo-app
9 spec:
10 externalTrafficPolicy: Cluster
11 ports:
12 - port: 80
13 protocol: TCP
14 targetPort: 8080
15 selector:
16 run: demo-app
17 sessionAffinity: None
18 type: NodePort
19 status:
20 loadBalancer: {}
▸ kubectl get service demo-app --export -o
yaml > demo-app-service.yaml
Label
Label
Label
Label

SERVICES & LINUX NETWORKING
▸ Internal Service -> ClusterIP
▸ Cluster (using cluster machines ip
address accessible wide service ->
NodePort
▸ LoadBalancer -> User CCM (Cloud
Control Manager to provision a
LoadBalancer and attach to
NodePorts

KUBERNETES 101 | WORKING WITH SERVICES
UNDERSTANDING KUBERNETES “OVERLAY” NETWORKING
An overlay network is a computer network that
is built on top of another network. Nodes in the
overlay network can be thought of as being
connected by virtual or logical links, each of
which corresponds to a path, perhaps through
many physical links, in the underlying network.
For example, distributed systems such as peer-
to-peer networks and client-server applications
are overlay networks because their nodes run
on top of the Internet.
Network Carier Layer
Service Provider Layer
User Controlled Layer
Overlay

“Docker” Networking
‣ eth0 routes all trafﬁc from outside to host
‣ docker0(br0) routes all trafﬁc to container through
host via iptables rules { a.k.a NAT rules }
‣ Doesn’t (not designed to scale) in multi-host need
the router’s awareness for the inner host networking !
172.17.0.1 { route 172.17.0.0 br0 }docker0
172.17.0.2
veth0
192.168.1.3eth0
172.17.0.2
veth1
192.168.1.1router
docker-machine

Docker/Container Networking == Networking
‣ eth0 routes all traffic from outside to host
‣ docker0(br0) routes all traffic to container through
host via iptables rules { a.k.a NAT rules }
‣ Doesn’t (not designed to scale) in multi-host need
the router’s awareness for the inner host networking !
‣ Enter:
‣ Software Defined Networking:
‣ Router doesn’t know (can’t route) 172.17.0.2 … but
you can change the CIDR on one of the hosts and
update the routing table …
192.168.1.1router
172.17.0.1 { route 172.17.0.0 br0 }docker0
172.17.0.2
veth0
192.168.1.2eth0
172.17.0.2
veth1
swarm-node
172.17.0.1 { route 172.17.0.0 br0 }docker0
172.17.0.2
veth0
192.168.1.3eth0
172.17.0.2
veth1
k8s-node

Multi-Host Networking
10.0.1.1 { route 172.17.0.0 br0 }$br0
10.0.1.2
veth0
192.168.1.2eth0
10.0.1.3
veth1
172.17.0.1 { route 172.17.0.0 br0 }$br0
10.0.1.2
veth0
192.168.1.3eth0
10.0.1.3
veth1
192.168.1.1router
0.0.0.0 default gw
10.0.1.0/24 192.168.1.2/32
10.0.2.0/24 192.168.1.3/32
Common
Networking
Interface
+ 
extend via

ClusterIP
10.10.10.310.10.10.2 10.10.10.4
172.17.0.2 172.17.2.2
default
api admin
172.17.1.2
172.17.2.3
admin service
api.default.cluster.local IN A 172.17.0.2 …. 172.17.2.2
admin.default.cluster.local IN A 172.17.1.2 …. 172.17.2.3
api service
‣ Inner cluster service discovery
only (* via kube-proxy)
‣ The service represents an entry
in the DNS pointing to it’s
members
‣ In the same name space (e.g
default) pod admin can
resolve api and get it’s ip
address
‣ Between namespaces it well be
<svc_name>.<ns_name>.cluster.local

NodePort
10.10.10.310.10.10.2 10.10.10.4
172.17.0.2 172.17.2.2
default
api admin
172.17.1.2
172.17.2.3
api service 30000:8080
admin service 30001:8080
30000
30001
30000
30001
30000
30001
$ service NodePort:PodPort $.$ns. .cluster.local IN A 172.17.$.2 …. 172.17.$.3
api.example.com
admin.example.com
‣ A port (the same port per service) is
allocated on each node in the cluster for
that named service
‣ An external LoadBalancer / ESB can
map a NLB (Network Load Balancer) to it
<SourcePort>:<node1:port,node2:por
t,node3:port>
‣ The service represents an entry in the
DNS pointing to it’s members
‣ In the same name space (e.g default)
pod admin can resolve api and get it’s
ip address

LoadBalancer
{ }
10.10.10.310.10.10.2 10.10.10.4
172.17.0.2 172.17.2.2
default
api admin
172.17.1.2
172.17.2.3
api service 30000:8080
admin service 30001:8080
30000
30001
30000
30001
30000
30001
$ service NodePort:PodPort $.$ns. .cluster.local IN A 172.17.$.2 …. 172.17.$.3
api.example.com
admin.example.com
‣ A port (the same port per service) is
allocated on each node in the cluster for
that named service
‣ An external LoadBalancer / ESB can
map a NLB (Network Load Balancer) to it
<SourcePort>:<node1:port,node2:por
t,node3:port>
‣ The service represents an entry in the
DNS pointing to it’s members
‣ In the same name space (e.g default)
pod admin can resolve api and get it’s
ip address

IT MAY LOOK LIKE
Label
Label
Label
Label
5656cc6f5 demo-app
84d5t
service port
service name
FQDN

KUBERNETES 101 | THE APPLICATION ASPECT There are no miracles !

CONTROL LOOP …
‣ Kubernetes receives a resource deﬁnition
request …
‣ A desired state is recorded
‣ Kubernetes challenges the current state to
verify it meets the desired state !

▸ A set of containers [ 1 or more ]
▸ Shared network namespace (all pod
members communicate in localhost)
▸ Share volumes (for persistence)
▸ Pod containers are Scheduled on the
same machine
▸ demo-app
▸ demo-app.default
▸ 10.98.55.147
▸ optional: attached volume
IT’S ALL ABOUT THE POD

MOVING PARTS …
‣ A monolith broken down to micro
services -> straight to kubernetes …
‣ messaging & event driven
‣ immutable yet persistent
credit link

CLOUD NATIVE KICKS IN …
‣ With a distributed system we cannot
process without centralised logging
and monitoring
‣ Communication/Networking is a
big issue …
‣ Piles of Yaml ﬁles deﬁning our
deployments doesn’t scale …

Tikal Knowledge
CONTAINERS ON K8S CLUSTER(S)…
▸ It matures enough for kubernetes …
▸ You need scale/elasticity …
▸ Now what ?!

Tikal Knowledge
w/o{ }
YOU SETUP A CLUSTER …
Kubeadm + { }
kubernetes is hard,

Tikal Knowledge
w/o{ }
YOU SETUP A CLUSTER …
Kubeadm + { }
kubernetes is hard, less frightening ;)

Tikal Knowledge
KUBERNETES | THE APPLICATION ASPECT
TOP DOWN
▸ You understand the chain of commands as
you go along …
▸ kubectl get s**t done !

Tikal Knowledge
KUBERNETES | THE APPLICATION ASPECT
BOTTOM UP
▸ You ﬁrst master then challenge the chain of
commands as you go along …
▸ Design cluster spec
▸ Setup resource groups
▸ Deﬁne Network Policies
▸ Integrate with cloud native add-ons
▸ … topics for another meet up

Tikal KnowledgeTikal Knowledge
KUBERNETES ARCHITECTURE

ODD # OF MASTERS

ODD # OF MASTERS
Service
Deployment
PO
Replica Set
Namespace
RBA

Tikal Knowledge
K8S IS THE AMPLIFIER OF LINUX
https://www.infoworld.com/article/3322120/kubernetes/sorry-linux-kubernetes-is-now-the-os-that-matters.html

Haggai Philip Zagury |
DevOps Group & Tech Lead @ Tikal Knowledge

Natively clouded Journey

Natively clouded Journey

More Related Content

What's hot

Similar to Natively clouded Journey

More from Haggai Philip Zagury

Recently uploaded

Natively clouded Journey