Sa ne tina dumnezeu sanatosi.


Previziuni timide: America o sa devina din ce in ce mai iubita in lume, la exemplul lor China isi ia Taivan, dupa care Trump face un atac supriza la Groenlanda, Rusia se muta si pe alte fronturi…
Bula AI se sparge, OpenAI o sa fie redus la tacere, singurii cu un produs valid raman Google.
Romania nu o sa reuseasca sa reglementeze pensiile speciale, statul roman nu vrea sa declare falimentul dar vor incerca sa faca bani din impozite din ce in ce mai mari. Europa nu o sa reuseasca pana la sfarsitul anului sa se impuna in nici un fel…
Oscarul o sa fie castigat de un film cu pisici care danseaza generat in totalitate cu AI.

Asa cum ne place sa privim inspre viitor, sa ghicim in stele sau in parul pubian prins pe cada de dus, in cafea, in liniile de pe palma, in vibratia zilei s.a.m.d – cum o sa fie 2026? Scenariul este un amestec de SF, Comedie neagra, cele mai proaste sitcom-uri si survivor la antena1. Viitorul arata ca gandurile care ne dau anxietate.

Pe Frontul Geopolitic: Unde se duce lumea?

Previziunile vorbeau despre o Americă brusc “mai iubită” pentru rezerverele de petrol din Venezuela (ironic, având în vedere tensiunile globale), urmată de o mișcare îndrăzneață a Chinei în Taiwan. Sună ca un joc de șah? Nu e sah, e etalare de cohones si pariuri pe faptul ca nimeni nu vrea WW3. Ca tacâmul să fie complet, un “atac surpriză” al lui Trump la Groenlanda (relicva unei intenții reale de cumpărare, acum transformată în scenariu de acțiune) și Rusia extinzându-se pe noi fronturi. Nu zic nimic despre Israel, ei doar nu mai vor hamas pe lume. Definitia hamasului este variabila in functie de narativ.

Sincer asta ne tine cu sufletul la gura, mai ca dabia mai respiram, mai rau decat versiunea alfa-beta covid. Esentialul este clar, resursele raman miza principala si suntem blestemati sa repetam greselile trecutului, pentru ca l-am uitat.

Bula AI se sparge? Adio, OpenAI, Salut, Google?

In mod ironic pentru ca lucrez in IT ma intriga bula AI. OpenAI, Nvidia si Oracle sunt prinsi acum intr-un cerc masturbatoric, ei spun ca nu o fac cand sunt cu plua partenerului in mana. Sper sa intre in faliment pentru ca AI-ul este un produs nociv pentru societate. Brain rot! Eficientizare procese? Imbunatatirea traiului celor care traiesc pe pamant? Nu. Doar imbunatatirea profitului, inrobirea celor care traiesc pe pamant. Masini care se conduc singure, gaini AI.

AI-ul este momentan un miraj, cu fanfara multa, concurenta acerba pentru un singur castigator. Cel care tine actiunile castigatorului in mana. Pentru noi se termina tot intr-o realitate rece, ca un dus pe vremea lui Ceausescu atunci cand faceam economii sa platim datoria externa a Romaniei.

România și Europa: O oglindă tristă a prezentului?

Aici, previziunile au un gust salciu de realism. “România nu o să reușească să reglementeze pensiile speciale,” “statul român nu vrea să declare falimentul, dar vor încerca să facă bani din impozite din ce în ce mai mari.” Sună familiar, nu? Cât timp mai poate dura acest dans politic? Ca sa fie bine nu trebuie sa fie un pic rau? dar noua romanilor nu ne este bine de multa vreme. Suntem satui ca nepotii de sarmale cand petrec vacanta de iarna pe la bunici.

Europa, la rândul ei, este văzută ca un colos lent, incapabil să se impună. Între birocrație și lipsa unei viziuni unitare, continentul pare să navigheze într-o ceață, căutându-și drumul într-o lume din ce în ce mai agitată.

