k3s vs k8s (kubernetes) - limitalt namespace konfiguralasa

Linux-haladó

Sziasztok,

a Configure RBAC in your Kubernetes Cluster (bitnami.com)

oldal szerint k3s un. lightweight kubernetes rendszeren ki szeretnem probalni a limitalt namespace konfiguralasat.

Csak egyetlen master szerverem van docker+k3s rendszerrel debian bullseye op. rendszerrel, ahol root hozzaferesem is van.

Meg tudna nekem mondani, hol is talalhatok k3s rendszeren a tanusitvanyok/certificates?

Szerintetek mukodni fog az egesz?

Van valakinek tapasztalata k3s rendszerrel?

Koszonom elore a segitseget.

Ardi

( ardi | 2023. 01. 23., h – 13:51 )

Sziasztok,

probaltam a dromie altal feltuntetett hivatalos linket.

Ugy latszik, mukodik.

Letrehoztam egy development-dept namespace objektumot:

kubectl create namespace development-dept

Majd a kovetkezo parancsot hasznaltam:

 kubectl config set-context myuser --cluster=kubernetes --namespace=development-dept --user=myuser

 

Rovid teszt:

root@server:~# kubectl config use-context myuser
Switched to context "myuser".
root@server:~# kubectl get nodes
The connection to the server localhost:8080 was refused - did you specify the right host or port?
root@server:~#

Ami talan jonak latszik, mivel myuser ne lassa az infot a node-okrol, ugye?

Visszakapcsolva default-ra:

root@server:~# kubectl config use-context default
Switched to context "default".
root@server:~# kubectl get nodes
NAME    STATUS   ROLES                  AGE    VERSION
server   Ready    control-plane,master   3d5h   v1.25.5+k3s2
root@server:~#

Most mar csak az a kerdes, hogy tud a myuser kivulrol bejelentkezni a server gepre es ott a development-dept

namespace alatt "mukodni"?

Ardi

"Most mar csak az a kerdes, hogy tud a myuser kivulrol bejelentkezni a server gepre es ott a development-dept

namespace alatt "mukodni"?"

 

Nem egészen értem hogy hova més miért akar a myuser bejelentkezni. kubectl -n development-dept ... paranccsal el tudn intézni bármit a clusteren belül amit akar és amihez joga van.

( ardi | 2023. 01. 23., h – 15:05 )

Hmm, peldaul azert, mert a myuser nem klasszikus linux user /home/myuser konyvtarral.

Ekkor hogyan kuldod a " kubectl -n development-dept ..." parancsot  a server gepre, ahol fut a docker es a k3s service

es csak root felhasznalo fut rajta?

Vagy feltetel, hogy a myuser felhasznalo "klasszikus" linux-user legyen /home/myuser konyvtarral?

Ardi

a kubernetes nem tud, és nem is érdekli hogy milyen posix userek vannak.

ha megnézed a "kubectl config view --minify --raw" kimenetét, akkor láthatod, hogy a current-context egy  context(cluster,namespace,user) strukturára mutat:
- cluster mutatja meg az apiserver elérhetőségét
- user azonosítja a felhasználót
- namespace pedig a default namespace-t

 

szóval ha kivülről akard elérni a k8s/k3s -edet, akkor a kubeconfig -od cluster-ért hogy betaláljon a konténerben futó apiserver-be.

ebből az is következik, hogy bárhol összerakhatsz egy jó kubeconfig-ot....és a "felhasználónak" semmi mást nem kell odaadni, csak egy jó kubeconfig-ot

Írd le pontosan mit szeretnél! A hozzászólásaidból nekem az jön le, hogy nem nagyon tudod hogyan működik a Kubernetes és mire jó.

A kubectl paranccsal bármilyen Kubernetes erőforrást létre tudsz hozni a szerveren - deploymentet, pod-okat, service-eket, stb. Én pl egyáltalán nem szoktam belépni a cluster node-jaira, bár elvileg be lehetne.

Ponstosan mi a use case? Mit szeretnék a clusteren futtatni?

Az igaz, hogy nem teljesen ertem - hiszen csak nemreg kezdtem ismerkedni vele. :-)

