This document summarizes a presentation about abstracting application deployment using Kubernetes. It introduces Kubernetes concepts like pods, services, deployments and secrets. It explains how Kubernetes uses a desired state architecture with masters and nodes. It also provides an anatomy of a Kubernetes config file and discusses managing Kubernetes objects through imperative and declarative approaches. Finally, it outlines a non-exhaustive production readiness checklist for Kubernetes.

2. Women Who Code CONNECT 2018
Abstracting application
deployment using
kubernetes
Supriya Premkumar
Stanford Linear Accelerator
Center.

3. Who am I?
❖ Software Engineer @ Stanford
Linear Accelerator Center
❖ Work on all things infra
❖ Superpowers someday?
+
=
?

4. Evolution of “unit of management”
Machine Application
Increasing Application Complexity
Standalone Servers VMs Containers

5. Today’s application requirements - Pick All!
❖ Discovery/Load Balancing.
❖ (Auto)-Scaling.
❖ Self Healing.
❖ Rolling upgrade/downgrades
❖ Resource pinning/consolidation.
❖ Health monitoring.
❖ Secret Management.
❖ Underlying infrastructure
agnostic.
No more “Works on my machine!”

6. I think Kubernetes is basically…

7. Kubernetes concepts | Architecture
❖ Desired State Architecture. Object state stored in etcd.
❖ Master Node:
❖ kube-api-server:
❖ validate/configure data.
❖ kube-controller-manager:
❖ implements control or “are we there yet” loop.
❖ kube-scheduler:
❖ honors scheduling requirements.
❖ Non-Master Node:
❖ kubelet:
❖ ensures all managed containers are up and
running.
❖ kube-proxy:
❖ TCP/UDP proxy, does load balancing
3 Master, 5 Node k8s cluster

8. Kubernetes Concepts | Objects
❖ Pod:
❖ Basic unit of scheduling. Can have one or more containers. - a.k.a “ an instance” of your
application.
❖ Ephemeral.
❖ Service:
❖ Provide an abstraction over pods and a policy to access them.
❖ Volume:
❖ Since pods are ephemeral. The application instances may not be.
❖ Apps need access to a kind of `file system` to preserve state and share some of it with other pods.
❖ Namespace:
❖ Scoping isolation between different pods.
❖ Cluster-ception!

9. Kubernetes Concepts | Controller Objects
❖ ReplicaSet:
❖ You can say “I want X number of Y pods”
❖ Deployment:
❖ A higher level abstraction than ReplicaSet.
❖ Declarative app state. Controller moves the app to desired state.
❖ Manages replicas, supports roll over and roll back
❖ StatefulSet:
❖ Similar to deployment, but for stateful applications. Has strong pod affinity.
❖ Used for persistent storage, network resources, ordered scaling etc..
❖ DaemonSet:
❖ You can say “I want my pod to run on all the nodes”
❖ Used for “daemony” things like monitoring each node, collecting logs etc…
❖ As new nodes are added, daemon sets are automatically scheduled.
❖ Job:
❖ Used for run to completion/batch workloads.

10. Kubernetes Concepts | Labels & Selectors
❖ Labels:
❖ key-value metadata added to
objects.
❖ Selector:
❖ filter for labels with a certain
match criteria.
❖ And the force is eternal…

11. My view of Kubernetes Objects
pod, service, replica set, deployment

12. One missing piece…
❖ Secrets:
❖ Allows secure sharing of confidential data to apps
that need them.
❖ Auth Tokens, Keys and passwords, image pull
creds.
❖ Share the secrets as env variables or volumes.

13. Anatomy of a config file
❖ Use yamls to describe the
desired state.
❖ Kind: Object Type
❖ Name: Object Name
❖ Spec: Desired State. Specifies:
❖ container image.
❖ container ports
❖ replicas.
❖ labels & selectors.

14. Managing Kubernetes Objects
❖ Imperative Commands:
❖ “Do this right now.”
❖ Imperative With Config Files:
❖ “Do what is specified in this file.”
❖ Works on a set of config files, which can be version controlled.
❖ Suitable for prod.
❖ Config files as the single source of truth.
❖ Declarative with config directories recursively
❖ “Do everything that is specified in this directory”
❖ Harder to debug and understand how we got into this state.

15. A Non-Exhaustive Prod Ready Kubernetes Checklist
❖ Ensure standard code hygiene is maintained. Validate user input, use least privilege. a.k.a follow
OWASP Guidelines
❖ Validate your container image. Check for vulns and analyze image layers.
❖ Run non-privileged containers unless you absolutely sure that you need CAP_SYSADMIN on your
containers.
❖ Configure security context for your pod. Use seccomp and no_new_privs to automatically enforce
things.
❖ Lock down access to api server, Implement RBAC on your cluster, Have Auth&Auth configured
(correctly)
❖ Set Resource quotas for your workloads.
❖ Monitor and track valuable metrics. (both for cluster and your app.)
❖ Have a strong telemetry story.
❖ Since upgrading is so easy, don’t be afraid to roll out security patches.

16. “Lets see some of these in action!”