Notes Kubernetes Best Practices Youtube Series

June 29, 2018   

My notes on the (“Kubernetes Best Practices Youtube Series”)[https://www.youtube.com/playlist?list=PLIivdWyY5sqL3xfXz5xJvwzFW_tlQB_GB]

Video 1: Building Small Containers

Default base images are too large and have many security issues. They are fine for onboarding but you should use a smaller container in production.

Option One - Build with the minimized base images (alpine)

Likely your langauge or stack provides a base image that is smaller then the default image.

For example using the node8:alpine image is very small a few dozen MB.

You can also build from scratch on alpine.

Option Two - Builder Pattern

Strip build tools from the container.

The code is built in the first container and the artifacts are extracted and loaded into into a runtime image:

Example:

# FRIST we BUILD the applcition, notice the 'build-env'
FROM glang:alpine AS build-env
WORKDIR /app
ADD . /app
RUN cd /app && go build -o goapp

# SECOND FROM we are pulling in another image, note that alpine by
# default lacks certificates so we need to get them since we're assuming
# this is a webapp
FROM alpine
RUN apk update && apk add ca-certificates && rm -rf /var/cache/apk/*
WORKDIR /app
COPY --from=build-env /app/goapp /app  # copys the goapp bin from the build container to this image

EXPOSE 8080
ENTRYPOINT ./goapp

What are the measurable advantage of small containers? -> 50% time savings on pushing the container -> If you add a node (or one is replaced on failure) it will take 20% the time to pull smaller containers which will save you a lot of time -> Security - less stuff, less stuff to be insecure

Video 2: Organizating Kubernetes with namespaces

Use namespaces to keep things organized.

A namespace like a “virtual” cluster inside your kubernetes cluster.

Namespaces are isolated from each other… They sort of act like OU’s.

They can help with organization, security and performance.

Kubernetes comes with the the following default name spaces:

  • default - don’t use at all in large production systems, collisions between teams likely
  • kube-system - don’t touch its for the system
  • kube-public - not used for much

Creating a namespace: kubectl create namespace test

Get namespaces: kubectl get namepsaces

Creating Resources inside a namespace:

  • use –namepspace flag
  • add namspace: tag in the YAML

All commands are run in the current active namespace, you can switch your namespace with the ‘-n’ namespace command

Use kubens to set your namespace?

Services can talk between namespaces.