Oscarul pentru Pisicile Dansatoare

Bomboana de pe tort: Oscarul câștigat de un film cu pisici dansatoare, generat integral de AI! O satiră inteligentă la adresa unei industrii care se luptă cu inovația și, în același timp, o premoniție deloc fantezistă.

Concluzie.

Nu trebuie sa ne afundam in pesimism. Lumea este intr-o continua miscare si trebuie sa fim constienti de provocari si sa cautam solutii. Eu sunt inca optimist ca vom vedea pe marile ecrane filmul cu pisici care danseaza, broadway ai! Ay!

Când înveți AWS, cel mai mare pericol nu e că nu înțelegi serviciile — e că uiți ceva pornit și găsești o factură surpriză la final de lună. Free Tier-ul AWS are limite clare, iar unele servicii nu au tier gratuit deloc. Iată 7 sfaturi practice ca să rămâi la zero.

1. Monitorizează storage-ul ca pe proprii bani

EBS are o limită de 30 GB total pentru toate volumele combinate în Free Tier. Nu per instanță, ci total. Dacă ai două instanțe cu câte 20 GB fiecare, ești deja peste limită.

S3 are o limită de 5 GB gratuit. Dacă urci fișiere mari pentru teste, pune lifecycle rules care șterg automat obiectele vechi.

Cel mai important: oprirea unei instanțe nu șterge volumul EBS atașat. Volumul continuă să existe și să consume din cei 30 GB. Dacă nu mai ai nevoie de el, șterge-l explicit.

Sfat practic: folosește un singur volum per instanță când e posibil.

2. Urmărește orele de compute cu atenție

Free Tier oferă 750 ore/lună pentru instanțe eligibile (t2.micro sau t3.micro, în funcție de regiune). 750 de ore înseamnă exact o instanță care rulează non-stop — 24h × 31 zile = 744 ore.

Dacă pornești două instanțe simultan, orele se adună: 2 instanțe × 24h = 48 ore pe zi, deci depășești limita în mai puțin de 16 zile.

Soluție: pornești instanțe suplimentare doar când le folosești activ și le oprești imediat după.

3. Evită serviciile fără Free Tier

Unele servicii AWS nu au tier gratuit deloc și încep să coste imediat ce le pornești:

  • NAT Gateway — costă per oră și per GB procesat. Dacă ai nevoie de acces la internet dintr-un subnet privat, folosește în schimb o instanță EC2 ca NAT instance (mai complicat, dar gratuit).
  • Load Balancer (ALB/NLB/CLB) — costă per oră, chiar dacă nu trece niciun trafic prin el.
  • RDS cu Provisioned IOPS — IOPS provizionat costă separat față de instanță. Folosește doar storage-ul standard gp2/gp3.
  • Elastic IP neutilizat — un Elastic IP alocat dar neatasat la o instanță activă costă câțiva cenți pe oră. Pare puțin, dar se adună.

Regula generală: dacă testezi ceva, pornești, testezi și ștergi în aceeași zi.

4. Curăță agresiv după teste

AWS taxează resursele provizionate, nu pe cele folosite efectiv. Asta înseamnă că o resursă uitată costă la fel ca una care procesează trafic intens.

Lista de verificat după fiecare sesiune de learning:

  • Instanțe EC2 oprite (nu terminate) — volumele EBS continuă să existe
  • Snapshots EBS rămase după ștergerea instanței
  • AMI-uri custom create pentru teste
  • CloudWatch Logs — log groups vechi ocupă storage și costă
  • Elastic IPs neatașate

5. Critic: Setează alarme de billing din prima zi

Înainte să faci orice altceva în AWS, mergi la Billing → Budgets și creează un budget de 1–2 USD cu alertă prin email. AWS te va notifica imediat ce depășești limita, înainte să ajungi la o factură serioasă.

Pași:

  1. AWS Console → Billing → Budgets → Create Budget
  2. Alege „Cost budget”
  3. Setează suma la 1 USD și alertă la 80% din budget
  4. Adaugă adresa de email

