1. Στόχος

Αυτό το έγγραφο περιγράφει την εννοιολογική και λειτουργική αρχιτεκτονική του Kubernetes για ένα πρακτικό εργαστήριο. Δεν ορίζει απλώς όρους· συνδέει τις βασικές έννοιες με λειτουργικές αποφάσεις, συνήθεις αστοχίες και συγκεκριμένα manifests.

Μετά το εργαστήριο, δεν πρέπει πλέον να βλέπεις το Kubernetes ως συλλογή ανεξάρτητων αρχείων YAML, αλλά ως σύστημα ελέγχου βάσει κατάστασης: περιγράφεις μια κατάσταση στόχο, το Kubernetes την επικυρώνει και την αποθηκεύει στο API, ενώ οι Controllers εργάζονται συνεχώς για να εναρμονίσουν την πραγματική κατάσταση με τον στόχο.

Το έγγραφο χρησιμεύει ως:

• Αναφορά για τις ενότητες και τις ασκήσεις του εργαστηρίου.
• Βάση συζητήσεων για την αρχιτεκτονική πλατφόρμας.
• Αφετηρία για troubleshooting και ανάληψη λειτουργικών ευθυνών.
• Βοήθημα αποφάσεων για τον σχεδιασμό workloads, δικτύου, storage και ασφάλειας.

Δεν προορίζεται ως πλήρης οδηγός εγκατάστασης για συγκεκριμένο cloud provider ή distribution όπως AKS, EKS, GKE, OpenShift, Rancher ή k3s. Οι αρχιτεκτονικές αρχές ισχύουν σε όλα τα clusters, ενώ οι επιμέρους υλοποιήσεις μπορεί να διαφέρουν.

2. Μαθησιακοί στόχοι

Αφού μελετήσεις αυτό το υλικό, θα μπορείς να:

• εξηγείς τις ευθύνες του Control Plane, των Worker Nodes και των add-ons,
• παρακολουθείς τη διαδρομή από ένα manifest έως ένα Pod που εκτελείται,
• κατατάσσεις αρχιτεκτονικά τα Deployments, ReplicaSets, Services, ConfigMaps, Secrets, PersistentVolumeClaims και resources Ingress/Gateway,
• αποφασίζεις ποιο Kubernetes object ταιριάζει σε κάθε ανάγκη,
• διερευνάς συστηματικά καταστάσεις αστοχίας όπως ImagePullBackOff, CrashLoopBackOff, Pending, αποτυχημένους ελέγχους readiness ή προβλήματα δικτύου,
• ορίζεις ουσιαστικά Requests, Limits, probes και στρατηγικές rollout,
• τοποθετείς μηχανισμούς ασφάλειας όπως RBAC, ServiceAccounts, Admission Control, Pod Security και NetworkPolicies στο αρχιτεκτονικό τους πλαίσιο,
• τεκμηριώνεις λειτουργικές αποφάσεις αντί να τις κρύβεις έμμεσα σε διάσπαρτα αρχεία YAML.

3. Επισκόπηση αρχιτεκτονικής

3.1. Βασική ιδέα

Το Kubernetes είναι πλατφόρμα εκτέλεσης εφαρμογών σε containers. Περιγράφεις εφαρμογές, διαμόρφωση, πρόσβαση δικτύου, μόνιμη αποθήκευση και δικαιώματα μέσω API objects. Το Kubernetes δέχεται αυτά τα objects και συντονίζει την εκτέλεσή τους σε ένα cluster μηχανών.

Το ουσιαστικό σημείο είναι ότι το Kubernetes δεν ξεκινά απλώς containers. Διαχειρίζεται workloads. Ένα workload περιλαμβάνει Desired State, αποφάσεις scheduling, συμπεριφορά Container Runtime, ταυτότητα δικτύου, διαμόρφωση, ασφάλεια, health checks και πληροφορίες κατάστασης.

flowchart LR
  user[You: manifest, CLI, or GitOps] --> api[Kubernetes API Server]
  api --> store[(etcd: cluster state)]
  api --> controllers[Controllers]
  controllers --> scheduler[Scheduler]
  scheduler --> nodes[Worker Nodes]
  nodes --> pods[Pods and containers]
  pods --> services[Services, DNS, Ingress/Gateway]
  pods --> obs[Logs, events, metrics]
  obs --> user

Το Kubernetes διαχωρίζει αρκετά πεδία ευθύνης:

3.2. Control Plane, Worker Nodes και add-ons

Ένα Kubernetes cluster αποτελείται από Control Plane και έναν ή περισσότερους Worker Nodes.

Το Control Plane διατηρεί την κατάσταση του cluster, επικυρώνει API requests και λαμβάνει κεντρικές αποφάσεις ελέγχου. Οι Worker Nodes εκτελούν Pods. Τα add-ons παρέχουν λειτουργίες που χρειάζεται το Kubernetes ως πλατφόρμα, αλλά δεν ανήκουν απαραίτητα σε έναν ενιαίο πυρήνα.

flowchart TB
  subgraph CP[Control Plane]
    api[kube-apiserver]
    etcd[(etcd)]
    sched[kube-scheduler]
    cm[kube-controller-manager]
    ccm[cloud-controller-manager]
  end

  subgraph W1[Worker Node]
    kubelet1[kubelet]
    proxy1[kube-proxy or eBPF dataplane]
    runtime1[Container Runtime]
    pod1[Pods]
  end

  subgraph ADD[Add-ons]
    dns[CoreDNS]
    ingress[Ingress/Gateway Controller]
    cni[CNI Plugin]
    csi[CSI Driver]
    metrics[Metrics/Logging]
  end

  api <--> etcd
  cm --> api
  sched --> api
  kubelet1 <--> api
  kubelet1 --> runtime1
  runtime1 --> pod1
  pod1 --> dns
  pod1 --> cni
  pod1 --> csi
  ingress --> api

3.3. Reconciliation Loop

