1. Σκοπός

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

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

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

Τι θα μπορείτε να κάνετε μετά το workshop

Αφού μελετήσετε το έγγραφο, θα μπορείτε να:

• συντάσσετε Kubernetes Manifests με συνεπή δομή,
• πραγματοποιείτε Rollout και Rollback των Deployments με ασφάλεια,
• διακρίνετε σωστά τους ρόλους των Services, Ingress, Gateway API και NetworkPolicies,
• ορίζετε τεκμηριωμένες απαιτήσεις πόρων και συμπεριφορά Scaling,
• χρησιμοποιείτε RBAC, ServiceAccounts, Secrets και Pod Security Standards με σωστή αρχιτεκτονική λογική,
• αναλύετε συστηματικά συνηθισμένες αστοχίες με το kubectl,
• εφαρμόζετε λίστες ελέγχου ανασκόπησης σε πραγματικά έργα.

Πεδίο εφαρμογής

Οι πρακτικές ισχύουν είτε εκτελείτε Kubernetes τοπικά είτε σε δικό σας Data Center είτε μέσω παρόχου Cloud. Για τη συγκεκριμένη πλατφόρμα που χρησιμοποιείτε πρέπει να προσθέτετε λεπτομέρειες όπως η υλοποίηση LoadBalancer, ο CSI Driver, το CNI Plugin, η ενσωμάτωση IAM, το Managed Control Plane και η σύνδεση με Registry.

2. Κατευθυντήριες αρχές

Το Kubernetes λειτουργεί πιο αξιόπιστα όταν ακολουθείτε ένα μικρό σύνολο βασικών αρχών.

Πρακτικός κανόνας

Μια λύση Kubernetes δεν θεωρείται καλή μόνο επειδή εκτελείται ένα Pod. Πρέπει επίσης να μπορείτε να εξηγήσετε γιατί εκτελείται, να αναπαραγάγετε τη ρύθμισή του, να το ασφαλίσετε, να το παρακολουθήσετε και να αναιρέσετε τις αλλαγές του.

3. Πρότυπα για Manifests και Git projects

3.1. Εργαστείτε δηλωτικά

Ορίστε τους πόρους σε Manifests και διαχειριστείτε τα αρχεία τους με Version Control. Αποφεύγετε χειροκίνητες αλλαγές στο Cluster που δεν μπορούν να αντιστοιχιστούν στην πηγή Git του έργου σας.

Βέλτιστη πρακτική

• Διατηρείτε όλους τους πόρους που αφορούν production ως YAML, Helm Charts, Kustomize Overlays ή GitOps Configuration.
• Χρησιμοποιείτε kubectl apply ή εργαλείο GitOps· μη βασίζεστε μόνιμα στο kubectl edit.
• Ελέγχετε τις αλλαγές εκ των προτέρων με kubectl diff και --dry-run=server.
• Τεκμηριώνετε ποια πηγή είναι authoritative: το Git project, το Helm Release, ο GitOps Controller ή άλλο σύστημα Deployment.

Ορθός έλεγχος

kubectl diff -f k8s/
kubectl apply --dry-run=server -f k8s/
kubectl apply -f k8s/

Ανεπαρκής πρακτική

kubectl edit deployment web
kubectl set image deployment/web web=registry.example.com/web:latest

Αυτή η ενέργεια μπορεί να είναι δικαιολογημένη κατά τη διαχείριση περιστατικού. Στη συνέχεια, όμως, πρέπει να μεταφέρετε την αλλαγή στη δηλωτική πηγή. Διαφορετικά, δημιουργείται Configuration Drift.

3.2. Χρησιμοποιείτε ονόματα πόρων με σαφή σημασία

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

Προτεινόμενο σχήμα

<app>-<component>
<app>-<component>-<purpose>

Παραδείγματα

Κανόνας

• Το όνομα περιγράφει τον λειτουργικό σκοπό και τον τεχνικό ρόλο.
• Τα στοιχεία που αφορούν συγκεκριμένο περιβάλλον ανήκουν συνήθως στο Namespace, στο Overlay ή στα Labels, χωρίς να χρειάζεται να επαναλαμβάνονται σε κάθε όνομα πόρου.
• Το όνομα πρέπει να παραμένει κατανοητό σε Logs, Events και Monitoring.

3.3. Χρησιμοποιείτε Labels και Annotations με συνέπεια

Τα Labels χρησιμοποιούνται για επιλογή, ομαδοποίηση και αυτοματοποίηση. Τα Annotations περιέχουν πρόσθετα Metadata που δεν χρησιμοποιούνται κυρίως για επιλογή.

Προτεινόμενα τυπικά Labels

metadata:
  labels:
    app.kubernetes.io/name: shop-api
    app.kubernetes.io/component: api
    app.kubernetes.io/part-of: shop
    app.kubernetes.io/managed-by: kustomize
    app.kubernetes.io/version: "1.4.2"
    environment: dev
    team: platform

Σημαντικό

• Οι Selectors των Services πρέπει να αντιστοιχούν στα Labels των Pods.
• Μην αλλάζετε χωρίς έλεγχο τα Labels που χρησιμοποιούνται από Selectors.
• Χρησιμοποιείτε Labels για Monitoring, κατανομή κόστους, ανάθεση ευθύνης και εξαιρέσεις Policies.
• Χρησιμοποιείτε Annotations για πληροφορίες Build, Git revisions, συνδέσμους τεκμηρίωσης ή οδηγίες ειδικές για εργαλεία.

Έλεγχος

kubectl get pods --show-labels
kubectl get svc shop-api -o yaml
kubectl get endpointslice -l kubernetes.io/service-name=shop-api

3.4. Διαχωρίζετε Base, περιβάλλοντα και Secrets

Μια καθαρή δομή αποτρέπει την ανάμειξη ρυθμίσεων διαφορετικών περιβαλλόντων και μειώνει τον κίνδυνο να καταχωριστούν κατά λάθος Secrets στο Git project.

Παράδειγμα δομής

k8s/
  base/
    deployment.yaml
    service.yaml
    serviceaccount.yaml
    networkpolicy.yaml
  overlays/
    dev/
      kustomization.yaml
      patch-resources.yaml
      patch-ingress.yaml
    test/
      kustomization.yaml
      patch-resources.yaml
    prod/
      kustomization.yaml
      patch-resources.yaml
      patch-pdb.yaml

Βέλτιστη πρακτική

• Οι κοινόχρηστοι πόροι βρίσκονται στο base.
• Οι διαφορές ανά περιβάλλον βρίσκονται στα Overlays.
• Τα Secrets δεν αποθηκεύονται ως Plaintext στην πηγή Git.
• Οι πόροι που αφορούν συγκεκριμένο πάροχο τεκμηριώνονται χωριστά.
• Οι τιμές παραδειγμάτων επισημαίνονται καθαρά ως τέτοιες.

Ερώτημα ανασκόπησης

Μπορείτε να διαπιστώσετε από τα αρχεία του Git project τι διαφέρει ανάμεσα στα dev, test και prod, χωρίς να υποβάλετε ερώτημα στο Cluster;

3.5. Επικυρώνετε τις αλλαγές πριν τις εφαρμόσετε

Το Kubernetes μπορεί να δεχτεί YAML που είναι συντακτικά έγκυρο αλλά λανθασμένο από λειτουργική ή αρχιτεκτονική άποψη. Γι’ αυτό χρειάζονται πολλαπλά επίπεδα επικύρωσης.

Επίπεδα επικύρωσης

Ελάχιστο πρότυπο workshop

kubectl apply --dry-run=server -f manifest.yaml
kubectl diff -f manifest.yaml
kubectl apply -f manifest.yaml
kubectl rollout status deployment/<name>

4. Βέλτιστες πρακτικές για Workloads

4.1. Επιλέξτε τον κατάλληλο τύπο Workload

Δεν είναι κάθε Workload κατάλληλο για Deployment.

Κανόνας