Costă zero să setezi un budget. Poate salva de o factură de 20–50 USD dintr-un NAT Gateway uitat.

6. Folosește Cost Explorer și Free Tier Usage

AWS are o pagină dedicată vizualizării consumului din Free Tier: Billing → Free Tier. Îți arată per serviciu câte procente din limita lunară ai consumat deja.

Dacă vezi un serviciu la 80% pe 15 ale lunii, știi că trebuie să reduci activitatea în a doua jumătate.

7. Pentru sesiuni intensive de learning

Dacă vrei să înveți servicii mai mari (instanțe mai puternice, baze de date, etc.) fără să plătești, strategia optimă e:

  • Menține o singură instanță t3.micro ca baseline lab, pornită 24/7 — aceasta consumă exact cele 750 ore gratuite
  • Pornești instanțe mai mari sau servicii extra doar când ești activ în fața calculatorului
  • Ștergi tot la finalul sesiunii

Dacă ai un credit AWS (din AWS Educate, evenimente, sau alte promoții), acesta acoperă costurile suplimentare. Direcționează creditul spre sesiunile intensive, nu spre resurse lăsate pornite.

Concluzie

Free Tier-ul AWS e generos dacă îl respecți. Cel mai frecvent motiv pentru facturi neașteptate nu e ignoranța, ci uitarea — o resursă pornită pentru un test rapid și neștearsă ulterior. Cu alarme de billing setate și o rutină de curățare după fiecare sesiune, poți învăța AWS luni întregi fără să plătești nimic.

Uptime Kuma este un tool dragut de monitorizare, face automat rapoarte SLA, monitorizeaza site-uri, este destul de util. Pentru a monitoriza ill.ro folosesc altceva (UptimeRobot), m-am gandit sa fie independent de homelab, ca daca pica homelab-ul nu mai imi zice nimeni ca a cazut site-ul…
Voi folosi ArgoCD pentru a testa si invata cum functioneaza acest tool… l-am instalat si pana acum e doar o interfata web… Asadar sa instalam cu ArgoCD.

Pentru pasii astia avem niste prerechizite:
1. Un share nfs pentru persistent storage (il foloseste uptime kuma ca sa tina minte tot ce face)
2. Un cont de github sau orice repo, eu o sa folosesc github ca inca nu am deployat asa ceva in homelab.
3. metalLB functional 🙂

1. Mai intai share-ul NFS: am folosit v3 pentru simplitate, am permis accesul full din reteaua de acasa, desigur in afara homelab-ului vom avea autentificare si altele. Am creat un share numit uptime-kuma.

Pe nodurile k8s (control/worker) vom instala nfs-common si testam daca share-ul nfs este disponibil si putem scrie pe el.

apt install -y nfs-common
mkdir /mnt/test-nfs
mount -t nfs -o nfsvers=3 IP_NFS:/uptime-kuma /mnt/test-nfs
touch testnfs
cd /mnt/test-nfs && ls

Ar trebui sa vedem fisierul. Daca e acolo, inseamna ca nodurile noastre pot accesa NFS, trecem mai departe.

2. Github. Facem un nou repo, o sa il numesc argoCD si vom crea intr-un director nou urmatoarele fisiere:

Prima oara facem un namespace, fisierul uptimekuma-namespace.yaml.

apiVersion: v1
kind: Namespace
metadata:
  name: uptime-kuma

Definim un persistent volume – uptimekuma-pv.yaml

apiVersion: v1
kind: PersistentVolume
metadata:
  name: nfs-pv-uptime-kuma
spec:
  capacity:
    storage: 10Gi
  volumeMode: Filesystem
  accessModes:
    - ReadWriteMany
  persistentVolumeReclaimPolicy: Retain
  storageClassName: slow
  mountOptions:
    - hard
    - nfsvers=3
  nfs:
    path: /uptime-kuma
    server: IP_NFS #adresa ip a serverului nfs