Ο κεντρικός μηχανισμός λειτουργίας του Kubernetes είναι το Reconciliation Loop. Οι Controllers παρακολουθούν το API, συγκρίνουν Desired State με Actual State και εκτελούν διορθωτικές ενέργειες.

Παράδειγμα: ορίζεις Deployment με replicas: 3. Αν εκτελούνται μόνο δύο Pods, ο αρμόδιος Controller δημιουργεί άλλο ένα. Αν εκτελούνται τέσσερα Pods, αφαιρεί ένα. Επομένως, το Kubernetes προσανατολίζεται πρωτίστως στην κατάσταση και όχι στις μεμονωμένες εντολές.

flowchart LR
  desired[Desired state\nmanifest in the API] --> compare[Controller compares]
  actual[Actual state\nPods, Nodes, network, storage] --> compare
  compare --> action[Corrective action]
  action --> actual

Για τη λειτουργία αυτό σημαίνει:

• Δεν ερευνάς μόνο τι εκτέλεσες, αλλά και ποια κατάσταση έχει αποθηκευτεί στο API.
• Πολλά προβλήματα δεν προέρχονται από μία εντολή, αλλά από αντικρουόμενα Desired States.
• Οι Controllers δημιουργούν παράγωγα objects. Ένα Deployment δημιουργεί ReplicaSets· τα ReplicaSets δημιουργούν Pods.
• Οι χειροκίνητες αλλαγές σε παράγωγα objects συνήθως δεν διατηρούνται, επειδή ο γονικός Controller τις αντικαθιστά ξανά.

4. Νοητικό μοντέλο Kubernetes

4.1. Desired State

Το Desired State είναι η επιδιωκόμενη κατάσταση ενός resource. Την περιγράφεις σε YAML ή JSON, συνήθως σε YAML. Το Kubernetes αποθηκεύει αυτή την κατάσταση στο etcd και προσπαθεί να εναρμονίσει μαζί της την πραγματική κατάσταση.

Παράδειγμα:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: nginx
          image: nginx:1.27

Με αυτό δεν λες «ξεκίνα τώρα τρία containers». Λες «φρόντιζε συνεχώς να υπάρχουν τρία κατάλληλα Pod replicas». Πρόκειται για θεμελιώδη διαφορά.

4.2. Δηλωτικό API

Το Kubernetes χρησιμοποιεί δηλωτικό API. Περιγράφεις το αποτέλεσμα και όχι κάθε ενδιάμεσο βήμα. Αυτό ταιριάζει με GitOps και Infrastructure as Code, επειδή το Desired State μπορεί να γίνεται versioning και review.

Τυπική ροή εργασίας:

kubectl apply -f deployment.yaml
kubectl get deployment web
kubectl rollout status deployment/web

Σημαντικές συνέπειες:

• Το kubectl apply έχει σχεδιαστεί για επανειλημμένη εφαρμογή manifests.
• Το kubectl create είναι καταλληλότερο για δημιουργία μίας φοράς.
• Το kubectl edit είναι βολικό σε lab, αλλά επικίνδυνο σε παραγωγή, επειδή οι αλλαγές δεν καταγράφονται αυτόματα σε versions.
• GitOps Controllers όπως Argo CD ή Flux αναμένουν το Git να αποτελεί την έγκυρη πηγή του Desired State.

4.3. Resources, objects και Controllers

Ένα resource είναι ένας τύπος του Kubernetes API, για παράδειγμα Pod, Deployment ή Service. Ένα object είναι συγκεκριμένο στιγμιότυπο αυτού του resource, για παράδειγμα deployment/web.

Σχεδόν κάθε object περιέχει:

Συνήθως αλλάζεις το spec, όχι το status. Το status προκύπτει από τη λειτουργία των Controllers και δείχνει τι παρατηρεί το Kubernetes.

4.4. Ονόματα, Labels, selectors και annotations

Τα ονόματα προσδιορίζουν objects μέσα στο πεδίο τους. Ένα όνομα Deployment πρέπει να είναι μοναδικό μέσα στο Namespace.

Τα Labels είναι δομημένα ζεύγη κλειδιού και τιμής που χρησιμεύουν στην επιλογή και ομαδοποίηση objects. Services, ReplicaSets, NetworkPolicies και πολλά άλλα resources χρησιμοποιούν Label selectors.

Τα annotations αποθηκεύουν πρόσθετα metadata που δεν προορίζονται κυρίως για επιλογή. Πολλοί Controllers χρησιμοποιούν annotations για διαμόρφωση, ενσωματώσεις ή υποδείξεις προς εργαλεία.

Παράδειγμα:

metadata:
  name: web
  labels:
    app.kubernetes.io/name: web
    app.kubernetes.io/component: frontend
    app.kubernetes.io/part-of: shop
    environment: workshop
  annotations:
    owner: platform-team
    documentation: "https://example.invalid/runbooks/web"

Σύσταση για το εργαστήριο:

• Χρησιμοποίησε συνεπές σχήμα Labels.
• Χρησιμοποίησε Labels για επιλογή και ομαδοποίηση.
• Χρησιμοποίησε annotations για περιγραφικές πληροφορίες ή δεδομένα συγκεκριμένων εργαλείων.
• Σχεδίασε τους selectors πριν δημιουργήσεις resources. Στα Deployments ο selector αποτελεί ουσιαστικά βασικό μέρος της ταυτότητας του resource και δεν πρέπει να αλλάζει αργότερα.

4.5. Namespaces

Τα Namespaces χωρίζουν λογικά ένα cluster σε περιοχές. Τα χρησιμοποιείς για οργάνωση resources, δικαιωμάτων, quotas, NetworkPolicies και πεδίων ονοματοδοσίας. Ωστόσο, ένα Namespace δεν αποτελεί πλήρες όριο ασφάλειας όπως ένα ξεχωριστό cluster.

Τυπικές στρατηγικές Namespaces:

