Written by 
- Kubernetes – orchestrátor kontejnerů (1) – schedulery vs. PaaS
- Kubernetes – orchestrátor kontejnerů (2) – instalace a první běžící kontejner
- Kubernetes – orchestrátor kontejnerů (3) – deployment aplikací, škálování a rollback
- Kubernetes – orchestrátor kontejnerů (4) – interní balancing a discovery služeb
- Kubernetes – orchestrátor kontejnerů (5) – přístup zvenku
Minule jsme srovnali Kubernetes s dalšími orchestrátory a platformami. Dnes už místo povídání systém nainstalujeme a spustíme si první kontejner.
Instalace pro naše zkoušení
Existuje mnoho způsobů jak Kubernetes nainstalovat – jak pro laboratorní tak pro produkční nasazení. Terraform (od firmy Hashicorp) je open sourcové řešení, které může rozjet Kubernetes unifikovaným způsobem nad vícero infrastrukturními prostředími jako je OpenStack, AWS nebo klasické vSphere virtualizace. Další možností jsou hotové předpisy pro configuration management nástroje jako je Ansible či Chef. Dá se také použít OpenStack Heat šablona nebo projekt OpenStack Magnum. Jednou z nejpříjemnějších metod je použití CoreOS, které se soustředí na jednoduché rozběhání Kubernetes už nějakou dobu. Právě kombinace CoreOS a Vagrant bude to, co použiji v této sérii článků. Stačí vám fyzický Linux stroj s VirtualBox a můžete začít.
Nejprve si stáhneme automatizační předpisy CoreOS pro Kubernetes
git clone https://github.com/coreos/coreos-kubernetes.git
UPDATE: Nemáte Linux stroj? Tady najdete variantu pro Vagrant fungující i ve Windows, ale nastavení je trochu jiné (na to přijdete).
https://github.com/pires/kubernetes-vagrant-coreos-cluster
Nakopírujte příkladový konfigurační soubor do config.rb.
cd coreos-kubernetes/multi-node/vagrant cp config.rb.sample config.rb
V tomto souboru upravíme námi požadovaný cluster. Budu chtít jeden kontroler, 3 “pracanty” a jednu VM s Etcd.
$update_channel="alpha" $controller_count=1 $controller_vm_memory=512 $worker_count=3 $worker_vm_memory=1024 $etcd_count=1 $etcd_vm_memory=512
Teď už stačí jen klasické:
vagrant up
Kromě vybudování VM s Kubernetes clusterem ještě budeme potřebovat CLI pro Kubernetes. Stáhněte ho, udělejte spustitelné a můžete ho například nakopírovat někam, kam vede cesta odkudkoli.
curl -O https://storage.googleapis.com/kubernetes-release/release/v1.2.2/bin/linux/amd64/kubectl chmod +x kubectl sudo mv kubectl /usr/local/bin/kubectl
Vagrant připravil i konfigurační soubory pro kubectl, takže vyzkoušejme, že je CLI schopno například vypsat členy Kubernetes clusteru.
$ export KUBECONFIG="${KUBECONFIG}:$(pwd)/kubeconfig"
$ kubectl get nodes
NAME STATUS AGE
172.17.4.101 Ready,SchedulingDisabled 52m
172.17.4.201 Ready 51m
172.17.4.202 Ready 52m
172.17.4.203 Ready 50m
Váš první běžící kontejner
Dnes se ještě nebudeme pouštět do bůh ví jakých podrobností, ale do základů se dáme. Spusťme si jeden kontejner (ve skutečnosti se toho stane trochu víc, ale buďte trpěliví).
$ kubectl run kontejner --image cloudsvet/byoc --port 3000 deployment "kontejner" created
Spustili jsme nejmodernější entitu v Kubernetes – “deployment”. Zkusme si ho vypsat.
$ kubectl get deployments NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE kontejner 1 0 0 0 20s
Všimněte si, že jsou tam velmi zajímavé sloupečky. DESIRED ukazuje kolik instancí chceme mít, CURRENT kolik aktuálně máme (ano, Kubernetes se postará, aby to tak bylo). Sloupeček UP-TO-DATE může zavánět nějakým chytrým verzování (a tak to také je).
Kubernetes při svém rozhodování na jaký node co umístí nepracuje na úrovni kontejnerů, ale používá koncept podů. Jde o jeden (a pak je to stejné jako použití samotného kontejneru), ale i víc nodů (pak Kubernetes garantuje, že jsou neustále spolu a jde o nedělitelné uskupení). Proč mít víc kontejnerů v podu? Tak například se občas používá princip “sajdkáry”, tedy aplikace běží v jednom kontejneru a má vedle sebe svého neoddělitelného souseda, který se stará o provisioning nebo monitoring.
Vypišme si tedy pody.
$ kubectl get pods -o wide NAME READY STATUS RESTARTS AGE NODE kontejner-3506078564-ptls4 1/1 Running 0 3m 172.17.4.203
Zkuste o něm zjistit víc detailů.
$ kubectl describe pod kontejner
Name: kontejner-3506078564-ptls4
Namespace: default
Node: 172.17.4.203/172.17.4.203
Start Time: Sat, 23 Apr 2016 01:02:16 -0700
Labels: pod-template-hash=3506078564,run=kontejner
Status: Running
IP: 10.2.49.2
Controllers: ReplicaSet/kontejner-3506078564
Containers:
kontejner:
Container ID: docker://b9acec853267371d7868b7bf1c36ba4c81e6132e22721f795b99d04d04046e4e
Image: cloudsvet/byoc
Image ID: docker://sha256:4b8e7e0e80a7313e138802085345fb9c370dae7c7dad9cf5c8f1380b1b8ca519
Port: 3000/TCP
QoS Tier:
memory: BestEffort
cpu: BestEffort
State: Running
Started: Sat, 23 Apr 2016 01:05:15 -0700
Ready: True
Restart Count: 0
Environment Variables:
Conditions:
Type Status
Ready True
Volumes:
default-token-u6ia4:
Type: Secret (a volume populated by a Secret)
SecretName: default-token-u6ia4
Events:
FirstSeen LastSeen Count From SubobjectPath Type Reason Message
--------- -------- ----- ---- ------------- -------- ------ -------
5m 5m 1 {default-scheduler } Normal Scheduled Successfully assigned kontejner-3506078564-ptls4 to 172.17.4.203
4m 4m 1 {kubelet 172.17.4.203} spec.containers{kontejner} Normal Pulling pulling image "cloudsvet/byoc"
2m 2m 1 {kubelet 172.17.4.203} spec.containers{kontejner} Normal Pulled Successfully pulled image "cloudsvet/byoc"
2m 2m 1 {kubelet 172.17.4.203} spec.containers{kontejner} Normal Created Created container with docker id b9acec853267
2m 2m 1 {kubelet 172.17.4.203} spec.containers{kontejner} Normal Started Started container with docker id b9acec853267
Pro dnešek nám to stačí – deployment smažeme.
$ kubectl delete deployment kontejner deployment "kontejner" deleted