• Χρησιμοποιείτε Deployments για συνήθη Stateless Workloads.
• Χρησιμοποιείτε StatefulSets μόνο όταν χρειάζεστε σταθερή ταυτότητα, καθορισμένη σειρά εκκίνησης ή ξεχωριστά Persistent Volumes ανά αντίγραφο.
• Χρησιμοποιείτε Jobs και CronJobs για εργασίες με πεπερασμένη διάρκεια.
• Χρησιμοποιείτε DaemonSets μόνο όταν πρέπει πραγματικά να εκτελείται ένα αντίγραφο σε κάθε Node ή σε επιλεγμένο σύνολο Nodes.

4.2. Σχεδιάζετε Deployments που επιτρέπουν Rollback

Ένα Deployment είναι σωστά σχεδιασμένο μόνο όταν το Rollout και το Rollback μπορούν να ελεγχθούν.

Προτεινόμενο παράδειγμα Deployment

apiVersion: apps/v1
kind: Deployment
metadata:
  name: shop-api
  labels:
    app.kubernetes.io/name: shop-api
    app.kubernetes.io/component: api
spec:
  replicas: 3
  revisionHistoryLimit: 5
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 0
      maxSurge: 1
  selector:
    matchLabels:
      app.kubernetes.io/name: shop-api
  template:
    metadata:
      labels:
        app.kubernetes.io/name: shop-api
        app.kubernetes.io/component: api
    spec:
      serviceAccountName: shop-api
      automountServiceAccountToken: false
      containers:
        - name: shop-api
          image: registry.example.com/shop-api:1.4.2
          imagePullPolicy: IfNotPresent
          ports:
            - name: http
              containerPort: 8080
          resources:
            requests:
              cpu: 100m
              memory: 128Mi
            limits:
              memory: 256Mi
          readinessProbe:
            httpGet:
              path: /ready
              port: http
            initialDelaySeconds: 5
            periodSeconds: 10
            timeoutSeconds: 2
            failureThreshold: 3
          livenessProbe:
            httpGet:
              path: /healthz
              port: http
            initialDelaySeconds: 20
            periodSeconds: 20
            timeoutSeconds: 2
            failureThreshold: 3
          startupProbe:
            httpGet:
              path: /startup
              port: http
            periodSeconds: 5
            failureThreshold: 30
          securityContext:
            allowPrivilegeEscalation: false
            readOnlyRootFilesystem: true
            runAsNonRoot: true
            runAsUser: 10001
            capabilities:
              drop:
                - ALL
            seccompProfile:
              type: RuntimeDefault

Επεξήγηση

• Το replicas: 3 μειώνει την επίδραση από την απώλεια ενός Pod.
• Το maxUnavailable: 0 αποτρέπει τη σκόπιμη μείωση της διαθεσιμότητας από το Kubernetes κατά το Rollout.
• Το maxSurge: 1 επιτρέπει ένα επιπλέον αντίγραφο κατά το Rollout.
• Το revisionHistoryLimit διατηρεί παλαιότερα ReplicaSets διαθέσιμα για Rollback.
• Το readinessProbe καθορίζει αν θα δρομολογείται κίνηση προς το Pod.
• Το livenessProbe καθορίζει αν το Kubernetes πρέπει να επανεκκινήσει το Container.
• Το startupProbe προστατεύει εφαρμογές με αργή εκκίνηση από πρόωρους ελέγχους Liveness.
• Το securityContext περιορίζει τα δικαιώματα του Container.

Έλεγχος

kubectl rollout status deployment/shop-api
kubectl rollout history deployment/shop-api
kubectl describe deployment shop-api
kubectl get rs -l app.kubernetes.io/name=shop-api

4.3. Σχεδιάζετε ομαλό τερματισμό

Το Kubernetes δεν τερματίζει τα Pods αμέσως. Στέλνει σήμα τερματισμού και περιμένει για το καθορισμένο Grace Period. Η εφαρμογή πρέπει να αξιοποιεί αυτό το διάστημα για να ολοκληρώνει αιτήματα, να κλείνει συνδέσεις και να σταματά να δέχεται νέα εργασία.

Βέλτιστη πρακτική

• Υλοποιήστε χειρισμό του σήματος SIGTERM.
• Ρυθμίστε το readinessProbe ώστε το Pod να αφαιρείται από την κίνηση πριν τερματιστεί.
• Επιλέξτε το terminationGracePeriodSeconds σύμφωνα με τη συμπεριφορά της εφαρμογής.
• Χρησιμοποιείτε preStop μόνο όταν χρειάζεστε συγκεκριμένη καθυστέρηση ή ενέργεια αποκαταχώρισης.
• Ελέγξτε αν ο Load Balancer ή ο Ingress Controller διαθέτει δικό του χρονισμό για Drain.

Παράδειγμα

spec:
  terminationGracePeriodSeconds: 30
  containers:
    - name: shop-api
      lifecycle:
        preStop:
          exec:
            command: ["/bin/sh", "-c", "sleep 5"]

Κίνδυνος

Πολύ σύντομο διάστημα τερματισμού διακόπτει αιτήματα. Υπερβολικά μεγάλο διάστημα επιβραδύνει τα Rollouts, το Node Drain και τις ενέργειες Scaling.

4.4. Χρησιμοποιείτε Probes με συγκεκριμένο σκοπό

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

Βέλτιστη πρακτική

• Χρησιμοποιείτε readinessProbe σχεδόν σε όλες τις υπηρεσίες.
• Χρησιμοποιείτε livenessProbe μόνο αν η επανεκκίνηση μπορεί πράγματι να διορθώσει μια κατάσταση εμπλοκής.
• Χρησιμοποιείτε startupProbe για εφαρμογές που εκκινούν αργά.
• Επιτρέψτε στο Readiness να ελέγχει συναφείς εξαρτήσεις, χωρίς να κάνετε τον έλεγχο υπερβολικά αυστηρό.
• Το Liveness δεν πρέπει να εξαρτάται άμεσα από εξωτερικά συστήματα. Διαφορετικά, πρόβλημα στη βάση δεδομένων μπορεί να προκαλέσει μαζικές επανεκκινήσεις.

Αντιπαράδειγμα

livenessProbe:
  httpGet:
    path: /deep-check-with-database-and-third-party-api
    port: 8080

Αν η βάση δεδομένων δεν είναι διαθέσιμη για λίγο, το Kubernetes επανεκκινεί όλα τα Pods. Έτσι επιδεινώνεται το περιστατικό.

4.5. Κατανέμετε τα Pods σκόπιμα

Τα πολλαπλά αντίγραφα βοηθούν μόνο αν δεν καταλήγουν όλα στον ίδιο Node ή στην ίδια ζώνη αστοχίας.

Επιλογές

Παράδειγμα: κατανομή τοπολογίας

spec:
  template:
    spec:
      topologySpreadConstraints:
        - maxSkew: 1
          topologyKey: kubernetes.io/hostname
          whenUnsatisfiable: ScheduleAnyway
          labelSelector:
            matchLabels:
              app.kubernetes.io/name: shop-api

Κανόνας

• Για υπηρεσίες production με πολλά αντίγραφα, επαληθεύετε ενεργά την κατανομή τους.
• Για κρίσιμα Workloads, εξετάζετε και την κατανομή σε διαφορετικές ζώνες.
• Χρησιμοποιείτε αυστηρούς κανόνες Scheduling μόνο όταν υπάρχει επαρκής χωρητικότητα. Διαφορετικά, τα Pods παραμένουν σε κατάσταση Pending.

4.6. Προστατεύετε τη διαθεσιμότητα με PodDisruptionBudgets

Ένα PodDisruptionBudget περιορίζει τις προγραμματισμένες διακοπές, όπως Node Drains, συντήρηση Cluster ή ελεγχόμενες απομακρύνσεις Pods.

Παράδειγμα

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: shop-api
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app.kubernetes.io/name: shop-api

Βέλτιστη πρακτική

• Ορίζετε PDBs για παραγωγικά Workloads με πολλά αντίγραφα.
• Μη χρησιμοποιείτε PDBs ως υποκατάστατο επαρκούς αριθμού αντιγράφων.
• Ελέγχετε αν τα PDBs μπορούν να εμποδίσουν εργασίες συντήρησης.
• Είστε ιδιαίτερα προσεκτικοί με συστήματα που βασίζονται σε Quorum.