Για workloads παραγωγής, απόφυγε το default Namespace. Δημιούργησε ρητά Namespaces και τεκμηρίωσε τον υπεύθυνο, τα quotas και την επιτρεπόμενη πρόσβαση.

Παράδειγμα:

apiVersion: v1
kind: Namespace
metadata:
  name: workshop
  labels:
    pod-security.kubernetes.io/enforce: baseline
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/warn: restricted

5. Components

5.1. Control Plane

5.2. Worker Node

5.3. Add-ons του cluster

6. Βασικά Kubernetes objects

7. Από το manifest στο Pod που εκτελείται

Όταν εφαρμόζεις ένα manifest, εκτελούνται πολλά βήματα. Αυτά είναι ουσιαστικά για το troubleshooting.

sequenceDiagram
  participant You
  participant API as kube-apiserver
  participant Etcd as etcd
  participant Ctrl as Controller
  participant Sched as Scheduler
  participant Kubelet as kubelet
  participant Runtime as Container Runtime

  You->>API: kubectl apply -f deployment.yaml
  API->>API: Authentication, authorization, admission, validation
  API->>Etcd: Store object
  Ctrl->>API: Watch Deployment
  Ctrl->>API: Create ReplicaSet and Pods
  Sched->>API: Watch unscheduled Pods
  Sched->>API: Set Node binding
  Kubelet->>API: Fetch PodSpec for its own Node
  Kubelet->>Runtime: Pull images, start containers
  Runtime-->>Kubelet: Status and logs
  Kubelet->>API: Update PodStatus

Σημαντικά σημεία διάγνωσης:

8. Workloads, Deployments και updates

8.1. Pods ως μικρότερη μονάδα

Ένα Pod είναι η μικρότερη μονάδα που μπορεί να εκτελέσει απευθείας το Kubernetes. Περιέχει ένα ή περισσότερα containers που μοιράζονται ένα Network Namespace, μια IP και, προαιρετικά, volumes.

Στην πράξη, ένα Pod περιέχει συνήθως ακριβώς ένα application container. Χρησιμοποίησε περισσότερα containers σε ένα Pod μόνο όταν συνδέονται στενά και πρέπει να εκτελούνται μαζί στο ίδιο Node.

Συνήθη μοτίβα πολλών containers:

Τα Pods είναι εκ φύσεως βραχύβια. Όταν διαγραφεί ένα Pod, το Pod αντικατάστασης αποκτά νέο UID και συνήθως νέα IP. Γι’ αυτό δεν πρέπει να απευθύνεσαι απευθείας σε Pods· χρησιμοποίησε Services, Labels και Controllers.

8.2. ReplicaSets και Deployments

Ένα ReplicaSet εξασφαλίζει ότι εκτελείται συγκεκριμένος αριθμός πανομοιότυπων Pods. Ένα Deployment διαχειρίζεται ReplicaSets και προσφέρει επιπλέον δυνατότητες, όπως rollouts, rollbacks και ιστορικό rollouts.

Στο εργαστήριο θα χρησιμοποιείς σχεδόν πάντα Deployments για stateless εφαρμογές και όχι ReplicaSets απευθείας.

flowchart TB
  dep[Deployment] --> rs1[ReplicaSet Revision 1]
  dep --> rs2[ReplicaSet Revision 2]
  rs1 --> oldpods[old Pods]
  rs2 --> newpods[new Pods]

Βασικοί κανόνες:

• Άλλαξε το Pod template ενός Deployment όταν θέλεις να προκαλέσεις νέο rollout.
• Κλιμάκωσε μέσω spec.replicas ή Autoscaler.
• Μην επεξεργάζεσαι Pods που δημιουργεί ένα Deployment ως μόνιμη λύση.
• Επίλεξε συνειδητά Labels και selectors, επειδή καθορίζουν τη σχέση μεταξύ Deployment, ReplicaSet, Pods και Service.

8.3. Rolling updates και rollbacks

Ένα rolling update αντικαθιστά σταδιακά παλιά Pods με νέα. Έτσι η εφαρμογή μπορεί να παραμένει διαθέσιμη κατά τη διάθεση νέας έκδοσης.

Σημαντικές παράμετροι:

Χρήσιμες εντολές:

kubectl rollout status deployment/web -n workshop
kubectl rollout history deployment/web -n workshop
kubectl rollout undo deployment/web -n workshop
kubectl describe deployment web -n workshop

Αν ένα rollout κολλήσει, εξέτασε πρώτα τα νέα Pods:

kubectl get pods -n workshop -l app=web
kubectl describe pod <pod-name> -n workshop
kubectl logs <pod-name> -n workshop

8.4. Παράδειγμα: Deployment με πόρους και probes

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
  namespace: workshop
  labels:
    app.kubernetes.io/name: web
    app.kubernetes.io/component: frontend
spec:
  replicas: 3
  revisionHistoryLimit: 5
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1
      maxSurge: 1
  selector:
    matchLabels:
      app.kubernetes.io/name: web
      app.kubernetes.io/component: frontend
  template:
    metadata:
      labels:
        app.kubernetes.io/name: web
        app.kubernetes.io/component: frontend
    spec:
      containers:
        - name: web
          image: nginx:1.27
          ports:
            - name: http
              containerPort: 80
          resources:
            requests:
              cpu: 100m
              memory: 128Mi
            limits:
              cpu: 500m
              memory: 256Mi
          startupProbe:
            httpGet:
              path: /
              port: http
            failureThreshold: 30
            periodSeconds: 2
          readinessProbe:
            httpGet:
              path: /
              port: http
            initialDelaySeconds: 3
            periodSeconds: 5
          livenessProbe:
            httpGet:
              path: /
              port: http
            initialDelaySeconds: 10
            periodSeconds: 10

Αξιολόγηση του παραδείγματος:

• Τα requests δίνουν στον Scheduler αξιόπιστη βάση για αποφάσεις τοποθέτησης.
• Τα limits εμποδίζουν απεριόριστη χρήση πόρων, αλλά τα CPU Limits μπορούν επίσης να προκαλέσουν throttling.
• Το startupProbe προστατεύει εφαρμογές με αργή εκκίνηση από πρόωρα restarts λόγω liveness.
• Το readinessProbe ελέγχει αν το Pod πρέπει να λαμβάνει κίνηση.
• Το livenessProbe πρέπει να εντοπίζει μόνο πραγματικά deadlocks ή καταστάσεις που δεν αυτοδιορθώνονται.

9. Αρχιτεκτονική δικτύου

9.1. Μοντέλο δικτύου Kubernetes

Το Kubernetes θεωρεί ότι το δίκτυο Pods είναι επίπεδο: κάθε Pod μπορεί, κατ’ αρχήν, να προσεγγίζει κάθε άλλο Pod μέσω της Pod IP του χωρίς Network Address Translation σε επίπεδο Pod. Η τεχνική υλοποίηση αυτού του μοντέλου εξαρτάται από το CNI plugin.

Σημαντικά επίπεδα δικτύου:

9.2. Services και Service Discovery

Τα Pods είναι βραχύβια και λαμβάνουν νέες IP. Τα Services παρέχουν σταθερή αφαίρεση πάνω από μια ομάδα Pods.

Παράδειγμα:

apiVersion: v1
kind: Service
metadata:
  name: web
  namespace: workshop
spec:
  type: ClusterIP
  selector:
    app.kubernetes.io/name: web
    app.kubernetes.io/component: frontend
  ports:
    - name: http
      port: 80
      targetPort: http

Τύποι Service:

Τα ονόματα DNS ακολουθούν συνήθως το μοτίβο:

<service>.<namespace>.svc.cluster.local

Για Service με όνομα web στο Namespace workshop, προκύπτει:

web.workshop.svc.cluster.local

Μέσα στο ίδιο Namespace, συχνά αρκεί το web, επειδή η λίστα αναζήτησης DNS του Pod συμπληρώνεται αυτόματα.

9.3. Ingress και Gateway API

Το Ingress περιγράφει HTTP και HTTPS routing από έξω προς Services μέσα στο cluster. Ένα Ingress object έχει αποτέλεσμα μόνο όταν έχει εγκατασταθεί αντίστοιχος Ingress Controller.

Παράδειγμα:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: web
  namespace: workshop
spec:
  ingressClassName: nginx
  rules:
    - host: web.example.invalid
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: web
                port:
                  number: 80

Για νέες αρχιτεκτονικές πλατφόρμας πρέπει επίσης να αξιολογείς το Gateway API. Αυτό το API διαχωρίζει σαφέστερα τους ρόλους και εκφράζει περισσότερες δυνατότητες από το κλασικό Ingress, ιδιαίτερα όταν διαφορετικές ομάδες έχουν την ευθύνη για υποδομή, routing και εφαρμογές.

Εννοιολογική διαφορά:

9.4. NetworkPolicies

Χωρίς NetworkPolicies, πολλά clusters επιτρέπουν από προεπιλογή την επικοινωνία μεταξύ Pods. Μια NetworkPolicy καθορίζει ποια εισερχόμενη ή εξερχόμενη κίνηση επιτρέπεται για τα επιλεγμένα Pods. Η εφαρμογή της εξαρτάται από το CNI plugin.

Παράδειγμα: μόνο Pods με Label app.kubernetes.io/name: web επιτρέπεται να προσεγγίζουν database στο port 5432.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-web-to-db
  namespace: workshop
spec:
  podSelector:
    matchLabels:
      app.kubernetes.io/name: db
  policyTypes:
    - Ingress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app.kubernetes.io/name: web
      ports:
        - protocol: TCP
          port: 5432

Λειτουργικοί κανόνες:

• Έλεγξε αν το CNI σου υποστηρίζει πράγματι NetworkPolicies.
• Ξεκίνα με σαφείς πολιτικές default deny, αλλά σχεδίασε συνειδητά τις εξαιρέσεις.
• Συνυπολόγισε το DNS egress όταν εισάγεις πολιτικές Egress.
• Τεκμηρίωσε τις επιτρεπόμενες διαδρομές επικοινωνίας ως μέρος της αρχιτεκτονικής εφαρμογής.

10. Storage και μόνιμη αποθήκευση

Τα filesystems των containers είναι προσωρινά. Όταν αντικαθίσταται ένα Pod, δεν πρέπει να υποθέτεις ότι διατηρούνται τα τοπικά δεδομένα. Το Kubernetes διαχωρίζει επομένως τα workloads από το storage μέσω Volumes, PersistentVolumes και PersistentVolumeClaims.

Σημαντικοί όροι:

Παράδειγμα PVC:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: data
  namespace: workshop
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: standard
  resources:
    requests:
      storage: 10Gi

Τυπικά ερωτήματα αρχιτεκτονικής:

• Είναι η εφαρμογή stateless ή stateful;
• Πρέπει το storage να είναι διαθέσιμο μεταξύ ζωνών ή περιοχών;
• Ποιο accessMode απαιτείται: ReadWriteOnce, ReadOnlyMany, ReadWriteMany ή ReadWriteOncePod;
• Τι συμβαίνει όταν διαγράφεται ένα PVC;
• Πώς δοκιμάζονται backups, restores και migrations;
• Ποια καθυστέρηση και πόσα IOPS χρειάζεται πραγματικά η εφαρμογή;

Η λειτουργία databases μέσα σε Kubernetes cluster απαιτεί πολύ περισσότερο αρχιτεκτονικό σχεδιασμό από τη λειτουργία stateless web υπηρεσιών. Τα StatefulSets λύνουν ζητήματα ταυτότητας και ταξινομημένης εκκίνησης, αλλά δεν αντικαθιστούν σχέδιο backup, στρατηγική replication ή διαδικασία disaster recovery.

11. Διαμόρφωση και Secrets