Hogy most mit szeretnek? Van 1 azaz 1 szerverem, ahol docker es k3s service fut.Root vagyok a gepen + van egy sajat specialis user ssh hozzaferessel.

Szeretnek user-eket letrehozni, akiknek sajat namespace-uk van, ahol barmit letrehozhatnak, modifikalhatnak es torolhetnek. (mondjuk egy podot, deploymentet (amelyek a szerverre lehuzott docker image-kbol futtatnak mondjuk egy szkriptet) es nem zavarjak a masik usert es nem is babralhatnak bele egymas dolgaiba)

Nem tudom, lehet-e quotat szabni szamukra, ami a cpu-t, ram-ot, tarhelyet, egyebet illeti...

E felhasznalok NEM klasszikus linux userek.(nincs /home/user1 /home/user2 konyvtaruk). A szerver ip cime IP=szerver_IP.

Egyelore ezt szeretnem letrehozni es peldan keresztul megerteni.

Ardi

Minden feature-t lehet, amit leírtál, viszont a Kubernetes nagyon máshogy működik user szemszögből, mint egy hagyományos linux (még ha a háttérben ezek amúgy végső soron linuxos feature-ket is használnak). Én azt javasolnám, hogy kiragadott példák és kisérletezgetés helyett inkább keress valami Kubernetes kurzust / tutorialt és menj rajta végig, mert ha nem érted a mögöttes koncepciókat, akkor nagyon hamar el fogsz veszni a feature-k között.

( ardi | 2023. 01. 23., h – 17:15 )

Hmm, az altalad emlitett parancs kimenete tartalmaz vmi kulcsokat, viszont zavar, hogy nem tartalmazza a szerver IP cimet.

Hogy leli meg a "jol" elkeszitett config a megfelelo kubernetes clustert? (az en esetemben az egyetlen szervert)?

Ardi

kubectl config view --minify --raw
apiVersion: v1

clusters:
- cluster:
    certificate-authority-data: LS0tLS1CRUdJ...LQo=
    server: https://127.0.0.1:6443
  name: default
contexts:
- context:
    cluster: default
    user: default
  name: default
current-context: default
kind: Config
preferences: {}
users:
- name: default
  user:
    client-certificate-data: LS0tL......LS0K
    client-key-data: LS0...Qo=

Ahogy dromie kolléga írta, a szervered ip címe jelen esetben 127.0.0.1. A 6443 pedig a K8s API szerver portja. A kubectl-nek a cert adatokkal együtt ennyi épp elég. 

A docker parancsot felejsd el, mindent el tudsz intézni a kubectl-el. Amit nem, azt K8s alatt nem lehet :-). Ha a config fájlod a ~/.kube/config útvonalon van, akkor nem kell külön kapcsoló a parancsnak, ha máshol, akkor a --kubeconfig -al tudod megadni neki az aktuálisan használt configot.

A Kubernetes arra való, hogy konénerizált mikroszervizeket futtass jól skálázható módon. Nem biztos hogy userek scriptjeinek futtatására ez a legalkamasabb rendszer.

  • Milyen nyelvű scripteket kell futtatni?
  • Várhatóan milyen függőségei lesznek a scripteknek?
  • Honnan jön az input? Adatfájlokból? REST API hívásokból?
  • Hova kell eljuttatni az ederményt és milyen formában? Elég logolni? Kimeneti fájlok lesznek?
  • Csak parancssori cli scripteket arasz futtatni vagy mást is?

A fentiektől függ hogy pontosan milyen K8s resource-okra lesz szükséged, illetve mennyire alkalmas a feladatra a K8s.

Sziasztok,

koszonom a hozzaszolasokat - mindegyik hasznos.

Azt szeretnem megerteni, hogy ha 2 kulonbozo, egymastol fuggetlen kubernetes szerverem lenne IP1 es IP2 cimekkel, viszont

mindeketton 127.0.0.1 port  6443 lenne definialva, akkor a sajat gepemen hogy generalom a kulcsokat?

Honnan tudom, melyik configot (fájlod a ~/.kube/config ) kell belovasnom, hogy az egyik illetve a masik rendszeren hajtsam vegre a kubectl parancsokat?

