Ieri, per delle robe un po’ urgenti, mi occorreva avere uno stack ben definito intorno a Kubernetes.

Siccome siamo DevOps Engineer fighi ho scritto un po’ di moduli Terraform e in due minuti ho fatto tutto…

Non è vero c’ho messo tipo mezza giornata e l’ho fatto anche un po’ “a manella”.

Mi piace molto Kubernetes ma, da ormai svariato tempo, preferisco usarlo tramite Openshift soprattutto nell’ambito enterprise. Tuttavia, Rancher mi è piaciuto e lo vedo come una valida soluzione da proporre in determinati casi (magari produrrò un post del tipo Openshift Vs Rancher).

Non è comunque un’alternativa ad Openshift perchè sono due prodotti diversi.

Giuro che non ho abbandonato l’utilizzo sfrenato di Vagrant in locale sulla mia workstation ma, questa volta, ho adottato la soluzione “del ferro economico” al quesito “dove provo tutta sta roba”.

Si, alla fine ho preso in affitto una macchina su Kimsufi con Proxmox 5 che uso come laboratorio da molto tempo.

Ci provo svariate cose come diverse versioni di Openshift e la piattaforma che racconterò in questo post.

La configurazione del nodo fisico è molto semplice:

1. Proxmox 5 (già installato da Kimsufi).
2. Una rete locale 10.10.10.0/24 su cui attesto le virtual machine e le faccio uscire su internet.
3. Un HaProxy installato direttamente sul nodo fisico in modo da inoltrare il traffico sulla 10.10.10.0/24 e farmi accedere da fuori.
4. Spengo e accendo le diverse “sub-platforms” (me lo sono inventato al volo questo termine…) a seconda delle risorse che mi servono e le raggiungo tranquillamente tramite il reverse proxy.
5. No, non è come in cloud che spengo e accendo come mi pare con la confortevole sensazione del risparmio pay as you go. Spendo sempre gli stessi soldi.
6.  Per entrare direttamente sulle vm dal mio computer naturalmente ho impostato gli Host nella configurazione ssh.

Host gluster01
HostName 10.10.10.16
User root
ProxyCommand ssh -W %h:%p -lroot kimsufi

Host gluster02
HostName 10.10.10.17
User root
ProxyCommand ssh -W %h:%p -lroot kimsufi

Host gluster03
HostName 10.10.10.18
User root
ProxyCommand ssh -W %h:%p -lroot kimsufi

Tutto questo anche visto che il mio mac MacBook Pro (13-inch, 2017, Two Thunderbolt 3 ports) quando faccio cose DevOps si scalda e accende la ventola che è abbastanza fastidiosa. Inoltre ti esponi al rischio “collega simpatico” che ti fa battute tipo << che fa decolla? >>.

Mi serviva avere questo stack in poco tempo per testare cose:

1. Un cluster Kubernetes.
2. Un’istanza Rancher per gestirlo.
3. Un cluster GlusterFS in replica 3.

Per creare le VMs?

Volevo provare un plugin di Vagrant per Proxmox, ma non avevo tempo cui ho svolto “a manella” l’installazione di un nodo CentOS Linux release 7.5.1804 (Core) con cloning per le altre 2 virtual machine.

• gluster01 (10.10.10.16)
• gluster02 (10.10.10.17)
• gluster03 (10.10.10.18)

Per installare velocemente Kubernetes?

Assolutamente KubeSpray!

È andata più o meno così

