Slideshare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our User Agreement and Privacy Policy.

Slideshare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our Privacy Policy and User Agreement for details.

Matthew Mark Miller is an engineer with 17 years experience designing scalable back-end systems. He is on the Kismatic team at Apprenda of Troy, New York, bringing Kubernetes to the enterprise. He loves helping engineers solve system problems, wrangle migrations, test the untestable, work with legacy code and anything else that’s truly hard in software.

3.
Purpose of QCon
- to empower software development by facilitating the spread of
knowledge and innovation
Strategy
- practitioner-driven conference designed for YOU: influencers of
change and innovation in your teams
- speakers and topics driving the evolution and innovation
- connecting and catalyzing the influencers and innovators
Highlights
- attended by more than 12,000 delegates since 2007
- held in 9 cities worldwide
Presented at QCon San Francisco
www.qconsf.com

4.
Cloud Native:
Microservices running inside
Containers on top of
Platforms on any infrastructure

5.
Microservice
A software component of a system that is independently
releasable and independently scalable from other parts of the
system.

6.
Container
A software process whose access has been reduced to the
point that it thinks it is the only thing running.

13.
Integrating this way isn’t easy
Takes time & testing to get it right
What you built and tested isn’t necessarily what
runs in production.
Leads to providers offering fewer, more highly
opinionated stacks

14.
A big question for platform
engineers:
How can we spend more time building useful
services and less time maintaining the platform?

20.
Controllers
Loops that maintain state
Run continuously on Master
Each Kubernetes object gets
its own Controller
Controllers are pluggable &
lightweight
Rely on declarative manifests
to determine intent

21.
The Pod
Many containers, working together as a single unit
Shared IP & localhost
Shared filesystem
Scale together
Separate hardware limits
Can be tagged with a label,
providing scheduling advice

22.
Services
Permanent, logical addresses for internal services
Expose a name, port and stable IP for a
group of pods
Load balance between individual pods
Provided to pods via DNS or
environment variable
Constructed using a selector onto pod
labels (sort of like a database query)

23.
Networking
Rules for all Kubernetes installations
Each Pod gets its own unique IP
address (which is the same outside and
in)
All Pods must be able to communicate
with each other without NAT
All Pods must be able to communicate
with and participate in Services

49.
Get hip to the heptagon
A platform is a real developer advantage but must avoid reinvention and being
overly proscriptive.
Kubernetes was built to bring independence from hardware choices.
Kubernetes also brings separation of concerns to dev teams.
It’s built from simple rules and objects that improve the usefulness and portability
of containers.