Έλεγχος

kubectl get pdb
kubectl describe pdb shop-api
kubectl drain <node> --ignore-daemonsets --dry-run=server

5. Διαχείριση πόρων και Scaling

5.1. Ορίζετε Resource Requests

Τα Requests παρέχουν στον Scheduler πληροφορίες για την τοποθέτηση των Pods. Χωρίς αυτά, η τοποθέτηση γίνεται λιγότερο αξιόπιστη, η αξιολόγηση των Quotas δυσκολεύει, το Autoscaling γίνεται αναξιόπιστο και οι Nodes μπορεί να υπερφορτωθούν.

Βέλτιστη πρακτική

• Ορίζετε resources.requests.cpu και resources.requests.memory για κάθε Container.
• Ξεκινάτε από μετρημένες τιμές και όχι από αισιόδοξες υποθέσεις.
• Χρησιμοποιείτε δεδομένα Monitoring, Load Tests και λειτουργική εμπειρία.
• Τεκμηριώνετε τις παραδοχές: αναμενόμενα αιτήματα ανά δευτερόλεπτο, προφίλ μνήμης, συμπεριφορά εκκίνησης και μέγιστο φορτίο.

Παράδειγμα

resources:
  requests:
    cpu: 100m
    memory: 128Mi
  limits:
    memory: 256Mi

Σημείωση για τη CPU

Τα CPU Requests επηρεάζουν το Scheduling και την κατανομή CPU. Τα CPU Limits μπορούν να προκαλέσουν Throttling. Ορίζετέ τα συνειδητά και παρακολουθείτε την πραγματική συμπεριφορά.

Σημείωση για τη μνήμη

Τα Memory Limits είναι αυστηρά όρια. Αν ένα Container ξεπεράσει το όριό του, μπορεί να τερματιστεί με OOMKilled. Γι’ αυτό χρειάζονται ρεαλιστικές τιμές και Alerts.

5.2. Ορίζετε Limits με συγκεκριμένο σκοπό

Τα Limits προστατεύουν τους Nodes και τα γειτονικά Workloads, αλλά μπορούν επίσης να προκαλέσουν αστοχίες.

Βέλτιστη πρακτική

• Ορίζετε τουλάχιστον CPU και Memory Requests.
• Ορίζετε Memory Limits σχεδόν για όλα τα Containers εφαρμογών.
• Επικυρώνετε τα CPU Limits με δοκιμές Latency και Throughput.
• Περιορίζετε το προσωρινό Storage όταν οι εφαρμογές γράφουν σημαντικό όγκο δεδομένων.
• Χρησιμοποιείτε Dashboards για CPU Throttling, Working Set Memory και OOM Events.

5.3. Χρησιμοποιείτε Namespaces, ResourceQuota και LimitRange

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

Παράδειγμα Namespace

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

Παράδειγμα ResourceQuota

apiVersion: v1
kind: ResourceQuota
metadata:
  name: compute-quota
  namespace: shop-dev
spec:
  hard:
    requests.cpu: "4"
    requests.memory: 8Gi
    limits.memory: 16Gi
    pods: "30"

Παράδειγμα LimitRange

apiVersion: v1
kind: LimitRange
metadata:
  name: default-container-limits
  namespace: shop-dev
spec:
  limits:
    - type: Container
      defaultRequest:
        cpu: 100m
        memory: 128Mi
      default:
        memory: 256Mi

Βέλτιστη πρακτική

• Χρησιμοποιείτε Namespaces ανά ομάδα, εφαρμογή, περιβάλλον ή Tenant.
• Ορίζετε ResourceQuotas σε κοινόχρηστα Clusters.
• Ορίζετε LimitRanges ώστε η απουσία Requests να μην περνά απαρατήρητη.
• Τεκμηριώνετε τους πόρους που μπορεί να χρησιμοποιεί κάθε ομάδα.

5.4. Βασίζετε το Scaling σε Metrics

Το Scaling χωρίς Metrics βασίζεται σε εικασίες. Το Kubernetes μπορεί να αυξομειώνει οριζόντια τα αντίγραφα όταν διαθέτει κατάλληλα Metrics.

Παράδειγμα HorizontalPodAutoscaler

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: shop-api
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: shop-api
  minReplicas: 3
  maxReplicas: 10
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70

Βέλτιστη πρακτική

• Χρησιμοποιείτε HPA για Stateless Workloads με μεταβαλλόμενο φορτίο.
• Βεβαιώνεστε ότι είναι διαθέσιμος ο Metrics Server ή κατάλληλα Custom Metrics.
• Ορίζετε σωστά τα Requests· διαφορετικά οι στόχοι CPU Utilization δεν έχουν νόημα.
• Ορίζετε τα minReplicas και maxReplicas βάσει λειτουργικών απαιτήσεων.
• Επαληθεύετε τη συμπεριφορά Scaling με Load Tests.
• Συνδυάζετε Workload Autoscaling με Node Autoscaling όταν χρειάζεται.

Έλεγχος

kubectl get hpa
kubectl describe hpa shop-api
kubectl top pods
kubectl top nodes

6. Networking και Service Discovery

6.1. Χρησιμοποιείτε Services ως σταθερό επίπεδο πρόσβασης

Τα Pods είναι προσωρινά. Τα Services παρέχουν σταθερό επίπεδο πρόσβασης μέσα στο Cluster.

Παράδειγμα Service

apiVersion: v1
kind: Service
metadata:
  name: shop-api
spec:
  type: ClusterIP
  selector:
    app.kubernetes.io/name: shop-api
  ports:
    - name: http
      port: 80
      targetPort: http

Βέλτιστη πρακτική

• Χρησιμοποιείτε ClusterIP για εσωτερική επικοινωνία.
• Χρησιμοποιείτε LoadBalancer μόνο όταν ένα Service πρέπει να είναι άμεσα προσβάσιμο από έξω.
• Χρησιμοποιείτε Ingress ή Gateway API για δρομολόγηση HTTP/HTTPS.
• Ονομάζετε τα Ports ώστε τα Probes, Services και Policies να διαβάζονται ευκολότερα.
• Ελέγχετε πάντα αν το Service διαθέτει Endpoints ή EndpointSlices.

Έλεγχος

kubectl get svc shop-api
kubectl get endpoints shop-api
kubectl get endpointslice -l kubernetes.io/service-name=shop-api

6.2. Κατανοείτε το DNS μέσα στο Cluster

Το Kubernetes παρέχει ονόματα DNS για Services. Συνήθως, ένα Service στο ίδιο Namespace είναι προσβάσιμο με το σύντομο όνομά του. Για επικοινωνία μεταξύ Namespaces, χρησιμοποιείτε το πλήρως προσδιορισμένο όνομα DNS.

Παραδείγματα

shop-api
shop-api.shop-dev
shop-api.shop-dev.svc.cluster.local

Βέλτιστη πρακτική

• Χρησιμοποιείτε ονόματα Services αντί για IPs των Pods.
• Χρησιμοποιείτε πλήρως προσδιορισμένα ονόματα DNS για επικοινωνία μεταξύ Namespaces.
• Διαγιγνώσκετε προβλήματα DNS από ένα Debug Pod.
• Διακρίνετε τις αστοχίες DNS από προβλήματα NetworkPolicy ή Selector του Service.

Έλεγχος

kubectl run dns-debug --rm -it --image=busybox:1.36 --restart=Never -- nslookup shop-api.shop-dev.svc.cluster.local
kubectl get pods -n kube-system -l k8s-app=kube-dns

6.3. Επιλέγετε Ingress ή Gateway API με συγκεκριμένο σκοπό

Τα Ingress και Gateway API καθιστούν Services προσβάσιμα εκτός του Cluster. Και τα δύο περιγράφουν τη δρομολόγηση, αλλά η πραγματική υλοποίηση εξαρτάται από τον εγκατεστημένο Controller.

Παράδειγμα Ingress

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

Βέλτιστη πρακτική