Η διαμόρφωση δεν πρέπει να ενσωματώνεται στο container image. Το Kubernetes διαχωρίζει τον κώδικα εφαρμογής, τη μη ευαίσθητη διαμόρφωση και τα ευαίσθητα δεδομένα.

Παράδειγμα ConfigMap:

apiVersion: v1
kind: ConfigMap
metadata:
  name: web-config
  namespace: workshop
data:
  LOG_LEVEL: "info"
  FEATURE_CHECKOUT: "enabled"

Παράδειγμα Secret:

apiVersion: v1
kind: Secret
metadata:
  name: database-credentials
  namespace: workshop
type: Opaque
stringData:
  username: app
  password: change-me-in-real-life

Χρήση σε Pod:

envFrom:
  - configMapRef:
      name: web-config
env:
  - name: DB_PASSWORD
    valueFrom:
      secretKeyRef:
        name: database-credentials
        key: password

Λειτουργικές οδηγίες:

• Τα Secrets δεν ισοδυναμούν αυτόματα με ισχυρό encryption. Σχεδίασε encryption at rest, RBAC, audit και, όπου χρειάζεται, εξωτερικά Secret stores.
• Τα updates ConfigMap και Secret συμπεριφέρονται διαφορετικά ανάλογα με τον τρόπο mounting ή injection. Τα environment variables ανανεώνονται μόνο με restart του Pod· τα mounted files μπορούν να ενημερώνονται, αλλά όχι άμεσα σε κάθε ειδική περίπτωση.
• Απόφυγε την έκθεση Secrets σε logs, Events, command-line arguments και έξοδο CI.
• Χρησιμοποίησε ξεχωριστά Secrets ανά εφαρμογή και σκοπό, όχι ένα γενικό Secret για όλα.

12. Διαχείριση πόρων και scheduling

12.1. Requests, Limits και QoS

Το Kubernetes κάνει scheduling Pods βάσει των Requests. Τα Limits περιορίζουν τη μέγιστη χρήση.

Παράδειγμα:

resources:
  requests:
    cpu: 250m
    memory: 256Mi
  limits:
    cpu: 1000m
    memory: 512Mi

Κλάσεις QoS:

Κανόνας εργαστηρίου: όριζε πάντα Requests σε παραδείγματα αντίστοιχα της παραγωγής. Χωρίς Requests ο Scheduler δεν μπορεί να λάβει ρεαλιστικές αποφάσεις χωρητικότητας.

12.2. Επιλογή Node, Affinity και Taints

Ο Scheduler επιλέγει Nodes βάσει πολλών κριτηρίων. Μπορείς να επηρεάσεις αυτή την επιλογή.

Παράδειγμα Toleration:

tolerations:
  - key: "workload"
    operator: "Equal"
    value: "platform"
    effect: "NoSchedule"

Παράδειγμα Node Affinity:

affinity:
  nodeAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      nodeSelectorTerms:
        - matchExpressions:
            - key: topology.kubernetes.io/zone
              operator: In
              values:
                - eu-central-1a
                - eu-central-1b

12.3. Quotas και Limits ανά Namespace

Τα ResourceQuotas περιορίζουν τη συνολική κατανάλωση πόρων ενός Namespace. Τα LimitRanges μπορούν να ορίζουν προεπιλογές ή ελάχιστες και μέγιστες τιμές για Pods και containers.

Παράδειγμα ResourceQuota:

apiVersion: v1
kind: ResourceQuota
metadata:
  name: workshop-quota
  namespace: workshop
spec:
  hard:
    requests.cpu: "4"
    requests.memory: 8Gi
    limits.cpu: "8"
    limits.memory: 16Gi
    pods: "20"

Αρχιτεκτονική σημείωση: τα quotas δεν προστατεύουν από κάθε μορφή υπερφόρτωσης, αλλά αποτρέπουν ένα Namespace από απεριόριστη κατανάλωση πόρων ή δημιουργία objects.

12.4. Autoscaling και Disruption Budgets

Το Horizontal Pod Autoscaler κλιμακώνει replicas βάσει παρατηρούμενων metrics. Για αυτό χρειάζονται κατάλληλες πηγές metrics και ουσιαστικά Requests.

Παράδειγμα HPA:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: web
  namespace: workshop
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web
  minReplicas: 2
  maxReplicas: 10
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70

Ένα PodDisruptionBudget περιορίζει προγραμματισμένες διακοπές, για παράδειγμα κατά τη συντήρηση Node:

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: web
  namespace: workshop
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app.kubernetes.io/name: web
      app.kubernetes.io/component: frontend

Σημαντικό: ένα PDB δεν προστατεύει από όλες τις αστοχίες. Εφαρμόζεται κυρίως σε προγραμματισμένες διακοπές όπως kubectl drain, όχι σε απρόβλεπτη αστοχία Node.

13. Health checks και κύκλος ζωής

Το Kubernetes παρέχει διαφορετικούς τύπους probes. Δεν πρέπει να τους θεωρείς εναλλάξιμους.

Απλοποιημένος κύκλος ζωής Pod:

stateDiagram-v2
  [*] --> Pending
  Pending --> Running
  Running --> Succeeded
  Running --> Failed
  Running --> Terminating
  Terminating --> [*]

Λειτουργικοί κανόνες:

• Το readiness πρέπει να ελέγχει εξαρτήσεις σημαντικές για την αποδοχή κίνησης.
• Το liveness πρέπει να ελέγχει μόνο καταστάσεις που πιθανότατα διορθώνονται με restart.
• Τα startup probes είναι χρήσιμα για αργές εφαρμογές, JVMs, migrations ή μεγάλη αρχική φόρτωση cache.
• Τα ίδια τα probes δεν πρέπει να υπερφορτώνουν την εφαρμογή.
• Τα probe endpoints πρέπει να απαντούν γρήγορα και προβλέψιμα και, ιδανικά, να αποφεύγουν ακριβές queries.

14. Ασφάλεια