Megjegyzes: most nem fontos, hogyan hasznalom a docker image-t  a pod illete a deploy yaml file definiciojaban.

Valahogy nem tiszta szamomra, honnan tudja a gepem kulcsok generalasa utan, hogy az egyik illetve a masik rendszeren hajtsa vegre a parancsokat.

A kulcsok generalasanal a szerverek mas es mas ca.key kulccsal rendelkeznek es igy kulonbozo kulcsok generalodnak a notebookom szamara? Es nem szukseges, hogy a ca.key kulcs tartalmazza a kubernetes1 szerver illetve kubernetes2 szerver ip cimet?

pl. https://kubernetes.io/docs/tasks/administer-cluster/certificates/

 

Mert ha a kovetkezo link szerint generalok egy user (=employee) reszere employee.key es employee.csr kulcsokat:

https://docs.bitnami.com/tutorials/configure-rbac-in-your-kubernetes-cl…

openssl genrsa -out employee.key 2048
openssl req -new -key employee.key -out employee.csr -subj "/CN=employee/O=bitnami"

Locate your Kubernetes cluster certificate authority (CA).
This will be responsible for approving the request and generating the necessary
 certificate to access the cluster API. Its location is normally /etc/kubernetes/pki/.
In the case of Minikube, it would be ~/.minikube/. Check that the files ca.crt and ca.key
exist in the location.

A kovetkezo sorban hasznalom fel az adott kubernetes szerver ca.crt es ca.key kulcsait arra, hogy kigeneraljam az employee.crt

Generate the final certificate employee.crt by approving the certificate
sign request, employee.csr, you made earlier. Make sure you substitute
 the CA_LOCATION placeholder with the location of your cluster CA. In this example,
 the certificate will be valid for 500 days:

openssl x509 -req -in employee.csr -CA CA_LOCATION/ca.crt -CAkey CA_LOCATION/ca.key -CAcreateserial -out employee.crt -days 500

Save both employee.crt and employee.key in a safe location (in this example we will use /home/employee/.certs/).

Megjegyzes: ez a mondatot nem teljesen ertem - nem arrol van szo, hogy az employee nem klasszikus linux user, akinek NINCS /home/employee konyvtara???

kubectl config set-credentials employee --client-certificate=/home/employee/.certs/employee.crt  --client-key=/home/employee/.certs/employee.key
kubectl config set-context employee-context --cluster=minikube --namespace=office --user=employee

Now you should get an access denied error when using the kubectl CLI with this configuration file.
 This is expected as we have not defined any permitted operations for this user.

kubectl --context=employee-context get pods

 

Ardi

Ha az első K8s szervered API szervere a 127.0.0.1:6443-on érhető el, akkor nem fogsz tudni második szervert indítani ugyan ezekkel a beállításokkal. Valószínűleg van rá mód, hogy ilyenkor a K8s API szerver másik porton figyeljen. De amúgy sem üzemszerű, hogy egy gép két különböző cluster nodejaként is funkcionál.

Mind írtam, a K8s arra való, hogy távoli szervereken, jól skálázható módon futtass konténerizált (nem feltétlenül Dockerben) alkalmazásokat. A fenti leírás arról szól, hogy nyilván egy userrel be vagy lépve egy munkaállomásra és onnan szeretnéd elérni a clustert. Ezért írja hogy a usered home mappájában mit hová tegyél. 

Lehet jobban járnál egy virtuális géppel és azon belül kialakított chroot jail megoldással. Nem írtad még meg pontosan mit és hogyan szeretnél futtatni.

Nos, a 127.0.0.1:6443 K3s (nem K8s!!) ip cimmel rendelkezik, melyre ssh-val fel tudok jelentkezni.

Nem kene inkabb ezt az IP cimet hasznalni? A localhost IP  eleres a notebookomrol tesztelheto valahogy?

Megjegyzes: most nem fontos, mit szeretnek futtatni - csak tudni szeretnem 100%-ra, hogy az adott K3s szerveren vagyok

mint user.

Ardi