• Τεκμηριώνετε ποιος Ingress ή Gateway Controller χρησιμοποιείται.
• Ορίζετε ρητά TLS, Hostnames και διαχείριση πιστοποιητικών.
• Αποφεύγετε Annotations ειδικά για Controller χωρίς επεξηγηματικά σχόλια.
• Επαληθεύετε χωριστά τη δρομολόγηση, το TLS, το Backend Service και τα Endpoints.

6.4. Απομονώνετε την κίνηση με NetworkPolicies

Χωρίς NetworkPolicies, η επικοινωνία μεταξύ Pods είναι σε πολλά Clusters ευρέως ανοιχτή. Τα NetworkPolicies ορίζουν επιτρεπόμενη κίνηση βάσει Pods, Namespaces, IP Blocks και Ports. Οι κανόνες εφαρμόζονται μόνο αν το CNI Plugin υποστηρίζει επιβολή NetworkPolicy.

Default Deny για εισερχόμενη κίνηση

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
  namespace: shop-dev
spec:
  podSelector: {}
  policyTypes:
    - Ingress

Επιτρέψτε κίνηση από τον Ingress Controller προς το API

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: shop-api-allow-ingress-controller
  namespace: shop-dev
spec:
  podSelector:
    matchLabels:
      app.kubernetes.io/name: shop-api
  policyTypes:
    - Ingress
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: ingress-nginx
      ports:
        - protocol: TCP
          port: 8080

Βέλτιστη πρακτική

• Ξεκινάτε με default-deny ανά Namespace.
• Επιτρέπετε μόνο τις απαραίτητες διαδρομές επικοινωνίας.
• Τεκμηριώνετε τις εξαρτήσεις μεταξύ Services.
• Δοκιμάζετε ενεργά τις Policies με Debug Pods.
• Όταν περιορίζετε την εξερχόμενη κίνηση, λαμβάνετε υπόψη και την πρόσβαση DNS.

7. Configuration, Secrets και Storage

7.1. Διαχωρίζετε το Configuration από το Image

Τα Container Images πρέπει να μεταφέρονται μεταξύ περιβαλλόντων με όσο το δυνατόν λιγότερες αλλαγές. Το Configuration κάθε περιβάλλοντος ανήκει σε ConfigMaps, Secrets ή εξωτερικά συστήματα ρυθμίσεων.

Παράδειγμα ConfigMap

apiVersion: v1
kind: ConfigMap
metadata:
  name: shop-api-config
data:
  LOG_LEVEL: "info"
  FEATURE_CHECKOUT_V2: "true"

Χρήση ως μεταβλητές περιβάλλοντος

containers:
  - name: shop-api
    envFrom:
      - configMapRef:
          name: shop-api-config

Βέλτιστη πρακτική

• Κάνετε Build ενός Image μία φορά και το χρησιμοποιείτε σε πολλά περιβάλλοντα.
• Μην ενσωματώνετε τιμές Configuration στο Image.
• Διακρίνετε το μη ευαίσθητο Configuration από τα ευαίσθητα δεδομένα.
• Τεκμηριώνετε αν μια αλλαγή ConfigMap απαιτεί Rollout.

7.2. Αντιμετωπίζετε τα Secrets ως ιδιαίτερα ευαίσθητα

Τα Kubernetes Secrets προορίζονται για ευαίσθητες τιμές, αλλά δεν υποκαθιστούν πλήρως τη διαχείριση Secrets. Σχεδιάζετε συνειδητά την πρόσβαση, την αποθήκευση, το Rotation και τη χρήση τους.

Βέλτιστη πρακτική

• Μην αποθηκεύετε πραγματικά Secrets ως Plaintext στο Git project.
• Χρησιμοποιείτε εξωτερικά συστήματα Secrets ή κρυπτογραφημένες ροές Git όταν απαιτείται Version Control για Secrets.
• Περιορίζετε αυστηρά την πρόσβαση RBAC στα Secrets.
• Ενεργοποιείτε Encryption at Rest για Secrets όταν λειτουργείτε οι ίδιοι το Cluster ή μπορείτε να ρυθμίσετε αυτή την επιλογή σε Managed Service.
• Χρησιμοποιείτε σύντομη διάρκεια ισχύος και Rotation όπου είναι δυνατό.
• Προτιμάτε το Mount των Secrets ως αρχεία όταν οι εφαρμογές υποστηρίζουν Rotation.
• Αποφεύγετε Secrets σε Logs, Events, μηνύματα σφάλματος και ορίσματα της γραμμής εντολών.

Παράδειγμα Secret μόνο για εκπαιδευτική χρήση

apiVersion: v1
kind: Secret
metadata:
  name: shop-api-db-credentials
type: Opaque
stringData:
  username: example-user
  password: example-password

Σημαντικό

Αυτό το παράδειγμα δεν αποτελεί πρότυπο για πραγματικούς κωδικούς σε production. Σε πραγματικά έργα, χρησιμοποιείτε μέθοδο διαχείρισης Secrets κατάλληλη για τον οργανισμό σας.

7.3. Σχεδιάζετε ρητά τη διατήρηση δεδομένων

Τα Pods είναι αναλώσιμα. Δεδομένα που πρέπει να επιβιώνουν από επανεκκινήσεις, αλλαγές Scheduling ή Rollouts δεν ανήκουν στο εγγράψιμο Filesystem του Container.

Βέλτιστη πρακτική

• Χρησιμοποιείτε PersistentVolumeClaims για δεδομένα που πρέπει να διατηρούνται.
• Ελέγχετε Access Mode, StorageClass, Reclaim Policy, Backup και Restore.
• Χρησιμοποιείτε StatefulSets για Stateful Workloads με σταθερά Volumes.
• Ορίζετε ποια δεδομένα επιτρέπεται να χαθούν.
• Δοκιμάζετε το Restore, όχι μόνο το Backup.

Παράδειγμα PVC

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

Ερωτήματα ανασκόπησης

• Ποια δεδομένα πρέπει να διατηρούνται;
• Ποιος δημιουργεί το Volume;
• Τι συμβαίνει όταν διαγραφεί το PVC;
• Πώς δημιουργείται Backup;
• Πώς δοκιμάζεται το Restore;
• Ποιες απαιτήσεις απόδοσης ισχύουν;

8. Βέλτιστες πρακτικές ασφάλειας

8.1. RBAC: Least Privilege αντί για Cluster Admin

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

Βέλτιστη πρακτική

• Εκχωρείτε δικαιώματα βάσει ρόλων και περιορίζετέ τα στα απολύτως απαραίτητα.
• Χρησιμοποιείτε Role και RoleBinding μέσα σε ένα Namespace όπου είναι δυνατό.
• Χρησιμοποιείτε ClusterRole μόνο για πόρους σε επίπεδο Cluster ή για ρόλους που σχεδιάζονται σκόπιμα για επαναχρησιμοποίηση.
• Αποφεύγετε το cluster-admin για εφαρμογές.
• Ελέγχετε τα δικαιώματα με kubectl auth can-i.
• Ελέγχετε τακτικά τα Bindings προς system:masters, cluster-admin και ομάδες με ευρεία πρόσβαση.

Παράδειγμα: δικαιώματα ανάγνωσης περιορισμένα σε Namespace

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

Επαλήθευση

kubectl auth can-i get pods --as=system:serviceaccount:shop-dev:diagnostics -n shop-dev
kubectl auth can-i delete secrets --as=system:serviceaccount:shop-dev:diagnostics -n shop-dev

8.2. Περιορίζετε τα ServiceAccounts

Κάθε Pod εκτελείται με ένα ServiceAccount. Αν δεν ορίσετε κάποιο, το Kubernetes χρησιμοποιεί το default ServiceAccount του Namespace.

Βέλτιστη πρακτική

• Δημιουργείτε ξεχωριστό ServiceAccount για κάθε εφαρμογή ή Component.
• Συνδέετε μόνο τα απαραίτητα δικαιώματα.
• Ορίζετε automountServiceAccountToken: false όταν η εφαρμογή δεν χρειάζεται πρόσβαση στο Kubernetes API.
• Μη χρησιμοποιείτε κοινά ServiceAccounts για πολλές ανεξάρτητες εφαρμογές.

