title	Kubernetes

Kubernetes

Ivan Velichko has lots of great posts on containers & k8s. Beetle & Infra are neat.

Kube-Hetzner is nice as Hetzner has cheap servers. GKE has nicest hosted Kubernetes experience.

Acorn is useful.

Notes

Kubernetes runs pods that contain 1 to n docker containers. So if you have your apps in the form of docker images you are ready to go.
The OpenShift guys like to make the analogy that Kubernetes is like Linux and that there are different distributions of it, OpenShift being one (like Red Hat).
Interacting with kubernetes feels very different and in a lot of ways it's almost an operating system for a super computer. You sort of forget how many computers and vms or whatever are out there and kubernetes handles a lot of the implementation details for you. Installing a lot of apps to the cloud is as simple as typing 'helm install jenkins' and waiting 5 minutes.
- It's just a radically new way of dealing with 'the cloud'. And the thing that makes it especially threatening to aws is that it doesn't matter where it runs. Developing an app for kubernetes on aws or google cloud or azure or anything else is almost an identical experience. People are going to become very price sensitive because that's the only thing that distinguishes one kubernetes host from another (aside from the ease of installing a kubernetes cluster -- something which aws is fairly far behind on)
In general, the right question to ask yourself when designing Pods is, “Will these containers work correctly if they land on different machines?” If the answer is “no,” a Pod is the correct grouping for the containers. If the answer is “yes,” multiple Pods is probably the correct solution.
Ingress controller watches for Ingress resources in your cluster.
Kubernetes (or whatever other container scheduler) might feel like overkill, but if all they do is force you to adopt a container-centric / 12-factor way of building your applications it was worth trying them. And once you've adopted that workflow it's a no-brainer to go from a single node to a cluster which will dynamically allocate the workloads it runs.
- Running a small container cluster at work has even changed how I setup single-host projects in my spare time: I will build everything into a container, bind-mount whatever it might need, create a simple systemd unit that just runs / rms the docker container on start and stop. Bliss.
After a couple years on kubernetes, there is a simple joy to a deployment process that looks like "scp binary server: && ssh server systemctl restart service", and takes 5s to complete.
In K8S, I think the best is hand-on experience, do it and. you will understand why a certain thing has to do that way.
Despite its reputation, Kubernetes is actually quite easy to master for simple use cases. And affordable enough for more complex ones. The fundamental abstractions are as simple as they can be, representing concepts that you'd already be familiar with in a datacenter environment. A cluster has nodes (machines), and you can run multiple pods (which is the smallest deployable unit on the cluster) on each node. A pod runs various types of workloads such as web services, daemons, jobs and recurring jobs which are made available (to the cluster) as docker/container images. You can attach various types of storage to pods, front your services with load-balancers etc. All of the nouns in the previous paragraph are available as building blocks in Kubernetes. You build your complex system declaratively from these simpler parts.
Can edit a deployment or pod via kubectl edit and update the command to be tail -f /dev/null

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Kubernetes

Notes

Links

FilesExpand file tree

kubernetes.md

Latest commit

History

kubernetes.md

File metadata and controls

Kubernetes

Notes

Links