Ja, hát én sem Linuxot használok, hanem Ubuntut. :-) (k3s - k8s)

 

Tehát nem tudod pontosan mire is való a Kubernetes, de használni akarod. Azért érdekel hogy mire szeretnéd használni, mert lehet hogy eleve nem is lesz arra jó és kapásból megkímélhetnéd magad sok-sok szívástól.

Egy fizikai gépen, virtuális gépekben futtatni több K8s K3s clustert max tanulásra, gyakorlásra jó, de értelme nem sok van.

Ha a kubectl paranccsal futtatsz bármit, az az adott K3s szervereden fog lefutni. Ha van egy másik clustered és annak a kubectl konfigját fogod megadni --kubeconfig paraméterrel a kubectl-nek, akkor meg azon.

A 127.0.0.1 ip-ből én arra következtettem hogy a fizikai gépedre telepítetted a K3s-t. Nem így van?

Ja, hát én sem Linuxot használok, hanem Ubuntut. :-) (k3s - k8s) <== Ez tetszik.

Van egy Dell server a cegben es most nem hasznaljak semmire, igy probalgatom a k3s-t.

Es otthonrol, a cegi gepemrol szeretnek mint dedikalt user egy dedikalt namespace-be "zarodni". :-)

Semmi tobb most...

Ardi

"Accessing the Cluster from Outside with kubectl

Copy /etc/rancher/k3s/k3s.yaml on your machine located outside the cluster as ~/.kube/config. Then replace the value of the server field with the IP or name of your K3s server. kubectl can now manage your K3s cluster."

 

Vagyis ha a konfig fájlt lemásolod a gépedre és átírod a 127.0.0.1-et a szerver IP-jére, akkor ha minden igaz a saját gépedről eléred a clustert kubectl-el. Ez lenne az üzemszerű működés, ekkor tudsz külön config fájlokat gyártani a usereidnek.

Ugye itt a userek lehetőséget kapnak hogy adott namespace-ekbe K8s erőforrásokat hozzanak létre. Ez messze nem egy virtuális gép.

Erőforrás limitet az egyes pod-okra tudsz beállítani, userekre nem. Ha egy szerveren futtatsz szoftvereker egy példányban, akkor kb értelmetlen az egész, kivéve ha tanulási céllal nyomogatod. (Bár én akkor is inkább egy Cloud Providernél lőnék fel egy clustert, max a nap végén leállítanám - pár dollárért cserébe valós környezetben lehet tanulni.)

Copy /etc/rancher/k3s/k3s.yaml on your machine located outside the cluster as ~/.kube/config ==> OK

$ kubectl get nodes
Unable to connect to the server: dial tcp 127.0.0.1:6443: connectex: No connection could be made because the target mach
ine actively refused it.

UPDATE: Atirva a configban a localhost IP-t a szerver cimre:

$ kubectl get nodes
NAME    STATUS   ROLES                  AGE    VERSION
server   Ready    control-plane,master   4d5h   v1.25.5+k3s2

UPDATE2:

A config file igy nez ki (kulcsok xxx-re irva)

apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: xxx
    server: https://server_IP:6443
  name: default
contexts:
- context:
    cluster: default
    user: default
  name: default
current-context: default
kind: Config
preferences: {}
users:
- name: default
  user:
    client-certificate-data: xxx
    client-key-data: xxx

 

$ kubectl get ns
NAME               STATUS   AGE
default            Active   4d5h
kube-system        Active   4d5h
kube-public        Active   4d5h
kube-node-lease    Active   4d5h
development-dept   Active   23h

$ kubectl get role
NAME        CREATED AT
developer   2023-01-23T12:34:33Z

$ kubectl get rolebinding
NAME                       ROLE             AGE
developer-binding-myuser   Role/developer   23h

Nos, az a kerdesem, hogyan tudom e configot boviteni myuser-rel es kulcsaival, hogy csak a development-dept namespace-ben tudjon mukodni?

Ardi

Asszem, megakadtam a fenn emlitett link alatti leirasban:

1.

Hianyzik ez a sor :

kubectl create namespace brown-fox

mielott ez kovetkezne.