14.1. Πρόσβαση στο Kubernetes API

Ο API Server είναι το κεντρικό σημείο ελέγχου. Κάθε request περνά από διάφορες φάσεις:

1. Authentication: ποιος υποβάλλει το request;
2. Authorization: επιτρέπεται σε αυτή την identity να εκτελέσει την ενέργεια;
3. Admission Control: γίνεται δεκτό, απορρίπτεται ή μεταβάλλεται το object;
4. Persistence: αποθηκεύεται η νέα κατάσταση στο etcd;

flowchart LR
  req[API request] --> authn[Authentication]
  authn --> authz[Authorization]
  authz --> adm[Admission Control]
  adm --> val[Validation]
  val --> etcd[(etcd)]

Για τοπική πρόσβαση το kubectl χρησιμοποιεί kubeconfig. Ένα kubeconfig περιέχει πληροφορίες cluster, user και context. Αντιμετώπισε τα αρχεία kubeconfig ως ευαίσθητα credentials.

14.2. RBAC και ServiceAccounts

Το RBAC ορίζει ποια subjects επιτρέπεται να εκτελούν ποια verbs σε ποια resources.

Παράδειγμα: ένα ServiceAccount μπορεί να διαβάζει Pods στο Namespace.

apiVersion: v1
kind: ServiceAccount
metadata:
  name: pod-reader
  namespace: workshop
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: pod-reader
  namespace: workshop
rules:
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: pod-reader
  namespace: workshop
subjects:
  - kind: ServiceAccount
    name: pod-reader
    namespace: workshop
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: pod-reader

Λειτουργικοί κανόνες:

• Παραχώρησε τα ελάχιστα απαιτούμενα δικαιώματα.
• Απόφυγε wildcards όπως *, εκτός αν είναι απολύτως απαραίτητα.
• Έλεγξε δικαιώματα με kubectl auth can-i.
• Δώσε σε workloads δικά τους ServiceAccounts αντί να χρησιμοποιούν ανεξέλεγκτα το default ServiceAccount.
• Πρόσεξε ιδιαίτερα δικαιώματα σε secrets, nodes, pods/exec, pods/attach, roles, rolebindings, clusterroles και clusterrolebindings.

14.3. Admission Control και Pod Security

Οι Admission Controllers ελέγχουν API requests μετά το authentication και authorization, αλλά πριν από την αποθήκευση. Μπορούν να επικυρώνουν ή να μεταβάλλουν objects.

Τυπικές χρήσεις:

• Επιβολή Labels και metadata υπευθυνότητας.
• Αποκλεισμός Privileged containers.
• Επιβολή Resource Requests.
• Αποκλεισμός images από μη εγκεκριμένα registries.
• Ορισμός προεπιλεγμένων τιμών.
• Έλεγχος Pod Security Standards.

Το Pod Security Admission μπορεί να ορίζει επίπεδα ασφάλειας σε Namespaces μέσω Labels:

Παράδειγμα Namespace Labels:

metadata:
  labels:
    pod-security.kubernetes.io/enforce: baseline
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/warn: restricted

14.4. Προστασία Secrets

Τα Secrets απαιτούν τεχνικά και οργανωτικά μέτρα προστασίας.

Λίστα ελέγχου:

• Ενεργοποίησε encryption at rest για Secrets στο cluster.
• Περιόρισε αυστηρά δικαιώματα get, list και watch σε Secrets.
• Απόφυγε τιμές Secrets σε environment variables όταν process lists, dumps ή debugging μπορούν να τις εκθέσουν.
• Προτίμησε εξωτερικά Secret stores όταν το απαιτούν η διακυβέρνηση, το rotation και το audit.
• Επαλήθευσε ότι τα συστήματα backup αποθηκεύουν Secrets κρυπτογραφημένα.
• Κάνε rotation των Secrets και τεκμηρίωσέ το ως λειτουργική διαδικασία.

14.5. Ασφάλεια images και supply chain

Το Kubernetes εκτελεί τα images στα οποία παραπέμπεις. Η πλατφόρμα δεν εξαλείφει αυτόματα όλους τους κινδύνους σχετικά με την προέλευση και το περιεχόμενό τους.

Συστάσεις:

• Χρησιμοποίησε αξιόπιστα registries.
• Προτίμησε αμετάβλητες αναφορές images μέσω digests αντί μόνο για tags.
• Έλεγξε images για γνωστές ευπάθειες.
• Υπόγραψε images ή επαλήθευσε υπογραφές όπου το υποστηρίζει η πλατφόρμα σου.
• Απόφυγε το latest σε manifests παραγωγής.
• Όρισε συνειδητά το imagePullPolicy.
• Χρησιμοποίησε μικρά base images και αφαίρεσε περιττά εργαλεία.

15. Observability

Το Kubernetes προσφέρει πολλά επίπεδα observability. Κανένα επίπεδο δεν αρκεί από μόνο του.

Ελάχιστη προσέγγιση observability στο εργαστήριο:

kubectl get all -n workshop
kubectl get events -n workshop --sort-by=.lastTimestamp
kubectl describe deployment web -n workshop
kubectl describe pod <pod-name> -n workshop
kubectl logs <pod-name> -n workshop
kubectl top pods -n workshop

Για παραγωγή χρειάζεσαι επιπλέον:

• κεντρική αποθήκευση logs,
• metrics με alerts,
• dashboards βασισμένα σε Service Level Indicators,
• audit logs,
• runbooks,
• σαφή υπεύθυνο για κάθε Namespace και εφαρμογή.

16. Αντιμετώπιση προβλημάτων

16.1. Συστηματική προσέγγιση

Χρησιμοποίησε σταθερή σειρά βημάτων ώστε να μη διερευνάς τυχαία.

1. Έλεγξε το context.

   bashΑντιγραφή κώδικα

   kubectl config current-context
   kubectl config view --minify
   kubectl get ns
   