Παράδειγμα

apiVersion: v1
kind: ServiceAccount
metadata:
  name: shop-api
  namespace: shop-dev
automountServiceAccountToken: false

Ερώτημα ανασκόπησης

Γιατί χρειάζεται αυτό το Pod πρόσβαση στο Kubernetes API; Αν δεν υπάρχει συγκεκριμένος λόγος, το Token δεν πρέπει να γίνεται Mount αυτόματα.

8.3. Εφαρμόζετε Pod Security Standards

Τα Pod Security Standards ορίζουν επίπεδα ασφάλειας για τα Pods. Τα τρία Profiles είναι privileged, baseline και restricted.

Βέλτιστη πρακτική

• Χρησιμοποιείτε το restricted όπου είναι δυνατό.
• Χρησιμοποιείτε το baseline όταν οι εφαρμογές δεν πληρούν ακόμη όλους τους περιορισμούς.
• Χρησιμοποιείτε το privileged μόνο για Infrastructure Workloads με σαφή αιτιολόγηση.
• Επιβάλλετε τα Standards μέσω Namespace Labels ή Admission Policies.
• Εντοπίζετε πρώτα τις παραβιάσεις με warn και audit, πριν ενεργοποιήσετε την απόρριψη πόρων σε Production Namespaces.

Namespace Labels

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

Διαδικασία μετάβασης

1. Ορίζετε warn=restricted και audit=restricted.
2. Διορθώνετε τις παραβιάσεις που αναφέρονται.
3. Ορίζετε enforce=baseline ή enforce=restricted.
4. Τεκμηριώνετε τις εξαιρέσεις που έχουν αιτιολόγηση.

8.4. Ενισχύετε την ασφάλεια των Containers

Τα Containers πρέπει να εκτελούνται με όσο το δυνατόν λιγότερα προνόμια.

Προτεινόμενο βασικό SecurityContext

securityContext:
  allowPrivilegeEscalation: false
  readOnlyRootFilesystem: true
  runAsNonRoot: true
  runAsUser: 10001
  capabilities:
    drop:
      - ALL
  seccompProfile:
    type: RuntimeDefault

Βέλτιστη πρακτική

• Αποφεύγετε την εκτέλεση ως root όπου είναι δυνατό.
• Αφαιρείτε τα Linux Capabilities που δεν χρειάζεστε.
• Αποφεύγετε το privileged: true.
• Αποφεύγετε την πρόσβαση στα Host Namespaces μέσω hostNetwork, hostPID και hostIPC, εκτός από Infrastructure Components για τα οποία υπάρχει σαφής αιτιολόγηση.
• Χρησιμοποιείτε Read-only Root Filesystem όταν το υποστηρίζει η εφαρμογή.
• Γράφετε προσωρινά αρχεία σε ρητά ορισμένα Volumes, όπως το emptyDir.

Παράδειγμα χώρου προσωρινής εγγραφής

spec:
  containers:
    - name: shop-api
      volumeMounts:
        - name: tmp
          mountPath: /tmp
  volumes:
    - name: tmp
      emptyDir: {}

8.5. Ασφαλίζετε τα Images και το Supply Chain

Η αξιοπιστία ενός Kubernetes Cluster εξαρτάται από την αξιοπιστία των Artifacts που εκτελεί.

Βέλτιστη πρακτική

• Χρησιμοποιείτε Images από αξιόπιστα Registries.
• Καθορίζετε τα Images τουλάχιστον με Versioned Tags· για αυξημένες απαιτήσεις ασφάλειας, χρησιμοποιείτε και Digests.
• Αποφεύγετε το latest στα Production Manifests.
• Σαρώνετε τα Images για γνωστές ευπάθειες.
• Χρησιμοποιείτε μικρά Base Images που συντηρούνται ενεργά.
• Υπογράφετε τα Images αν ο οργανισμός σας διαθέτει αλυσίδα υπογραφής.
• Αφαιρείτε Build Tools, Package Managers και περιττά Shells από τα Runtime Images όπου είναι δυνατό.
• Χρησιμοποιείτε Private Registries με ελεγχόμενη πρόσβαση.

Καλή πρακτική

image: registry.example.com/shop-api:1.4.2@sha256:aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa

Ακατάλληλη πρακτική

image: shop-api:latest
imagePullPolicy: Always

Το imagePullPolicy: Always δεν λύνει το βασικό πρόβλημα ενός μη συγκεκριμένου Tag. Ένα Mutable Tag παραμένει μεταβλητό.

8.6. Χρησιμοποιείτε Admission Control και Policy as Code

Τα Admission Controllers επικυρώνουν ή τροποποιούν τα API Requests πριν αποθηκευτούν οι πόροι. Έτσι μπορούν να εφαρμόζονται κεντρικά κανόνες ασφάλειας και λειτουργίας.

Συνήθεις κανόνες Policy

• Κανένα Container με privileged: true.
• Κανένα Production Image με :latest.
• Κάθε Container πρέπει να έχει Resource Requests.
• Τα Pods πρέπει να εκτελούνται χωρίς δικαιώματα root.
• Τα Namespaces πρέπει να έχουν Pod Security Labels.
• Οι πόροι Ingress πρέπει να χρησιμοποιούν TLS.
• Επιτρέπονται μόνο εγκεκριμένα Registries.
• Συγκεκριμένα Annotations ή Labels είναι υποχρεωτικά.

Εργαλεία Policy as Code

Βέλτιστη πρακτική

• Δοκιμάζετε πρώτα τα Policies σε λειτουργία Audit ή Warn.
• Τεκμηριώνετε τις εξαιρέσεις με ημερομηνία λήξης και αιτιολόγηση.
• Διατηρείτε τα Policies σε Version Control.
• Δοκιμάζετε τα Policies σε CI πριν τα επιβάλετε στο Cluster.

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

9.1. Διακρίνετε Logs, Events και Metrics

Αυτές οι πηγές δεδομένων απαντούν σε διαφορετικά ερωτήματα.

Βέλτιστη πρακτική

• Οι εφαρμογές γράφουν Logs στα stdout και stderr.
• Τα Logs περιλαμβάνουν Timestamp, Level, Service, Environment και Correlation ID.
• Κατά την ανάλυση σφαλμάτων ελέγχετε πάντα τα Kubernetes Events.
• Δεν ανασυνθέτετε Metrics από Logs όταν μπορείτε να τα μετρήσετε απευθείας.
• Καταγράφετε σε Audit Log τις κρίσιμες αλλαγές μέσω του Kubernetes API.

9.2. Δημιουργείτε εφαρμογές με Observability

Το Kubernetes μπορεί να ελέγχει αξιόπιστα μόνο όσα η εφαρμογή εκθέτει ως Signals.

Ελάχιστες απαιτήσεις για Services

Προτεινόμενα Endpoints

/startup   -> Has the application completed initial startup?
/ready     -> Can the application serve traffic?
/healthz   -> Is the process basically alive?
/metrics   -> Metrics for monitoring, if intended

9.3. Τυποποιείτε το Troubleshooting

Το Troubleshooting δεν πρέπει να βασίζεται σε τυχαίες εντολές. Προχωράτε από έξω προς τα μέσα και από γενικές ενδείξεις σε συγκεκριμένες λεπτομέρειες.

Τυπική διαδικασία

1. Ορίστε το εύρος: Ποια εφαρμογή, ποιο Namespace, από πότε, μετά από ποια αλλαγή;
2. Ελέγξτε τα Objects: Deployment, ReplicaSet, Pod, Service, EndpointSlice, Ingress/Gateway.
3. Ελέγξτε την κατάσταση: Conditions, Events, Restarts, Images, Nodes.
4. Ελέγξτε τα Logs: Τρέχοντα Logs και --previous μετά από Restarts.
5. Ελέγξτε το Networking: DNS, Service Selector, Endpoints, NetworkPolicy.
6. Ελέγξτε τους πόρους: Requests, Limits, OOM, NodePressure, Quotas.
7. Ελέγξτε το RBAC: kubectl auth can-i και ServiceAccount.
8. Αξιολογήστε την αλλαγή: Rollout History, Git Diff, CI/CD Runs.
9. Επαληθεύστε τη διόρθωση: Τεκμηριώστε τις εντολές πριν και μετά.
10. Τεκμηριώστε το Rollback: Πώς μπορεί να αναιρεθεί η διόρθωση.

