Po roce experimentování s Docker Swarm a Mesosem jsme se rozhodli vsadit na Kubernetes. Verze 1.5 přinesla StatefulSets (beta) a PodDisruptionBudgets, což jsou přesně věci, které jsme pro naše enterprise nasazení potřebovali.
Proč Kubernetes a ne Docker Swarm¶
Docker Swarm je jednoduchý. Příliš jednoduchý. Pro pár kontejnerů na jednom projektu je skvělý, ale jakmile potřebujete RBAC, namespace izolaci, vlastní scheduler nebo federation přes více clusterů, Swarm nestačí. A přesně tam jsme se dostali.
Kubernetes má strmější learning curve, to je fakt. Ale komunita kolem něj je obrovská — Google, Red Hat, CoreOS a desítky dalších firem do něj investují. To je pro nás důležitý signál stability. Nechceme stavět infrastrukturu na projektu, který za dva roky nikdo neudržuje.
Co přinesla verze 1.5¶
StatefulSets (beta). Dříve PetSets — konečně způsob, jak provozovat stateful workloady. Databáze, message brokery, Elasticsearch clustery. Každý pod dostane stabilní hostname a persistent volume. Pro nás klíčové — máme klienty, kteří potřebují PostgreSQL v clusteru.
PodDisruptionBudgets. Říkáte Kubernetes: „vždy musí běžet minimálně 2 repliky mého servisu.” Cluster pak při rolling update nebo node drain respektuje toto omezení. Konečně se dá dělat údržba bez výpadků.
Cluster Federation. Alpha, ale slibná. Představte si jeden kubectl příkaz, který nasadí aplikaci do clusterů v Praze a Frankfurtu. Pro disaster recovery a latency-based routing to bude game changer.
Naše testovací topologie¶
Rozjeli jsme tříuzlový cluster na bare metal serverech v naší serverovně. Tři mastery s etcd v HA režimu, tři worker nody. Networking přes Calico — potřebujeme network policies pro izolaci tenant prostředí.
$ kubectl get nodes
NAME STATUS AGE
master1 Ready 45d
master2 Ready 45d
master3 Ready 45d
worker1 Ready 44d
worker2 Ready 44d
worker3 Ready 44d
Instalace přes kubeadm — překvapivě bezbolestná. Dříve jsme zkoušeli manuální setup podle Kelsey Hightower’s „Kubernetes The Hard Way” a bylo to poučné, ale pro produkci chceme automatizaci.
První produkční workload¶
Jako pilotní projekt jsme zvolili interní monitoring stack — Prometheus + Grafana. Ideální kandidát: stateless (Grafana), semi-stateful (Prometheus s retention 30 dnů), a pokud spadne, nikdo nepřijde o peníze.
Deployment proběhl hladce. Helm chart pro Prometheus stacku fungoval téměř out of the box, jen jsme museli upravit storage class pro naše Ceph volumes. Grafana dashboardy jsme definovali jako ConfigMapy — infrastructure as code, jak má být.
Kde nás Kubernetes překvapil negativně¶
Debugging. Když něco nefunguje, musíte procházet logy kubelet, kube-proxy, kube-controller-manager, kube-scheduler… Tooling pro troubleshooting je zatím slabý. kubectl describe pod je váš nejlepší přítel, ale občas nestačí.
Resource management. Správně nastavit requests a limits je umění. Nastavíte moc nízké limits — OOM kill. Nastavíte moc vysoké — plýtváte resources.
Upgrades. Upgrade z 1.4 na 1.5 nebyl úplně triviální. etcd upgrade, API server flags se změnily. Zero-downtime upgrade clusteru samotného je stále výzva.
Plán na 2017¶
Do konce Q2 chceme mít na Kubernetes alespoň 5 interních služeb. Do konce roku plánujeme první klientský projekt nasadit na kontejnerovou platformu. Sledujeme vývoj Kubernetes 1.6 (RBAC jako beta!) a připravovaný EKS od Amazonu.
Kubernetes je budoucnost naší infrastruktury¶
Není to jednoduchý nástroj a vyžaduje investici do know-how. Ale pro firmu naší velikosti, která spravuje desítky služeb pro různé klienty, je kontejnerová orchestrace nutnost. Kubernetes je nejlepší volba na trhu.