2. Έλεγξε τα objects στο Namespace.

   bashΑντιγραφή κώδικα

   kubectl get all -n workshop
   kubectl get deploy,rs,pods,svc,endpointslice -n workshop
   

3. Διάβασε τα Events.

   bashΑντιγραφή κώδικα

   kubectl get events -n workshop --sort-by=.lastTimestamp
   

4. Εξέτασε λεπτομερώς το επηρεαζόμενο object.

   bashΑντιγραφή κώδικα

   kubectl describe pod <pod-name> -n workshop
   

5. Έλεγξε τα logs.

   bashΑντιγραφή κώδικα

   kubectl logs <pod-name> -n workshop
   kubectl logs <pod-name> -n workshop --previous
   

6. Κατανόησε την αλυσίδα Owners.

   bashΑντιγραφή κώδικα

   kubectl get pod <pod-name> -n workshop -o yaml | grep -A 10 ownerReferences
   

7. Δοκίμασε το δίκτυο μεμονωμένα.

   bashΑντιγραφή κώδικα

   kubectl run debug -n workshop --rm -it --image=curlimages/curl -- sh
   

16.2. Συνήθεις αστοχίες

16.3. Χρήσιμες εντολές kubectl

# Επισκόπηση
kubectl get nodes -o wide
kubectl get pods -A -o wide
kubectl get all -n workshop

# Κατάσταση και Events
kubectl describe pod <pod-name> -n workshop
kubectl get events -n workshop --sort-by=.lastTimestamp

# Logs
kubectl logs <pod-name> -n workshop
kubectl logs <pod-name> -n workshop --previous
kubectl logs deployment/web -n workshop

# Rollouts
kubectl rollout status deployment/web -n workshop
kubectl rollout history deployment/web -n workshop
kubectl rollout undo deployment/web -n workshop

# Labels και selectors
kubectl get pods -n workshop --show-labels
kubectl get pods -n workshop -l app.kubernetes.io/name=web

# Services και Endpoints
kubectl get svc,endpointslice -n workshop
kubectl describe svc web -n workshop

# Εμφάνιση YAML
kubectl get deployment web -n workshop -o yaml
kubectl explain deployment.spec.template.spec.containers.resources

# Έλεγχος δικαιωμάτων
kubectl auth can-i get pods -n workshop
kubectl auth can-i list secrets -n workshop --as=system:serviceaccount:workshop:pod-reader

# Εκκίνηση debug Pod
kubectl run debug -n workshop --rm -it --image=busybox:1.36 -- sh

17. Αρχιτεκτονικές αποφάσεις

Τεκμηρίωσε τις αρχιτεκτονικές αποφάσεις ρητά. Τα Kubernetes manifests δείχνουν τι έχει διαμορφωθεί, αλλά όχι πάντα γιατί έγινε αυτή η επιλογή.

Καθοδηγητικές ερωτήσεις:

Desired State και ευθύνη

• Πού βρίσκεται το έγκυρο Desired State: στο Git, σε σύστημα CI/CD, σε Helm repository, σε GitOps Controller ή σε χειροκίνητες αλλαγές API;
• Ποιος επιτρέπεται να αλλάζει manifests παραγωγής;
• Πώς γίνονται review, δοκιμή και rollout των αλλαγών;
• Πώς εκτελούνται rollbacks;

Μοντέλο Namespaces και tenants

• Ποια Namespaces υπάρχουν και ποιος έχει την ευθύνη τους;
• Χωρίζονται ανά ομάδα, εφαρμογή, περιβάλλον ή tenant;
• Ποια Quotas και LimitRanges ισχύουν;
• Ποια NetworkPolicies ισχύουν από προεπιλογή;

Μοντέλο workloads

• Είναι η εφαρμογή stateless ή stateful;
• Αρκεί Deployment ή χρειάζεσαι StatefulSet, DaemonSet, Job ή CronJob;
• Ποιος είναι ο ελάχιστος απαιτούμενος αριθμός replicas;
• Ποια στρατηγική update είναι αποδεκτή;
• Πώς διατηρείται η διαθεσιμότητα κατά τη συντήρηση;

Πόροι

• Ποια Requests και Limits είναι ρεαλιστικά;
• Πώς δοκιμάζεται το φορτίο;
• Υπάρχει HPA, VPA ή Cluster Autoscaler;
• Πώς εντοπίζεις CPU throttling, OOMKills και πίεση πόρων σε Node;

Δίκτυο

• Ποια Services πρέπει να είναι προσβάσιμα εσωτερικά;
• Ποια εξωτερικά endpoints υπάρχουν;
• Χρησιμοποιείται Ingress ή Gateway API;
• Ποια στρατηγική TLS ισχύει;
• Ποιες διαδρομές επικοινωνίας επιτρέπονται μέσω NetworkPolicies;

Storage

• Ποια δεδομένα πρέπει να διατηρούνται μόνιμα;
• Ποια StorageClass χρησιμοποιείται;
• Ποιες διαδικασίες backup και restore έχουν δοκιμαστεί;
• Τι συμβαίνει σε αστοχία ζώνης ή Node;
• Ποια δεδομένα μπορούν να διαγραφούν και ποια όχι;

Ασφάλεια

• Ποια ServiceAccounts χρησιμοποιεί η εφαρμογή;
• Ποια δικαιώματα RBAC απαιτούνται πραγματικά;
• Ποιες Admission Policies ισχύουν;
• Πώς δημιουργούνται, αποθηκεύονται, ανανεώνονται και ελέγχονται τα Secrets;
• Ποια images επιτρέπεται να χρησιμοποιούνται;

Observability και λειτουργία

• Ποια logs, metrics και traces είναι υποχρεωτικά;
• Ποια alerts δείχνουν πραγματική επίδραση στους χρήστες και όχι μόνο τεχνικά συμπτώματα;
• Υπάρχουν runbooks;
• Ποιος ανταποκρίνεται σε incidents;
• Πώς μαθαίνει η ομάδα από incidents;