Βασικές εντολές

kubectl get all -n <namespace>
kubectl describe pod <pod> -n <namespace>
kubectl logs <pod> -n <namespace>
kubectl logs <pod> -n <namespace> --previous
kubectl get events -n <namespace> --sort-by=.lastTimestamp
kubectl rollout status deployment/<deployment> -n <namespace>
kubectl rollout history deployment/<deployment> -n <namespace>

10. Deployment, Release και Rollback

10.1. Χρησιμοποιείτε αναπαραγώγιμα Images

Ένα Deployment πρέπει να παραμένει ιχνηλάσιμο και αργότερα. Πρέπει να γνωρίζετε ποιος κώδικας, ποιες Dependencies και ποιο Image εκτελέστηκαν πράγματι.

Βέλτιστη πρακτική

• Δημιουργείτε τα Images σε CI.
• Δίνετε στα Images αμετάβλητες εκδόσεις.
• Αποθηκεύετε το Git Commit, τον χρόνο του Build και το Build Pipeline ως Metadata.
• Χρησιμοποιείτε Digests για ιδιαίτερα κρίσιμα Workloads.
• Τεκμηριώνετε ποιος επιτρέπεται να προωθεί ένα Image στο επόμενο περιβάλλον.

Χρήσιμα Annotations

metadata:
  annotations:
    build.example.com/git-sha: "f4c2a7e"
    build.example.com/pipeline: "https://ci.example.com/pipelines/12345"

10.2. Δοκιμάζετε Rollouts και Rollbacks

Μια διαδικασία Rollback είναι χρήσιμη μόνο αν έχει δοκιμαστεί.

Έλεγχος Rollout

kubectl apply -f k8s/
kubectl rollout status deployment/shop-api
kubectl get pods -l app.kubernetes.io/name=shop-api

Έλεγχος Rollback

kubectl rollout history deployment/shop-api
kubectl rollout undo deployment/shop-api
kubectl rollout status deployment/shop-api

Βέλτιστη πρακτική

• Δοκιμάζετε το Rollout και το Rollback πριν από αλλαγές στο Production.
• Εξετάζετε ξεχωριστά τα Database Migrations. Δεν είναι δυνατό να αναιρεθεί κάθε αλλαγή δεδομένων.
• Τεκμηριώνετε αν ένα Rollback επηρεάζει μόνο τον κώδικα της εφαρμογής ή και τα δεδομένα.
• Ορίζετε σαφή κριτήρια διακοπής: Error Rate, Latency, CrashLoop και Business Metrics.

10.3. Χρησιμοποιείτε Quality Gates στο CI/CD

Τα Manifests δεν πρέπει να αποτυγχάνουν για πρώτη φορά μέσα στο Cluster.

Προτεινόμενα βήματα Pipeline

1. YAML Linting
2. Επικύρωση Kubernetes Schema
3. Έλεγχοι Policy
4. Σάρωση Image
5. Σάρωση Secrets
6. Unit και Integration Tests
7. Render με Helm ή Kustomize
8. Diff σε σχέση με το περιβάλλον στόχο
9. Deployment σε Test Environment
10. Smoke Test
11. Έγκριση ή αυτοματοποιημένη διαδικασία Promotion

Παραδείγματα Quality Gates

11. Λίστες ελέγχου για ανασκόπηση

11.1. Ανασκόπηση Manifests

11.2. Ανασκόπηση ασφάλειας

11.3. Ανασκόπηση λειτουργίας

11.4. Ανασκόπηση τελικού έργου

Για το τελικό έργο, μια λύση θεωρείται ολοκληρωμένη όταν μπορείτε να δείξετε τα εξής:

• Μπορείτε να κάνετε Deploy την εφαρμογή χρησιμοποιώντας το υλικό του Workshop.
• Μπορείτε να εξηγήσετε ποιοι πόροι δημιουργούνται.
• Μπορείτε να προσπελάσετε την εφαρμογή εσωτερικά ή εξωτερικά.
• Μπορείτε να ελέγξετε Logs, Events και Status.
• Μπορείτε να εκκινήσετε και να παρακολουθήσετε ένα Rollout.
• Μπορείτε να εκτελέσετε ένα Rollback.
• Έχετε ορίσει Requests, Limits και Probes.
• Έχετε χρησιμοποιήσει ξεχωριστό Namespace.
• Δεν υπάρχουν πραγματικά Secrets στο υλικό του Workshop.
• Έχετε εφαρμόσει τουλάχιστον ένα μέτρο ασφάλειας: RBAC, Pod Security, SecurityContext ή NetworkPolicy.
• Έχετε προκαλέσει και επιλύσει σκόπιμα τουλάχιστον έναν συνηθισμένο τρόπο αστοχίας.

12. Anti-Patterns και τρόποι αστοχίας

12.1. Το Pod παραμένει σε κατάσταση Pending

Συνήθεις αιτίες

• Δεν υπάρχει επαρκής CPU ή μνήμη στο Cluster.
• Node Selector, Affinity ή Taints εμποδίζουν το Scheduling.
• Το PVC δεν έχει γίνει Bound.
• Το ResourceQuota έχει εξαντληθεί.
• Το Image Pull δεν εξετάζεται ακόμη, επειδή το Pod δεν έχει γίνει Scheduled.

Επαλήθευση

kubectl describe pod <pod> -n <namespace>
kubectl get events -n <namespace> --sort-by=.lastTimestamp
kubectl describe quota -n <namespace>
kubectl get nodes
kubectl describe node <node>

Διόρθωση

• Προσαρμόζετε τα Requests σε ρεαλιστικές τιμές.
• Ελέγχετε ή αυξάνετε τα Quotas.
• Διορθώνετε το Affinity και τα Tolerations.
• Ελέγχετε το PVC και το StorageClass.
• Αυξάνετε τη χωρητικότητα του Cluster.

12.2. CrashLoopBackOff

Συνήθεις αιτίες

• Η εφαρμογή τερματίζεται αμέσως.
• Το Configuration λείπει ή είναι λανθασμένο.
• Λείπει Secret ή ConfigMap.
• Το LivenessProbe είναι υπερβολικά αυστηρό.
• Η εφαρμογή δεν μπορεί να συνδεθεί με κάποια Dependency.
• Η εντολή Startup ή τα ορίσματά της είναι λανθασμένα.

Επαλήθευση

kubectl logs <pod> -n <namespace>
kubectl logs <pod> -n <namespace> --previous
kubectl describe pod <pod> -n <namespace>
kubectl get events -n <namespace> --sort-by=.lastTimestamp

Διόρθωση

• Διαβάζετε τα Logs· μην περιορίζεστε στον αριθμό των Restarts.
• Ελέγχετε ConfigMaps, Secrets και μεταβλητές περιβάλλοντος.
• Προσαρμόζετε τα Probes ή προσθέτετε StartupProbe.
• Αναπαράγετε το πρόβλημα του Container τοπικά ή σε Debug Environment.

12.3. ImagePullBackOff ή ErrImagePull

Συνήθεις αιτίες

• Το όνομα ή το Tag του Image είναι λανθασμένο.
• Το Registry δεν είναι προσβάσιμο.
• Λείπει το Authentication.
• Το imagePullSecret είναι λανθασμένο ή βρίσκεται σε άλλο Namespace.
• Rate Limits ή προβλήματα δικτύου εμποδίζουν το Pull.

Επαλήθευση

kubectl describe pod <pod> -n <namespace>
kubectl get secret -n <namespace>
kubectl get serviceaccount <sa> -n <namespace> -o yaml

Διόρθωση