Persistent volume claim uptimekuma-pvclaim.yaml

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: uptime-kuma-pvc
  namespace: uptime-kuma
spec:
  accessModes:
    - ReadWriteMany
  volumeMode: Filesystem
  resources:
    requests:
      storage: 1Gi
  storageClassName: slow

Definim serviciul – uptimekuma-service.yaml

apiVersion: v1
kind: Service
metadata:
  name: uptime-kuma-tcp
  namespace: uptime-kuma
spec:
  type: LoadBalancer #nu specificam ip, lasam metallb sa aleaga pentru noi
  ports:
  - name: web-ui
    protocol: TCP
    port: 3001
    targetPort: 3001
  selector:
    app: uptime-kuma

Si in final, deployment-ul uptimekuma-deplyment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: uptime-kuma
  namespace: uptime-kuma
spec:
  selector:
    matchLabels:
      app: uptime-kuma
  replicas: 1
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  template:
    metadata:
      labels:
        app: uptime-kuma
    spec:
      containers:
      - name: uptime-kuma
        image: louislam/uptime-kuma:1
        imagePullPolicy: IfNotPresent
        env:
        # only need to set PUID and PGUI because of NFS server
        - name: PUID
          value: "1000"
        - name: PGID
          value: "1000"
        ports:
        - containerPort: 3001
          name: web-ui
        resources:
          limits:
            cpu: 200m
            memory: 512Mi
          requests:
            cpu: 50m
            memory: 128Mi
        livenessProbe:
          tcpSocket:
            port: web-ui
          initialDelaySeconds: 60
          periodSeconds: 10
        readinessProbe:
          httpGet:
            scheme: HTTP
            path: /
            port: web-ui
          initialDelaySeconds: 30
          periodSeconds: 10
        volumeMounts:
        - name: data
          mountPath: /app/data
      volumes:
      - name: data
        persistentVolumeClaim:
          claimName: uptime-kuma-pvc

Pasul 2, sa intram in ArgoCD, sa definim un repository si o aplicatie. Rezultatele ar arata ca in printscreen-urile de mai jos. Avem nevoie de 2-3 lucruri:
– repository URL: tip https sau cum vreti voi, si path-ul.
– project – o sa fie default, ca nu am altceva definit
– cluster – o sa aleaga automat clusterul pe care este instalat
– path: uptimekuma – e directorul unde am pus tot.
– sync: am lasat manual

Dupa ce accesezi aplicatia si dai click pe sync, argo o sa downloadeze yaml-urile din repo, din directorul ales si o sa inceapa sa le aplice.
Rezultatul ar trebui sa arate asa:

Teoretic ar trebui sa poti accesa uptime kuma, pe ip-ul pe care il aloca metallb… si sa vezi interfata.

Orice schimbare a yaml-urilor din github vor fi semnalate de ArgoCD. Daca ai pus sincronizarea pe automat ar trebui ca orice modificare faci sa fie deployata in Kubernetes automat, sa zicem ca modifici numarul de replici (pod-uri) pentru aplicatia ta.. sau faci un update… Mai jos exemplu:

“BestMan” m-a sfatuit sa ma uit si la ArgoCD. Rachete, magie, gitops, kubernetzi…
Sa incepem cu o traducere:

Argo CD este un instrument declarativ CICD pentru aplicațiile Kubernetes. Acesta utilizează stilul GitOps pentru a crea și gestiona clustere Kubernetes. Atunci când se fac modificări în configurația aplicației din Git, Argo CD o compară cu configurația aplicației care rulează și notifică utilizatorii pentru a sincroniza starea dorită cu cea actuală.
Argo CD a fost dezvoltat în cadrul proiectului Argo al Cloud Native Computing Foundation (CNCF), un proiect destinat în special gestionării ciclului de viață al aplicațiilor Kubernetes. Acest proiect include, de asemenea, Argo Workflow, Argo Rollouts și Argo Events. Fiecare dintre acestea rezolvă un set specific de probleme în procesul de dezvoltare agilă și contribuie la livrarea scalabilă și securizată a aplicațiilor Kubernetes.