18. Ασκήσεις εργαστηρίου

Οι ακόλουθες ασκήσεις αντιστοιχούν σε αυτό το υλικό. Μπορείς να τις εκτελέσεις με τη σειρά ή να επιλέξεις μεμονωμένες ενότητες.

Άσκηση 1: Δημιουργία Namespace και βασικού επιπέδου

Στόχος: δημιούργησε ξεχωριστό Namespace και επαλήθευσε το context σου.

kubectl create namespace workshop
kubectl config set-context --current --namespace=workshop
kubectl get ns

Συζήτηση:

• Γιατί ένα ξεχωριστό Namespace είναι προτιμότερο από το default;
• Ποια Labels θα όριζες για υπευθυνότητα και Pod Security;

Άσκηση 2: Rollout ενός Deployment

Στόχος: δημιούργησε Deployment με τρία replicas και παρατήρησε την αλυσίδα Controllers.

kubectl apply -f deployment.yaml
kubectl get deploy,rs,pods -n workshop
kubectl rollout status deployment/web -n workshop

Συζήτηση:

• Ποια objects δημιούργησες απευθείας;
• Ποια objects προέκυψαν από το Kubernetes;
• Τι συμβαίνει αν διαγράψεις χειροκίνητα ένα Pod;

Άσκηση 3: Δοκιμή Service Discovery

Στόχος: δημιούργησε Service και δοκίμασε το DNS από debug Pod.

kubectl apply -f service.yaml
kubectl run debug --rm -it --image=curlimages/curl -- sh
curl http://web.workshop.svc.cluster.local

Συζήτηση:

• Γιατί απευθύνεσαι στο Service αντί στις IP των Pods;
• Πώς γνωρίζεις αν ένα Service έχει Endpoints;

Άσκηση 4: Σκόπιμη δημιουργία αστοχίας

Στόχος: άλλαξε το image σε ανύπαρκτο tag και ανάλυσε το σφάλμα.

kubectl set image deployment/web web=nginx:does-not-exist -n workshop
kubectl rollout status deployment/web -n workshop
kubectl get pods -n workshop
kubectl describe pod <pod-name> -n workshop

Συζήτηση:

• Πού εμφανίζεται το πραγματικό μήνυμα σφάλματος;
• Γιατί μπορεί το Deployment να παραμένει εν μέρει διαθέσιμο;
• Πώς εκτελείς rollback;

Άσκηση 5: Κατανόηση Readiness και Liveness

Στόχος: όρισε σκόπιμα λανθασμένο readiness probe και παρατήρησε τα Endpoints του Service.

kubectl get endpointslice -n workshop
kubectl describe pod <pod-name> -n workshop

Συζήτηση:

• Γιατί εκτελείται το container αλλά δεν λαμβάνει κίνηση;
• Ποια είναι η διαφορά Readiness και Liveness;

Άσκηση 6: Έλεγχος RBAC

Στόχος: δημιούργησε ServiceAccount με ελάχιστα δικαιώματα και επαλήθευσε την πρόσβαση.

kubectl auth can-i list pods -n workshop --as=system:serviceaccount:workshop:pod-reader
kubectl auth can-i list secrets -n workshop --as=system:serviceaccount:workshop:pod-reader

Συζήτηση:

• Γιατί το list secrets είναι ιδιαίτερα ευαίσθητο;
• Πότε χρειάζεσαι Role και πότε ClusterRole;

Άσκηση 7: Εισαγωγή NetworkPolicy

Στόχος: περιόρισε την επικοινωνία και επαλήθευσε αν το CNI σου εφαρμόζει τις πολιτικές.

kubectl apply -f networkpolicy.yaml
kubectl get networkpolicy -n workshop

Συζήτηση:

• Τι συμβαίνει σε CNI χωρίς υποστήριξη NetworkPolicy;
• Ποιες εξαιρέσεις Egress χρειάζεσαι για DNS;

19. Πεδίο εφαρμογής και όρια

Το Kubernetes δεν ταυτίζεται με τα εργαλεία και τις πλατφόρμες γύρω του. Μια καθαρή αρχιτεκτονική διαχωρίζει τις ευθύνες.

20. Γλωσσάρι

21. Επίσημες πηγές

Αυτό το υλικό βασίζεται στην επίσημη τεκμηρίωση Kubernetes. Για λεπτομέρειες και διαφορές ανά έκδοση, συμβουλεύσου την τεκμηρίωση της έκδοσης Kubernetes που χρησιμοποιείς.

• Kubernetes Components: https://kubernetes.io/docs/concepts/overview/components/
• Pods: https://kubernetes.io/docs/concepts/workloads/pods/
• Pod Lifecycle: https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/
• Deployments: https://kubernetes.io/docs/concepts/workloads/controllers/deployment/
• Services: https://kubernetes.io/docs/concepts/services-networking/service/
• DNS for Services and Pods: https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/
• Ingress: https://kubernetes.io/docs/concepts/services-networking/ingress/
• Gateway API: https://kubernetes.io/docs/concepts/services-networking/gateway/
• Network Policies: https://kubernetes.io/docs/concepts/services-networking/network-policies/
• ConfigMaps: https://kubernetes.io/docs/concepts/configuration/configmap/
• Secrets: https://kubernetes.io/docs/concepts/configuration/secret/
• Resource Management for Pods and Containers: https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/
• Labels and Selectors: https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/
• Namespaces: https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/
• RBAC Good Practices: https://kubernetes.io/docs/concepts/security/rbac-good-practices/
• Pod Security Admission: https://kubernetes.io/docs/concepts/security/pod-security-admission/
• Good practices for Kubernetes Secrets: https://kubernetes.io/docs/concepts/security/secrets-good-practices/
• Horizontal Pod Autoscaling: https://kubernetes.io/docs/concepts/workloads/autoscaling/horizontal-pod-autoscale/
• Pod Disruption Budgets: https://kubernetes.io/docs/tasks/run-application/configure-pdb/