• Επαληθεύετε το ακριβές Image Reference.
• Δοκιμάζετε την πρόσβαση στο Registry.
• Δημιουργείτε τα imagePullSecrets στο σωστό Namespace.
• Δηλώνετε σωστά το ServiceAccount.
• Αποφεύγετε το latest για ευκολότερη διάγνωση και αναπαραγωγιμότητα.

12.4. Service χωρίς Endpoints

Συνήθεις αιτίες

• Ο Service Selector δεν ταιριάζει με τα Pod Labels.
• Τα Pods δεν είναι Ready.
• Λανθασμένο Namespace.
• Λανθασμένο targetPort.

Επαλήθευση

kubectl get svc <service> -n <namespace> -o yaml
kubectl get pods -n <namespace> --show-labels
kubectl get endpoints <service> -n <namespace>
kubectl get endpointslice -n <namespace> -l kubernetes.io/service-name=<service>

Διόρθωση

• Ευθυγραμμίζετε τα Labels με τον Selector.
• Ελέγχετε το ReadinessProbe.
• Ελέγχετε τα Port Names και το targetPort.
• Διορθώνετε το Namespace.

12.5. Το DNS δεν λειτουργεί μέσα στο Cluster

Συνήθεις αιτίες

• Λανθασμένο όνομα Service ή Namespace.
• Το CoreDNS δεν λειτουργεί σωστά.
• Κάποιο NetworkPolicy μπλοκάρει το DNS.
• Το Service δεν έχει Endpoints, παρότι το DNS επιλύει το όνομα.

Επαλήθευση

kubectl run dns-debug --rm -it --image=busybox:1.36 --restart=Never -- nslookup kubernetes.default
kubectl run dns-debug --rm -it --image=busybox:1.36 --restart=Never -- nslookup <service>.<namespace>.svc.cluster.local
kubectl get pods -n kube-system -l k8s-app=kube-dns
kubectl logs -n kube-system -l k8s-app=kube-dns

Διόρθωση

• Διορθώνετε τα DNS Names.
• Ελέγχετε το CoreDNS.
• Επιτρέπετε Egress προς το DNS όταν είναι ενεργά Egress Policies.
• Ελέγχετε ξεχωριστά τα Service Endpoints.

12.6. Το Ingress ή το Gateway δεν δρομολογεί την κίνηση

Συνήθεις αιτίες

• Λείπει το IngressClass ή το GatewayClass.
• Ο Controller δεν εκτελείται.
• Το Host ή το Path είναι λανθασμένο.
• Το Backend Service δεν έχει Endpoints.
• Το TLS Secret λείπει ή είναι λανθασμένο.
• Κάποιο Annotation ειδικό για τον Controller είναι λανθασμένο.

Επαλήθευση

kubectl describe ingress <name> -n <namespace>
kubectl get ingressclass
kubectl get svc <backend-service> -n <namespace>
kubectl get endpoints <backend-service> -n <namespace>
kubectl logs -n <controller-namespace> deploy/<controller-deployment>

Διόρθωση

• Ελέγχετε τους κανόνες Routing.
• Διαβάζετε τα Logs του Controller.
• Διορθώνετε το Backend Service και τα Endpoints.
• Επαληθεύετε το TLS Secret και τα Hostnames.

12.7. RBAC Forbidden

Συνήθεις αιτίες

• Ο User ή το ServiceAccount δεν έχει αντίστοιχο RoleBinding.
• Το Role έχει συνδεθεί σε λανθασμένο Namespace.
• Ο πόρος ανήκει σε διαφορετικό API Group.
• Λείπει κάποιο απαιτούμενο Verb: get, list, watch, create, update, patch, delete.

Επαλήθευση

kubectl auth can-i get pods -n <namespace>
kubectl auth can-i get secrets -n <namespace> --as=system:serviceaccount:<namespace>:<serviceaccount>
kubectl get rolebinding,clusterrolebinding -A | grep <name>

Διόρθωση

• Προσδιορίζετε με ακρίβεια τα απαιτούμενα Verbs και Resources.
• Δημιουργείτε το RoleBinding στο σωστό Namespace.
• Μη χρησιμοποιείτε ευρύ ClusterRoleBinding όταν αρκεί ένα Role.

12.8. NodePressure

Συνήθεις αιτίες

• Δεν υπάρχει αρκετός ελεύθερος χώρος στον δίσκο.
• Δεν υπάρχει αρκετή διαθέσιμη μνήμη.
• Υπάρχουν υπερβολικά πολλά Logs ή προσωρινά αρχεία.
• Τα Images καταλαμβάνουν υπερβολικά πολύ χώρο.
• Υπάρχουν υπερβολικά πολλά Pods σε έναν Node.

Επαλήθευση

kubectl describe node <node>
kubectl get events -A --sort-by=.lastTimestamp
kubectl top nodes
kubectl top pods -A

Διόρθωση

• Ελέγχετε Requests και Limits.
• Περιορίζετε το Ephemeral Storage.
• Ελέγχετε το Log Rotation.
• Αφαιρείτε Images και Pods που δεν χρησιμοποιούνται.
• Αυξάνετε τη χωρητικότητα των Nodes ή κατανέμετε τα Workloads.

12.9. OOMKilled

Συνήθεις αιτίες

• Το Memory Limit είναι πολύ χαμηλό.
• Η εφαρμογή έχει Memory Leak.
• Δεν έχει ληφθεί υπόψη η μέγιστη αιχμή φορτίου.
• Η Cache αυξάνεται χωρίς όριο.

Επαλήθευση

kubectl describe pod <pod> -n <namespace>
kubectl get pod <pod> -n <namespace> -o jsonpath='{.status.containerStatuses[*].lastState}'
kubectl top pod <pod> -n <namespace>

Διόρθωση

• Μετράτε το Memory Profile.
• Προσαρμόζετε το Limit σε ρεαλιστική τιμή.
• Αναλύετε τα Memory Leaks.
• Θέτετε όριο στην αύξηση της Cache.
• Ορίζετε Alerts για τη χρήση μνήμης και τα Restarts.

12.10. Το PVC παραμένει σε κατάσταση Pending

Συνήθεις αιτίες

• Το StorageClass δεν υπάρχει.
• Το Dynamic Provisioning δεν λειτουργεί.
• Το Access Mode δεν υποστηρίζεται.
• Το Zone ή Node Affinity δεν ταιριάζει.
• Το Quota εμποδίζει το Provisioning.

Επαλήθευση

kubectl get pvc -n <namespace>
kubectl describe pvc <pvc> -n <namespace>
kubectl get storageclass
kubectl get events -n <namespace> --sort-by=.lastTimestamp

Διόρθωση

• Ελέγχετε το StorageClass.
• Ελέγχετε τον CSI Driver.
• Προσαρμόζετε το Access Mode.
• Ελέγχετε τα Quotas.
• Εξετάζετε τα σφάλματα του Controller που σχετίζονται με τον Provider.

12.11. Το HPA δεν κάνει Scaling

Συνήθεις αιτίες

• Το Metrics Server λείπει ή δεν παρέχει δεδομένα.
• Δεν έχουν οριστεί CPU Requests.
• Το Target Metric έχει οριστεί λανθασμένα.
• Τα minReplicas και maxReplicas εμποδίζουν την αναμενόμενη συμπεριφορά.
• Το φορτίο δεν φτάνει την τιμή στόχο.

Επαλήθευση

kubectl get hpa -n <namespace>
kubectl describe hpa <hpa> -n <namespace>
kubectl top pods -n <namespace>
kubectl get --raw /apis/metrics.k8s.io/v1beta1/pods

Διόρθωση

• Κάνετε Deploy ή διορθώνετε το Metrics Server.
• Ορίζετε Requests.
• Προσαρμόζετε το Metric και την τιμή στόχο.
• Εκτελείτε Load Test.
• Ελέγχετε τα όρια Scaling.

13. Ασκήσεις Workshop

Άσκηση 1: Ανασκόπηση Deployment

Εργασία

Λαμβάνετε ένα Deployment χωρίς Requests, Probes ή SecurityContext. Το επεξεργάζεστε ώστε να είναι κατάλληλο για το Workshop και να μπορεί να αξιολογηθεί σωστά.