Role for Bill:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: bill
  namespace: brown-fox
rules:
  - apiGroups: [""]
    resources: ["pods", "services", "namespaces", "nodes"]
    verbs: ["create", "get", "update", "list", "watch", "patch"]
  - apiGroups: ["apps"]
    resources: ["deployment"]
    verbs: ["create", "get", "update", "list", "delete", "watch", "patch"]
  - apiGroups: ["rbac.authorization.k8s.io"]
    resources: ["clusterroles", "clusterrolebindings"]
    verbs: ["create", "get", "list", "watch"]

2.

Itt akadtam meg:

Letrehoztam:

vi config-adam.yaml

vi config-bill.yaml es megprobalom kitolteni: config-adam.yaml file-t

# Fetching Adam's secret
kubectl get secrets -n kube-system

root@server:~# kubectl get secrets -n kube-system
NAME                                TYPE                                  DATA   AGE
k3s-serving                         kubernetes.io/tls                     2      5d1h
server.node-password.k3s             Opaque                                1      5d1h
sh.helm.release.v1.traefik-crd.v1   helm.sh/release.v1                    1      5d1h
sh.helm.release.v1.traefik.v1       helm.sh/release.v1                    1      5d1h
adam-secret                         kubernetes.io/service-account-token   3      12m
root@server:~#

kubectl describe secrets adam-secret -n kube-system

es meglett a token!

Kerdes: alul a hianyzo ??? helyebe mit irok be? adam vagy default

- context:

    cluster: default
    user: default
  name: default
current-context: default
kind: Config
users:
- name: default
  user: ??? <---ez hianyzik: adam lenne?:
    token: xxx <---ez megvan

Megjegyzes: Nem hasznalok AWS EKS-t!

Ardi

Hello,

Akkor igy jo lesz mindket user yaml configuracioja?

.

.

.

    server: https://server-ip:6443
  name: default
contexts:
- context:
    cluster: default
    user: default
  name: default
current-context: default
kind: Config
users:
- name: adam (illetve bill)
  user:
    token: xxx

 

Ardi

nem, a context-ben lévő usernek is adam -nak (v bill-nek) kéne lennie.

De ez a név csak a configfile-on belüli referencia, a kubernetes api server természetesen ebből semmit nem fog látni, ő csak a token-t fogja megpróbálni feldolgozni.

Ok - kezdem erteni.

Mukodne, ha a default, adam es bill konfigjat egyetlen fajlba tennem?

cat <<EOF | kubectl apply -f -

apiVersion: v1
kind: Config
clusters:
- cluster:
    server: https://server-ip:6443
  name: default

contexts:
- context:
    cluster: default
    namespace: default
    user: default
  name: default
- context:
    cluster: default
    namespace: kube-system
    user: adam
  name: context-adam
- context:
    cluster: default
    namespace: brown-fox
    user: bill
  name: context-bill
current-context: "" #<---???
users:
- name: adam
  user:
    token: aaaa
- name: bill
  user:
    token: xxxx

EOF

 

Mit jelent a current-context: "" #<---???

#mutatja az osszes beallitast?

kubectl config view

#mutatja az aktualisan beallitott contextet

kubectl config get-contexts

#igy valthatok az egyikbe vagy masikba (ez fugg attol, hogy mi van a configban?)

kubectl config use-context context-adam

kubectl config use-context context-bill

#igy valtok vissza default-ba (mi is a default tulajdonkeppen)?

kubectl config use-context default

#esetleg ez

kubectl config use-context context-default

 

https://kubernetes.io/docs/concepts/configuration/organize-cluster-acce…

https://kubernetes.io/docs/tasks/access-application-cluster/configure-a…

 

Ardi

"Mukodne, ha a default, adam es bill konfigjat egyetlen fajlba tennem?"

 

Valószínűleg működne, csak nem sok értelme van. Ha adam tud default context-et használva bármit csinálni, akkor miért használná a sajátját? Ugye minden user úgy fér hozzá a clusterhez hogy kap egy saját konfig fájlt. Ha abban benne van midnen, akkor nem sok értelme van az egésznek.

Ertem.

Vmi bibi lehet viszont a configgal:

root@server:~# cat config-adam.yaml
apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: xxx
    server: https://server-ip:6443
  name: default
contexts:
- context:
    cluster: default
    user: adam
  name: context-adam
current-context: context-adam
kind: Config
users:
- name: adam
  user:
    token: xxx
root@server:~#
root@server:~#

root@server:~# kubectl apply -f config-adam.yaml
error: resource mapping not found for name: "" namespace: "" from "config-adam.yaml": no matches for kind "Config" in version "v1"
ensure CRDs are installed first
root@server:~#

Ardi

Koszi a valaszt.

Ezzel mar a valaszod elott is probalkoztam - nem segitett.

 

root@server:~# ku get ns
NAME               STATUS   AGE
default            Active   5d6h
kube-system        Active   5d6h
kube-public        Active   5d6h
kube-node-lease    Active   5d6h
development-dept   Active   2d
brown-fox          Active   4h33m
root@server:~#

TESZT1:

contexts:
- context:
    cluster: default
    namespace: default
    user: adam
  name: context-adam
current-context: context-adam
kind: Config
preferences: {}
users:
- name: adam
  user:

root@server:~# kubectl apply -f config-adam.yaml
error: resource mapping not found for name: "" namespace: "" from "config-adam.yaml": no matches for kind "Config" in version "v1"
ensure CRDs are installed first
root@server:~#

TESZT2:

contexts:
- context:
    cluster: default
    namespace: brown-fox
    user: bill
  name: context-bill
current-context: context-bill
kind: Config
preferences: {}
users:
- name: bill
  user:

root@server:~# kubectl apply -f config-bill.yaml
error: resource mapping not found for name: "" namespace: "" from "config-bill.yaml": no matches for kind "Config" in version "v1"
ensure CRDs are installed first

Ardi

Bocsánat, nem olvastam el a kérdést.....

SEMMI ÉRTELME nincs "kubectl apply" -olni a kubeconfig-ot.

a kubeconfig-ot csak átadod a kubectl -nek mint "kapcsolódási paraméterek" szinten.....a kubeconfig NEM része a kubernetesnek

amit ki akarsz adni parancs:

kubectl --kubeconfig config-bill.yaml get pods
kubectl --kubeconfig config-adam.yaml get pods

SZUPER!! ==> mukodik.

TESZT1:

Atkopiroztam a config-bill.yaml files a notebookomra, mentettem az eredeti config file-t es ezt tettem be helyette.

#$ kubectl get pods
No resources found in brown-fox namespace.

$ kubectl get ns
Error from server (Forbidden): namespaces is forbidden: User "system:serviceaccount:brown-fox:bill-sa" cannot list resou
rce "namespaces" in API group "" at the cluster scope

TESZT2:

Ugyanezt ismetelve config-adam.yaml file eseteben:

$ kubectl get pods
No resources found in default namespace.

$ kubectl get ns
NAME               STATUS   AGE
default            Active   5d7h
kube-system        Active   5d7h
kube-public        Active   5d7h
kube-node-lease    Active   5d7h
development-dept   Active   2d1h
brown-fox          Active   5h35m

$ kubectl get role
Error from server (Forbidden): roles.rbac.authorization.k8s.io is forbidden: User "system:serviceaccount:kube-system:ada
m-sa" cannot list resource "roles" in API group "rbac.authorization.k8s.io" in the namespace "default"

$ kubectl get clusterrole|grep adam
adam                                                                   2023-01-25T08:39:25Z

$

Megprobalok vmi "helyes" toolokat keresni, amik kiirjak, mit csinalhat egy adott beallitas.

Kezdetnek talan ez is jo: https://www.mankier.com/1/kubectl-auth-can-i

Koszonet mindenkinek, aki segitett!

Ardi

( mhmxs v | 2023. 01. 25., sze – 21:04 )

Azt nagyon halkan jegyzem meg, hogy `k3s un. lightweight kubernetes` volt regen. Manapsag alig vesznek ki a mainstreambol dolgokat, mondhatni vanilla Kubernetes (ezt a k3s dev mondja nem en).

Coding and ADHD should be best friends