Spotkania::9 maja 2020

Spotkanie HSŁ - 9 maja 2020

Obecni:

1. d33tah
2. Keij0
3. Martyna
4. q3k
5. beniamin
6. cytp450
7. bluraf
8. kpc
9. mciancia
10. pidpawel
11. zagura

Agenda:

1. (brak planu)
2. q3k: k8s
3. (brak planu)

Link do tmate: https://tmate.io/t/ro-nxpwxJX7Za3BaZZCqSqStw7MR

q3k: k8s

Nie stawiać k8s od nowa na początku, tylko użyć GKE - inaczej się zniechęcicie bo będziecie stawiać chmurę od nowa. Ciężko deployować coś, czego się nigdy nie używało.

k8s to przede wszystkim ujednolicone API po https i wielki key-value store z ACL.

node = pod = jeden zestaw kontenerów, który uruchamia się razem deployment = "chcę mieć ten pod uruchomiony" / "zrób mi update do tej wersji podu" (odpali drugą wersję, upewni się że żyje przez healthchecki i ubije poprzednią)

interaktywny shell z ubuntu

$ kubectl -n test run --image=ubuntu:20.04 -it foo /bin/bash

foo to nazwa

nie jest to komenda której się używa na produkcji

powstał pod (?), nowa wersja nie tworzy deploymentu ani replicaset

sieć w k8s

sieć w k8s jest śmieszna. 3 składniki: sieć podów, sieć serviceów, ingress z zewnątrz

sieć podowa

każdy node ma własną podsieć i będzie alokować jakiś adres z tej puli. wszystkie rzeczy z tej rzeczy widzą się nawzajem. w GKE to jest magiczne, w praktyce użyłoby się flannel lub czegoś innego co zapewnia routing

k8s tworzy natywny kontener, który się nazywa POD. jest to hack na dockera, który normalnie nie pozwala wygodnie współdzielić sieci (?)

stawiamy factorio (potem openttd)

kubectl -n test describe pod factorio-55cd5fb7f7-s5mv4

describe mówi nam, co jest nie tak, w odróżnieniu od get które jest bardzo gadatliwe

szybki edit deployu:

$ kubectl -n test edit deploy factorio

"nie powinieneś tak robić"

backoff = pod się odpala, wypierdala, po czym restartuje

factorio się nie odpaliło, nie było zamontowanego d/ata?

q3k upraszcza deployment do w miarę minimalnej wersji

konfudująca rzecz w q3k: matchLabels, metadane w template

service

wszystkie service mają osobne stałe adresy zajmują się routowaniem (?)

clusterip = serwis zewnętrzny?

q3k@stream:~$ kubectl -n test create service clusterip factorio --tcp=3979:3979

domyślnie dopiął się selector app=factorio (do sprawdzenia komendą kubectl -n test get svc -o wide)

do service'ów można się podpiąć też po takim hostname:

factorio.test.svc.cluster.local

(test to tutaj namespace)

sieci w k8s

ogarnięte po iptables

każdy serwis = jedna regułka na wszystkich maszynach, co się nie skaluje

ogarnia to kubeproxy

zmiana iptables = pobranie wszystkich reguł, zmiana jednej, wgranie nowej całości słabo skalowalne rozwiązanie, podobnież istnieją alternatywne implementacje

ping nie działa

zmiana typu deploymentu na factorio na loadbalancer sprawia, że GKE przydziela nam IP, ale to (dłuższą) chwilę trwa

kubecfg show i update

show = bierze filename i go wypluwa, więcej będzie wiadomo za chwilę. jeśli dostanie jsonneta, wypluwa yaml

update = bierze ścieżkę i robi deploy (?)

hello world jsonneta

w jsonnecie nie trzeba quotować kluczy, więc łatwiej przejść między yamlem a jsonem. w sumie taki yaml + klamerki. stringi muszą być quotowane. dozwolony jest przecinek na ostatniej linii, np {a: "b", }

zagooglać "kubernetes api reference"

(czy to jest klawiatura mechaniczna?)

podwójny dwukropek: kubecfg nie będzie w tym szukał zmiennej (?)

templating

efekt: platforma do hostowania serwerów gier która jest łatwo modyfikowalna

czemu docker ssie

system budowania obrazów

system nazywania obrazów

nixery

kubectl -n test run --image=nixery.dev/shell/bash/git/htop/yosys -it foo2

cue vs jsonnet vs gcl

RBAC

kubectl get clusterrole

clusterrolebinding

kubectl get clusterrolebinding get system:discovery -o yaml

multi-tenant = można dać dostęp osobom mniej zaufanym

internale

kubectl get all --all nie daje wszystkiego

niektóre typy są mocno wirtualne, więc nie da się łatwo zdumpować jako zwykły KV

porównanie z rancherem, k3s

rancher = kubernetes pod spodem, prostsze api

k3s = masa kodu z k8s wywalone, adaptowane do małej ilości maszyn, "jak jebnie to jebnie"

kiedy następne spotkanie?

Szkic wiadomości na listę mailingową:

Hej,

Dziś zanim na spotkaniu pojawił się q3k, były tylko dwie osoby: Keij0 i BluRaf. Pingowałem na Telegramie osobiście i przez podpiętą wiadomość, ale ogólnie od nas frekwencja była raczej mniejsza niż zwykle. Nie mam z tym problemu i możemy dalej funkcjonować w aktualnym trybie, ale pomyślałem, że zapytam, czy przypadkiem nie mamy do czynienia ze zmęczeniem materiału.

Stąd pytanie: czy chcecie, żebyśmy dalej spotykali się w obecnej formie, tj. spotkania o 18 we wtorki oraz dłuższe spotkania o 17 w soboty? Czy też zmieniamy coś w formule?

Będę wdzięczny za odpowiedź - na ten moment nie zaplanowałem żadnego spotkania na Meetupie, jeśli trzy osoby zgodzą się co do terminu z powrotem jakiś ogłoszę ;)

Pozdro, d33tah

wrzuciłem to tutaj: https://lists.hackerspace.pl/pipermail/lodz/2020-May/000123.html

rozmowa o tym, jak ogarnąć więcej elektroników

1. brakuje nam sprzętu (dla ludzi diy)
2. brakuje nam ludzi (od diy)
3. brakuje nam wiedzy eksperckiej (w kwestiach diy)

Co mamy:

1. Temat nas interesuje
2. w temacie np rasberry pi ogarniamy linuxa

pomysły:

1. d33tah robi lego mindstorms, kilka kamerek wycelowanych w stół
2. zapytac

d33tah testował streamowanie lego mindstorms

https://t.me/hakierspejs/25355

---

Przemigrowano z pada https://pad.hs-ldz.pl/HaE6ojkOQQW1kBRoI6Ikzw. Znajdziesz tam historię edycji sprzed migracji.

---