Κριτήρια αποδοχής

• Κάθε Container έχει CPU και Memory Requests.
• Έχει οριστεί Memory Limit.
• Υπάρχει ReadinessProbe.
• Η χρήση LivenessProbe έχει αιτιολογηθεί.
• Το Container εκτελείται χωρίς δικαιώματα root.
• Το Privilege Escalation είναι απενεργοποιημένο.
• Το Image έχει συγκεκριμένη έκδοση.

Άσκηση 2: Debug Service χωρίς Endpoints

Αρχική κατάσταση

Υπάρχει ένα Service, αλλά η εφαρμογή δεν είναι προσβάσιμη.

Εργασία

Εντοπίστε αν το πρόβλημα οφείλεται στο DNS, στον Service Selector, στο Readiness ή στα Pod Labels.

Απαραίτητες εντολές

kubectl get svc -o yaml
kubectl get pods --show-labels
kubectl get endpoints
kubectl describe pod <pod>

Αποτέλεσμα

Τεκμηριώστε την αιτία, τη διόρθωση και την επαλήθευση.

Άσκηση 3: Εκχώρηση ελάχιστων δικαιωμάτων RBAC

Εργασία

Δημιουργήστε ServiceAccount που επιτρέπεται μόνο να διαβάζει Pods και Pod Logs σε ένα Namespace.

Κριτήρια αποδοχής

• Χωρίς ClusterRoleBinding.
• Χωρίς δικαιώματα εγγραφής.
• Επαλήθευση με kubectl auth can-i.

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

Εργασία

Ορίστε πρώτα default-deny σε ένα Namespace και έπειτα επιτρέψτε μόνο την κίνηση από τον Ingress Controller προς το API.

Κριτήρια αποδοχής

• Η μη εξουσιοδοτημένη επικοινωνία μεταξύ Pods μπλοκάρεται.
• Η επιτρεπόμενη HTTP κίνηση λειτουργεί.
• Το DNS συνεχίζει να λειτουργεί αν έχει περιοριστεί το Egress.

Άσκηση 5: Δοκιμή Rollout και Rollback

Εργασία

Κάντε Rollout μιας νέας έκδοσης Image, παρακολουθήστε τη διαδικασία και στη συνέχεια εκτελέστε Rollback.

Απαραίτητες εντολές

kubectl rollout status deployment/<name>
kubectl rollout history deployment/<name>
kubectl rollout undo deployment/<name>

Αποτέλεσμα

Τεκμηριώστε πώς διαπιστώσατε ότι το Rollout και το Rollback ολοκληρώθηκαν επιτυχώς.

14. Ετοιμότητα λειτουργίας

Μια λύση είναι έτοιμη για λειτουργία όταν μπορεί να αναπαραχθεί, να παρακολουθηθεί, να αναιρεθεί και να ελεγχθεί, χωρίς να περιέχει πραγματικά Secrets. Για το Kubernetes, όμως, αυτός ο σύντομος ορισμός δεν αρκεί. Χρησιμοποιήστε τον ακόλουθο πίνακα ωριμότητας.

Ελάχιστες απαιτήσεις για τις εργασίες του Workshop

Μια εργασία του Workshop θεωρείται έτοιμη για λειτουργία όταν μπορείτε να δείξετε τα εξής:

• Deployment, Service και Namespace έχουν οριστεί δηλωτικά.
• Οι πόροι ομαδοποιούνται ιχνηλάσιμα με Labels.
• Τα Images έχουν συγκεκριμένες εκδόσεις.
• Έχουν οριστεί Requests και εύλογα Limits.
• Υπάρχει ReadinessProbe.
• Μπορείτε να ελέγξετε Logs και Events.
• Rollout και Rollback έχουν τεκμηριωθεί.
• Δεν περιλαμβάνονται πραγματικά Secrets.
• Χρησιμοποιείται ξεχωριστό ServiceAccount ή έχει τεκμηριωθεί ότι δεν χρειάζεται.
• Έχει εφαρμοστεί τουλάχιστον ένα NetworkPolicy ή μέτρο ενίσχυσης του SecurityContext.
• Οι συνήθεις τρόποι αστοχίας έχουν τεκμηριωθεί.

15. Αναφορά εντολών

Context και Namespace

kubectl config current-context
kubectl config get-contexts
kubectl get namespaces
kubectl config set-context --current --namespace=<namespace>

Προβολή πόρων

kubectl get all -n <namespace>
kubectl get pods -n <namespace> -o wide
kubectl get deployment,rs,pod,svc,endpointslice -n <namespace>

Λεπτομέρειες και Events

kubectl describe pod <pod> -n <namespace>
kubectl get events -n <namespace> --sort-by=.lastTimestamp

Logs

kubectl logs <pod> -n <namespace>
kubectl logs <pod> -n <namespace> --previous
kubectl logs deployment/<deployment> -n <namespace>

Rollout

kubectl rollout status deployment/<deployment> -n <namespace>
kubectl rollout history deployment/<deployment> -n <namespace>
kubectl rollout undo deployment/<deployment> -n <namespace>

Επικύρωση Manifests

kubectl apply --dry-run=server -f k8s/
kubectl diff -f k8s/
kubectl apply -f k8s/

RBAC

kubectl auth can-i get pods -n <namespace>
kubectl auth can-i get secrets -n <namespace> --as=system:serviceaccount:<namespace>:<serviceaccount>

Network Debugging

kubectl run net-debug --rm -it --image=busybox:1.36 --restart=Never -- sh
nslookup <service>.<namespace>.svc.cluster.local
wget -S -O- http://<service>.<namespace>.svc.cluster.local

Πόροι

kubectl top nodes
kubectl top pods -A
kubectl describe quota -n <namespace>
kubectl describe limitrange -n <namespace>

16. Πηγές και περαιτέρω μελέτη

Το υλικό αυτό βασίζεται στην επίσημη τεκμηρίωση του Kubernetes και τη συμπληρώνει με πρακτικές οδηγίες ανασκόπησης και Workshop.

• Τεκμηρίωση Kubernetes: https://kubernetes.io/docs/home/
• Kubernetes API και δηλωτική διαχείριση Objects: https://kubernetes.io/docs/concepts/overview/kubernetes-api/
• kubectl apply: https://kubernetes.io/docs/reference/kubectl/generated/kubectl_apply/
• kubectl diff: https://kubernetes.io/docs/reference/kubectl/generated/kubectl_diff/
• Διαχείριση πόρων για Pods και Containers: https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/
• Liveness, Readiness και Startup Probes: https://kubernetes.io/docs/concepts/workloads/pods/probes/
• Services: https://kubernetes.io/docs/concepts/services-networking/service/
• Ingress: https://kubernetes.io/docs/concepts/services-networking/ingress/
• Gateway API: https://kubernetes.io/docs/concepts/services-networking/gateway/
• NetworkPolicies: https://kubernetes.io/docs/concepts/services-networking/network-policies/
• Βέλτιστες πρακτικές RBAC: https://kubernetes.io/docs/concepts/security/rbac-good-practices/
• ServiceAccounts: https://kubernetes.io/docs/concepts/security/service-accounts/
• Pod Security Standards: https://kubernetes.io/docs/concepts/security/pod-security-standards/
• Pod Security Admission: https://kubernetes.io/docs/concepts/security/pod-security-admission/
• Secrets: https://kubernetes.io/docs/concepts/configuration/secret/
• Βέλτιστες πρακτικές για Kubernetes Secrets: https://kubernetes.io/docs/concepts/security/secrets-good-practices/
• Images: https://kubernetes.io/docs/concepts/containers/images/
• Horizontal Pod Autoscaling: https://kubernetes.io/docs/concepts/workloads/autoscaling/horizontal-pod-autoscale/
• PodDisruptionBudgets: https://kubernetes.io/docs/tasks/run-application/configure-pdb/
• Αρχιτεκτονική Logging: https://kubernetes.io/docs/concepts/cluster-administration/logging/
• Auditing: https://kubernetes.io/docs/tasks/debug/debug-cluster/audit/