Cumva in github pui yaml-urile, asta verifica ce e acolo si face treaba. Asta e magie, ca pana acum stateam cu 20j de fisiere yaml pe nodu de control si le pierdeam, le suprascriam, nu mai stiam care fisier e ce imi trebuie… nah, gandire de sysadmin.
Am deja cont de github, o sa fac un repo nou si o sa il folosesc pentru a instala “Uptime Kuma” cu ArgoCD.

Instalarea ArgoCD e simpla, am facut un namespace nou si am folosit manifestul lor.
kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

Dupa 2-3 minute am vazut si podurile:

Mai devreme am pus MetalLB si as vrea sa il folosesc sa ajung la ArgoCD. Se poate folosi si nodeport dar e mai elegant asa, fara sa accesezi porturi ciudate. Dezavantajul pe care il vad eu pe termen lung o sa trebuiasca sa extinzi pool-ul de ip-uri folosit de metallb. Deci, revenim:
kubectl patch svc argocd-server -n argocd -p '{"spec": {"type": "LoadBalancer"}}'

Teoretic acum ar trebui sa am ArgoCD publicat pe unu din ip-urile alea din loadbalancer, pe porturile 443 si 80.

O sa avem nevoie de parola (userul e admin). Avem o parola random creata la instalare…
kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d
Accesam 192.168.111.220:80, user si parola avem. Iaca!

Avem ArgoCD functional, teoretic putem incepe sa il folosim.
Next post, instalare “Uptime Kuma” cu ArgoCD.

MetalLB este o soluție de LoadBalancer pentru clusterele Kubernetes care de pe infrastructură bare-metal, asa cum am si eu in HomeLab. Spre deosebire de cloud-uri (eks de ex) unde ai deja solutii native… pe onprem (bare metal) ai nevoie de o solutie pentru a expune serviciile catre retea si de acolo… mai departe, pe internet daca este cazul 😀

Instalarea MetalLB

Eu am folosit manifestul lor..
kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/main/config/manifests/metallb-native.yaml
In cateva zeci de secunde se for initializa toate componentele si vom avea ceva de genul
kubectl get pods -n metallb-system

Pentru a configura MetalLB vom avea nevoie de un spatiu de ip-uri din zona in care tinem si nodurile de k8s. Daca avem DHCP va trebui sa rezervam zona aceea… Creaza un fisier de ex metallb-config.yaml si aplica configuratia.

apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  name: default-pool
  namespace: metallb-system
spec:
  addresses:
  - 192.168.111.220-192.168.111.230
---
apiVersion: metallb.io/v1beta1
kind: L2Advertisement
metadata:
  name: l2advertisement
  namespace: metallb-system

kubectl apply -f metallb-config.yaml

Destul de simplu… pentru a vedea logurile metallb

kubectl logs -n metallb-system -l app=metallb

Ca sa ii vedem utilitatea putem sa cream un nginx mic si stingher, facem un yaml nou, nginx-lb.yaml iar la serviciu specificam tipul LoadBalancer.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-lb
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx-lb
  template:
    metadata:
      labels:
        app: nginx-lb
    spec:
      containers:
      - name: nginx
        image: nginx
        ports:
        - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: nginx-lb
  namespace: default
spec:
  selector:
    app: nginx-lb
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
  type: LoadBalancer

Se aplica configuratia, dupa care K8s va crea un POD conform specificatiilor si un serviciu prin care publicam nginx-ul pe portul 80.
kubectl apply -f nginx-lb.yaml

Va trebui sa se regaseasca in lista serviciul si un IP din pool-ul setat mai sus pentru metallb.

Din browser va trebui sa puteti accesa serviciul pe portul 80, pe acel ip.

Easy peasy!