1. 1. Come installare Python3 su Centos 7.5 visto qui

   2. yum install git ansible
      git clone https://github.com/kubernetes-incubator/kubespray.git
      mkdir inventory/mycluster
      cp -rfp inventory/sample/* inventory/mycluster
      declare -a IPS=(10.10.10.16 10.10.10.17 10.10.10.18)
      CONFIG_FILE=inventory/mycluster/hosts.ini python3.6 contrib/inventory_builder/inventory.py ${IPS[@]}
      

   3. Prova di connessione ai nodi con ‘ansible all -i inventory/mycluster/hosts.ini -m shell -a “whoami”‘

   4. Inizio installazione
      ansible-playbook -i inventory/mycluster/hosts.ini cluster.yml

Devo dire che è andato tutto bene senza troppi intoppi.

Kubernetes cluster up and running!

[root@gluster01 kubespray]# kubectl get nodes
NAME STATUS ROLES AGE VERSION
node1 Ready master,node 4m v1.11.2
node2 Ready master,node 4m v1.11.2
node3 Ready node 3m v1.11.2

 

Installazione di Rancher

Rancher si installa facilmente e basta dargli in pasto un cluster Kubernetes per vederlo all’opera. Nel mio caso gira come container Docker con persistenza.

 docker run -d --restart=unless-stopped -p 80:80 -p 443:443 -v /host/rancher:/var/lib/rancher rancher/rancher:latest

This slideshow requires JavaScript.

#creazione di un service account con diritti per amministrare il cluster k8s
[root@gluster01 ~]# kubectl create -f admin-user.yaml
serviceaccount/admin-user created
[root@gluster01 ~]# kubectl create clusterrolebinding cluster-admin-binding --clusterrole cluster-admin --user admin-user
clusterrolebinding.rbac.authorization.k8s.io/cluster-admin-binding created

Dopo un po’ di “smanettamenti” lato reverse proxy e DNS finalmente il cluster è in stato waiting…

Dopo altri “smanettamenti ” il cluster si è “joinato” correttamente a Rancher. Anzi più che “joinato” forse è meglio dire che Rancher ha eseguito un takeover su k8s.

Però ho dovuto importare un certificato nel container di Rancher con:

 docker cp /etc/pki/ca-trust/source/anchors/kube-ca.crt $idcontainerdirencher:/etc/ssl/certs/

È una cosa temporanea eh… dopo metto apposto…

Questi sono i pod attivi sul cluster nel namespace creato per Rancher

[root@node1 ~]# kubectl get pods --all-namespaces
NAMESPACE NAME READY STATUS RESTARTS AGE
cattle-system cattle-cluster-agent-6b8df4755-8tfxg 1/1 Running 0 2m
cattle-system cattle-node-agent-48bcq 1/1 Running 0 2m
cattle-system cattle-node-agent-928wl 1/1 Running 0 1m
cattle-system cattle-node-agent-t6cs6 1/1 Running 0 2m

Installazione di GlusterFS

Sui tre nodi Gluster01,02,03 dove avevo installato Kubernetes controllato da Rancher dovevo aggiungere anche GlusterFS.

Per l’installazione niente di più semplice di questa guida

[root@node1 ~]# gluster volume info

Volume Name: gv0
Type: Replicate
Volume ID: 2a111687-5d26-4051-b0a8-8d4a67efc87f
Status: Started
Snapshot Count: 0
Number of Bricks: 1 x 2 = 2
Transport-type: tcp
Bricks:
Brick1: gluster02:/bricks/brick1/gv0
Brick2: gluster03:/bricks/brick1/gv0
Options Reconfigured:
performance.client-io-threads: off
nfs.disable: on
transport.address-family: inet

#Lista nodi dei peer dal node1
[root@node1 ~]# gluster peer status
Number of Peers: 2

Hostname: gluster02
Uuid: 2cb83c74-ebc3-4dca-a62f-799433d198ae
State: Peer in Cluster (Connected)

Hostname: gluster03
Uuid: 6918282f-23f8-4627-b9b4-e7b9d521b32d
State: Peer in Cluster (Connected)

 

Una volta completato tutto ho potuto eseguire delle simulazioni utili per alcuni problemi su un’altra piattaforma.

Al momento sto girando dei pod con GlusterFS come persistent volume e nei prossimi articoli scenderò più nel dettaglio sull’utilizzo di Rancher.

Bella

Spesso, a seconda dell’environment in cui ci troviamo e delle restrizioni che dobbiamo affrontare lato sicurezza, dobbiamo effettuare un tuning del nostro inventory file.

Riporto in questo post un po’ di casi diversi che possono essere utili come esempi di configurazione base.

Sono casi molto semplici ma uniti insieme possono essere una visione d’insieme rapida sui parametri disponibili da usare nell’inventory.

Scambio chiavi ssh

Il default user per le connessioni ssh è root. La chiave pubblica dell’utente da cui sto lanciando Ansible è stata inserita in /root/.ssh/authorized_keys di root in ocslave35.

#inventory
[nodes]
ocslave35 openshift_hostname=ocslave35

ansible nodes -m ping
ocslave35 | SUCCESS => {
"changed": false,
"ping": "pong"
}

Autenticazione con password

Definisco la password di root di ocslave35.

#inventory
[nodes]
ocslave35 openshift_hostname=ocslave35 ansible_ssh_pass=supersecret_password

ansible nodes -m ping
ocslave35 | SUCCESS => {
"changed": false,
"ping": "pong"
}

Utilizzo utente operatore con password

Definisco un utente operatore con relativa password.

#inventory
[nodes]
ocslave35 openshift_hostname=ocslave35 ansible_user=operatore ansible_ssh_pass=foobar.123

[root@ocmaster35 ~]# ansible nodes -m shell -a "whoami"
ocslave35 | SUCCESS | rc=0 >>
operatore

become_method sudo

L’utente operatore diventa root tramite sudo

[root@ocslave35 ~]# cat /etc/sudoers.d/operatore
operatore ALL=(ALL) ALL

#inventory
[nodes]
ocslave35 openshift_hostname=ocslave35 ansible_user=operatore ansible_ssh_pass=foobar.123 ansible_become_user=root ansible_become=yes ansible_become_method=sudo ansible_become_pass=foobar.123

[root@ocmaster35 ~]# ansible nodes -m shell -a "whoami"
ocslave35 | SUCCESS | rc=0 >>
root

become_method su

L’utente operatore diventa root tramite il comando su con password definita nell’inventory.

#inventory
[nodes]
ocslave35 openshift_hostname=ocslave35 ansible_user=operatore ansible_ssh_pass=foobar.123 ansible_become_user=root ansible_become=yes ansible_become_method=su ansible_become_pass=supersecret_password

[root@ocmaster35 ~]# ansible nodes -m shell -a "whoami"
ocslave35 | SUCCESS | rc=0 >>
root

 

Accesso locale

Il nodo da cui lanciamo Ansible è lo stesso a cui vogliamo connetterci. Non c’è bisogno di ssh quindi.

[nodes]
ocmaster35 ansible_connection=local

ciao!

… si, ma oggi sto al mare per cui niente devops pistolotto.