Merhaba! Ben

Federico Calò

Sviluppatore Software | Divulgatore Tecnico

Creo applicazioni web moderne e strumenti digitali personalizzati per aiutare le attività a crescere attraverso l'innovazione tecnologica. La mia passione è unire informatica ed economia per generare valore reale.

İletişime Geç

Hakkımda

La mia passione per l'informatica è nata tra i banchi dell'Istituto Tecnico Commerciale di Maglie, dove ho scoperto il potere della programmazione e il fascino di creare soluzioni digitali. Fin da subito, ho capito che l'informatica non era solo codice, ma uno strumento straordinario per trasformare idee in realtà.

Durante gli studi superiori in Sistemi Informativi Aziendali, ho iniziato a intrecciare informatica ed economia, comprendendo come la tecnologia possa essere il motore della crescita per qualsiasi attività. Questa visione mi ha accompagnato all'Università degli Studi di Bari, dove ho conseguito la Laurea in Informatica, approfondendo le mie competenze tecniche e la mia passione per lo sviluppo software.

Oggi metto questa esperienza al servizio di imprese, professionisti e startup, creando soluzioni digitali su misura che automatizzano processi, ottimizzano risorse e aprono nuove opportunità di business. Perché la vera innovazione inizia quando la tecnologia incontra le esigenze reali delle persone.

Yeteneklerim

Analisi Dati & Modelli Previsionali

Trasformo i dati in insights strategici con analisi approfondite e modelli predittivi per decisioni informate

Süreç Otomasyonu

Creo strumenti personalizzati che automatizzano operazioni ripetitive e liberano tempo per attività a valore aggiunto

Özel Sistemler

Sviluppo sistemi software su misura, dalle integrazioni tra piattaforme alle dashboard personalizzate

const federico = {
  nome: "Federico Calò",
  ruolo: "Sviluppatore Software",
  città: "Bari, Italia",
  missione: "Aiutare attraverso l'informatica",
  passioni: [
    "Codice Pulito",
    "Innovazione",
    "Crescita Continua"
  ]
};

Misyonum

Credo fermamente che l'informatica sia lo strumento più potente per trasformare le idee in realtà e migliorare la vita delle persone.

Teknolojiyi Demokratikleştirmek

La mia missione è rendere l'informatica accessibile a tutti: dalle piccole imprese locali alle startup innovative, fino ai professionisti che vogliono digitalizzare la propria attività. Ogni realtà merita di sfruttare le potenzialità del digitale.

BT ve İş Dünyasını Birleştirmek

Non è solo questione di scrivere codice: è capire come la tecnologia possa generare valore reale. Intrecciando competenze informatiche e visione economica, aiuto le attività a crescere, ottimizzare processi e raggiungere nuovi traguardi di efficienza e redditività.

Özel Çözümler Oluşturmak

Ogni attività è unica, e così devono esserlo le soluzioni. Sviluppo strumenti personalizzati che rispondono alle esigenze specifiche di ciascun cliente, automatizzando processi ripetitivi e liberando tempo per ciò che conta davvero: far crescere il business.

İşletmenizi Teknolojiyle Dönüştürün

Che tu gestisca un negozio, uno studio professionale o un'azienda, posso aiutarti a sfruttare le potenzialità dell'informatica per lavorare meglio, più velocemente e in modo più intelligente.

Konuşalım →

Unisciti alla Community

Entra nella community di sviluppatori dove discutiamo di software, AI, architettura e DevOps. Condividi idee, fai domande e cresci insieme a noi.

Canale

FC Dev Blog

Ricevi notifiche su nuovi articoli, serie complete, tips settimanali e tool in evidenza. Contenuti bilingui IT/EN direttamente nel tuo Telegram.

Nuovi articoli appena pubblicati
Tips e code snippets settimanali
Sondaggi sugli argomenti futuri

Iscriviti al Canale

Gruppo

FC Dev Community

Una community bilingue IT/EN per sviluppatori. Discussioni, Q&A, aiuto reciproco e networking con altri professionisti del settore.

Discussioni su articoli e tecnologie
Help coding e code review
Opportunità di lavoro e collaborazione

Unisciti al Gruppo

Topic di Discussione

Visualizza

Master SQL

RoadMap.sh

Novembre 2024

Visualizza

Oracle Certified Foundations Associate

Oracle

Ottobre 2024

Visualizza

People Leadership Credential

Connect

Settembre 2024

Linguaggi & Tecnologie

Java

Python

JavaScript

Angular

React

TypeScript

SQL

PHP

CSS/SCSS

Node.js

Docker

Git

💼

12/2024 - Presente

Custom Software Engineering Analyst

Accenture

Bari, Puglia, Italia · Ibrida Analisi e sviluppo di sistemi informatici attraverso l'utilizzo di Java e Quarkus in Health and Public Sector. Formazione continua su tecnologie moderne per la creazione di soluzioni software personalizzate ed efficienti e sugli agenti.

💼

06/2022 - 12/2024

Analista software e Back End Developer Associate Consultant

Links Management and Technology SpA

Esperienza nell'analisi di sistemi software as-is e flussi ETL utilizzando PowerCenter. Formazione completata su Spring Boot per lo sviluppo di applicazioni backend moderne e scalabili. Sviluppatore Backend specializzato in Spring Boot, con esperienza in progettazione di database, analisi, sviluppo e testing dei task assegnati.

💼

02/2021 - 10/2021

Programmatore software

Adesso.it (prima era WebScience srl)

Esperienza nell'analisi AS-IS e TO-BE, evoluzioni SEO ed evoluzioni website per migliorare le performance e l'engagement degli utenti.

🎓

2018 - 2025

Laurea in Informatica

Università degli Studi di Bari Aldo Moro

Bachelor's degree in Computer Science, focusing on software engineering, algorithms, and modern development practices.

📚

2013 - 2018

Diploma - Sistemi Informativi Aziendali

Istituto Tecnico Commerciale di Maglie

Technical diploma specializing in Business Information Systems, combining IT knowledge with business management.

İletişime Geç

Aklınızda bir proje mi var? Konuşalım! Formu doldurun, en kısa sürede dönüş yapacağım.

* Campi obbligatori. I tuoi dati saranno utilizzati solo per rispondere alla tua richiesta.

Kubernetes'te Çoklu Kiralama: Ad Alanı, Kaynak Kotası ve HNC

Tek bir ekip için tek bir Kubernetes kümesini yönetmek nispeten basittir. Gerçek zorluk, aynı kümeyi 10, 20, 50 takım arasında paylaşmak zorunda kaldığınızda başlar farklıdır ve her birinin kendi kaynak, güvenlik ve izolasyon gereksinimleri vardır. veya Müşterilerinize hizmet olarak Kubernetes'i sunduğunuzda ve A'nın B takımının iş yükünü göremez veya bunlara müdahale edemez, daha fazla tüketemez bütçesinin kaynakları ve şirket politikalarını atlayamaz.

Kubernetes şunları sunuyor: ad alanı temel yalıtım birimi olarak ancak gerçek çoklu kiracılık için tek başına yeterli değildir. Bu yazıda göreceğiz Eksiksiz bir çok kiracılı sistem nasıl oluşturulur: KaynakKotası ad alanı başına kaynakları sınırlamak için, Sınır Aralığı ayarlamak Konteyner başına varsayılanlar ve maksimumlar, Ağ Politikası trafiği izole etmek, e Hiyerarşik Ad Alanı Denetleyicisi (HNC) tesisleri yönetmek Politika mirasına sahip karmaşık organizasyon sistemleri.

Ne Öğreneceksiniz

Çoklu kiracılık modelleri: kiracı başına ad alanı ve kiracı başına küme
ResourceQuota: CPU, bellek, depolama ve ad alanı başına nesne sayısıyla ilgili sınırlamalar
LimitRange: kapsayıcılar için varsayılanlar ve maksimumlar, Pod'ların sınırsız önlenmesi
Ad alanları arası yalıtım için NetworkPolicy
Kiracılar için RBAC: her takım yalnızca kendi ad alanını görür
HNC (Hiyerarşik Ad Alanı Denetleyicisi): politikanın, kotanın ve RBAC'ın devralınması
Vcluster: güçlü izolasyon için eksiksiz sanal kümeler
Otomatik kiracı katılımına yönelik model

Çok Kiracılı Modeller

Uygulamaya geçmeden önce seviyenize göre doğru modeli seçmeniz gerekir. yalıtım gerekli:

Modeli	Yalıtım	Operasyonel Giderler	Maliyet	Kullanım Örneği
Ekip için ad alanı	Mantıksal (RBAC, Paylaş)	Bas	Asgari	Karşılıklı güvene sahip iç ekipler
Müşteri başına ad alanı (yumuşak çoklu kiracılık)	Mantıksal + Ağ	Orta	Bas	Temel izolasyona sahip SaaS
Sanal Küme (vcluster)	Güçlü (ayrı sunucu API'si)	Yüksek	Orta	Kurumsal müşteriler, CI/CD izolasyonu
Kiracı başına ayrı küme	Tamamlamak	Çok Uzun	Yüksek	Düzenleme, hassas veriler

KaynakKotası: Ad Alanlarına İlişkin Sınırlar

ResourceQuota, bir ad alanındaki tüm kaynaklar için toplam sınırları tanımlar. Bir ad alanının kotası olduğunda her kaynak oluşturma isteği gelir mevcut kotaya göre doğrulandı.

Bir Ekip için Tam KaynakKotası

# resource-quota-team-alpha.yaml
apiVersion: v1
kind: ResourceQuota
metadata:
  name: team-alpha-quota
  namespace: team-alpha
spec:
  hard:
    # Risorse compute
    requests.cpu: "20"          # max 20 vCPU richieste nel namespace
    limits.cpu: "40"            # max 40 vCPU limits
    requests.memory: "40Gi"     # max 40 GB RAM richiesta
    limits.memory: "80Gi"       # max 80 GB RAM limits

    # Storage
    requests.storage: "500Gi"   # max 500 GB storage totale
    persistentvolumeclaims: "20" # max 20 PVC

    # Per StorageClass specifica
    standard.storageclass.storage.k8s.io/requests.storage: "200Gi"
    ssd.storageclass.storage.k8s.io/requests.storage: "100Gi"

    # Oggetti Kubernetes
    pods: "100"                  # max 100 Pod
    services: "20"
    secrets: "50"
    configmaps: "50"
    replicationcontrollers: "20"
    services.nodeports: "0"      # nessun NodePort (usiamo Ingress)
    services.loadbalancers: "2"  # max 2 LoadBalancer

    # GPU (se applicabile)
    requests.nvidia.com/gpu: "4"  # max 4 GPU

# Verifica utilizzo quota
kubectl describe resourcequota team-alpha-quota -n team-alpha
# Output:
# Name:                                 team-alpha-quota
# Resource                              Used    Hard
# --------                              ---     ---
# limits.cpu                            8500m   40
# limits.memory                         12Gi    80Gi
# pods                                  35      100
# requests.cpu                          4200m   20

Hizmet Sınıfı Başına Kaynak Kotası

# resource-quota-by-priority.yaml
# Separa le quote per classe di priorita
# Usa PriorityClass per fare QoS
---
apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: high-priority
value: 1000
globalDefault: false
description: "Workload critici, non soggetti a eviction"
---
apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: low-priority
value: 100
globalDefault: true
description: "Workload batch, possono essere evicted"
---
# Quota separata per workload ad alta priorita
apiVersion: v1
kind: ResourceQuota
metadata:
  name: high-priority-quota
  namespace: team-alpha
spec:
  hard:
    pods: "10"
    requests.cpu: "8"
    requests.memory: "16Gi"
  scopeSelector:
    matchExpressions:
      - scopeName: PriorityClass
        operator: In
        values: ["high-priority"]

LimitRange: Kapsayıcılar için Varsayılanlar ve Maksimumlar

ResourceQuota, ad alanı düzeyinde çalışır ancak bir Kapsül, Resources.request'leri belirtmiyorsa, kota kullanımı hesaplayamaz. LimitRange bunu çözer: isteği ve limiti ayarlar her kapsayıcı için varsayılandır ve izin verilen minimum ve maksimum değerleri tanımlar.

# limitrange-team-alpha.yaml
apiVersion: v1
kind: LimitRange
metadata:
  name: team-alpha-limits
  namespace: team-alpha
spec:
  limits:
    # Valori di default per container (applicati se non specificati)
    - type: Container
      default:
        cpu: "500m"
        memory: "512Mi"
      defaultRequest:
        cpu: "100m"
        memory: "128Mi"
      # Massimi e minimi consentiti
      max:
        cpu: "4"
        memory: "8Gi"
      min:
        cpu: "10m"
        memory: "32Mi"
      # Ratio max/request per prevenire burst eccessivi
      maxLimitRequestRatio:
        cpu: "10"       # limit max 10x il request
        memory: "4"     # limit max 4x il request

    # Per i Pod (somma di tutti i container)
    - type: Pod
      max:
        cpu: "8"
        memory: "16Gi"

    # Per i PVC
    - type: PersistentVolumeClaim
      max:
        storage: "50Gi"
      min:
        storage: "1Gi"

Çoklu Kiralama için RBAC

Her kiracının yalnızca kendi ad alanını görmesi ve değiştirmesi gerekir. Bir desen oluşturalım Her yeni ekip için otomatikleştirilebilen tekrarlanabilir RBAC:

# onboarding-team-alpha.yaml
# Script di onboarding: crea namespace + quota + limitrange + RBAC
apiVersion: v1
kind: Namespace
metadata:
  name: team-alpha
  labels:
    team: alpha
    env: production
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/enforce-version: latest
---
# Gruppo di utenti: tutti i developer del team alpha
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: team-alpha-developers
  namespace: team-alpha
subjects:
  - kind: Group
    name: "team-alpha"
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: edit   # ClusterRole built-in: edit permette tutto tranne RBAC e quota
  apiGroup: rbac.authorization.k8s.io
---
# Tech Lead: puo anche gestire i quota (ma non cluster-admin)
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: team-alpha-lead
  namespace: team-alpha
subjects:
  - kind: User
    name: "alice@company.com"
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: admin   # ClusterRole built-in: admin = edit + gestione RBAC nel namespace
  apiGroup: rbac.authorization.k8s.io

# Verifica che il team non possa accedere ad altri namespace
kubectl auth can-i get pods --as-group=team-alpha --as=developer -n team-beta
# No
kubectl auth can-i get pods --as-group=team-alpha --as=developer -n team-alpha
# Yes

Çapraz Ad Alanı Yalıtımı için NetworkPolicy

# networkpolicy-tenant-isolation.yaml
# Isola completamente il namespace del tenant
# Permette solo traffico interno al namespace + DNS + monitoring
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: tenant-isolation
  namespace: team-alpha
spec:
  podSelector: {}    # tutti i Pod nel namespace
  policyTypes:
    - Ingress
    - Egress
  ingress:
    # Traffico solo da Pod nello stesso namespace
    - from:
        - podSelector: {}
    # Permetti dall'ingress controller (namespace ingress-nginx)
    - from:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: ingress-nginx
  egress:
    # Traffico solo verso Pod nello stesso namespace
    - to:
        - podSelector: {}
    # DNS
    - ports:
        - protocol: UDP
          port: 53
        - protocol: TCP
          port: 53
    # Monitoring: permetti scrape da namespace monitoring
    - to:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: monitoring
    # Accesso a servizi comuni (es. database condiviso, internal APIs)
    - to:
        - namespaceSelector:
            matchLabels:
              shared-service: "true"
      ports:
        - protocol: TCP
          port: 5432   # PostgreSQL condiviso
        - protocol: TCP
          port: 6379   # Redis condiviso

Hiyerarşik Ad Alanı Denetleyicisi (HNC)

HNC oluşturmanıza olanak tanır ad alanı hiyerarşileri mirası ile kaynaklar. Karmaşık organizasyon yapıları için idealdir: "ekip-alfa" ad alanı "team-alpha-dev", "team-alpha-staging", "team-alpha-prod" alt ad alanlarıyla otomatik olarak RBAC, NetworkPolicy, ResourceQuota ve LimitRange'ı üst öğeden devralırlar.

HNC kurulumu

# Installa HNC con kubectl
kubectl apply -f https://github.com/kubernetes-sigs/hierarchical-namespaces/releases/download/v1.1.0/default.yaml

# Oppure con Helm
helm repo add hnc https://kubernetes-sigs.github.io/hierarchical-namespaces/
helm install hnc hnc/hnc \
  --namespace hnc-system \
  --create-namespace \
  --version 1.1.0

# Installa il plugin kubectl per HNC
curl -L https://github.com/kubernetes-sigs/hierarchical-namespaces/releases/download/v1.1.0/kubectl-hns_linux_amd64 \
  -o /usr/local/bin/kubectl-hns
chmod +x /usr/local/bin/kubectl-hns

# Verifica
kubectl hns version

Bir Ekip için Ad Alanı Hiyerarşisi

# Crea la gerarchia: team-alpha e il namespace root
# team-alpha-dev e team-alpha-prod sono subnamespace

# Crea il namespace root
kubectl create namespace team-alpha

# Crea i subnamespace (HNC li gestisce)
kubectl hns create team-alpha-dev -n team-alpha
kubectl hns create team-alpha-staging -n team-alpha
kubectl hns create team-alpha-prod -n team-alpha

# Visualizza la gerarchia
kubectl hns tree team-alpha
# Output:
# team-alpha
# ├── team-alpha-dev
# ├── team-alpha-staging
# └── team-alpha-prod

# Configura cosa viene propagato dai parent ai children
kubectl hns config set-resource networkpolicies --mode Propagate
kubectl hns config set-resource rolebindings --mode Propagate
kubectl hns config set-resource limitranges --mode Propagate
# ResourceQuota NON viene propagata (ogni sub-namespace ha la sua)

Otomatik Kaynak Yayılımı

# Nel namespace parent team-alpha:
# Un RoleBinding qui viene propagato automaticamente a tutti i subnamespace

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: team-alpha-developers
  namespace: team-alpha   # propagato automaticamente a tutti i children
  annotations:
    propagate.hnc.x-k8s.io/select: "true"
subjects:
  - kind: Group
    name: "team-alpha-devs"
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: view   # view in tutti i subnamespace
  apiGroup: rbac.authorization.k8s.io

# RoleBinding specifico per prod: solo il tech lead
# Non si propaga ai children perche e in team-alpha-prod
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: prod-admin
  namespace: team-alpha-prod
subjects:
  - kind: User
    name: "alice@company.com"
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: edit
  apiGroup: rbac.authorization.k8s.io

# Verifica propagazione
kubectl get rolebindings -n team-alpha-dev | grep team-alpha-developers
# Il RoleBinding e apparso nel subnamespace per propagazione

vcluster ile Sanal Küme

Daha güçlü izolasyon için vcluster tam Kubernetes kümeleri oluşturur (kendi Bir ad alanı içinde çalışan API sunucusu, zamanlayıcı ve denetleyici yöneticisi) ana bilgisayar kümesinin. Kiracının vcluster'ına tam erişimi var ancak görmüyor ana bilgisayar kümesi.

# Installa vcluster CLI
curl -L -o vcluster "https://github.com/loft-sh/vcluster/releases/latest/download/vcluster-linux-amd64"
chmod +x vcluster
sudo mv vcluster /usr/local/bin

# Crea un virtual cluster per il team-beta
vcluster create team-beta-cluster \
  --namespace vcluster-team-beta \
  --connect=false \
  --helm-values vcluster-values.yaml

# vcluster-values.yaml
# vcluster:
#   image: ghcr.io/loft-sh/vcluster-k8s:1.30
# sync:
#   nodes:
#     enabled: true
#     syncAllNodes: false  # sync solo i nodi dove girano i Pod del vcluster
# resources:
#   limits:
#     cpu: "2"
#     memory: "2Gi"

# Connettiti al vcluster
vcluster connect team-beta-cluster --namespace vcluster-team-beta -- kubectl get nodes

Kiracı Katılım Otomasyonu

Çok sayıda ekibin bulunduğu kümelerde manuel katılım ölçeklenmez. Ortak bir model ve kullanım tüm işlemleri otomatik olarak oluşturan özel bir Operatör (veya basit bir komut dosyası/GitOps) CRD'den başlayarak yeni bir kiracı için gereken kaynaklar Tenant:

# tenant-crd.yaml - esempio con Capsule (operator per multi-tenancy)
# Capsule e un operator CNCF che automatizza la creazione di tenant
helm repo add clastix https://clastix.github.io/charts
helm install capsule clastix/capsule \
  --namespace capsule-system \
  --create-namespace

---
# tenant.yaml - definisci un tenant con Capsule
apiVersion: capsule.clastix.io/v1beta2
kind: Tenant
metadata:
  name: team-alpha
spec:
  owners:
    - name: alice@company.com
      kind: User
    - name: team-alpha-admins
      kind: Group
  namespaceOptions:
    quota: 10         # max 10 namespace per questo tenant
    forbiddenLabels:
      denied: ["environment=production"]  # il tenant non puo creare ns con certi label
  resourceQuotas:
    scope: Tenant    # quota aggregata su tutti i namespace del tenant
    items:
      - hard:
          requests.cpu: "50"
          requests.memory: "100Gi"
          requests.storage: "1Ti"
  limitRanges:
    items:
      - limits:
          - type: Container
            default:
              cpu: "500m"
              memory: "512Mi"
            defaultRequest:
              cpu: "100m"
              memory: "128Mi"
  networkPolicies:
    items:
      - podSelector: {}
        policyTypes:
          - Ingress
          - Egress
        ingress:
          - from:
              - podSelector: {}
  nodeSelector:
    kubernetes.io/os: linux
    # Possibile restringere il tenant a nodi specifici:
    # tenant: team-alpha

Oran İzleme

# Vedi utilizzo quota di tutti i namespace
kubectl get resourcequota -A -o custom-columns=\
  "NAMESPACE:.metadata.namespace,NAME:.metadata.name,\
  CPU-REQ:.status.used.requests\.cpu,CPU-LIM:.status.used.limits\.cpu,\
  MEM-REQ:.status.used.requests\.memory"

# Alert Prometheus per quota vicina al limite
# Aggiungi questa regola PrometheusRule:
apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: namespace-quota-alerts
  namespace: monitoring
spec:
  groups:
    - name: quota
      rules:
        - alert: NamespaceCPUQuotaExceeding80Percent
          expr: |
            kube_resourcequota{resource="requests.cpu",type="used"} /
            kube_resourcequota{resource="requests.cpu",type="hard"} > 0.8
          for: 5m
          labels:
            severity: warning
          annotations:
            summary: "Namespace {{ $labels.namespace }} al {{ $value | humanizePercentage }} della quota CPU"

        - alert: NamespaceMemoryQuotaExceeding90Percent
          expr: |
            kube_resourcequota{resource="requests.memory",type="used"} /
            kube_resourcequota{resource="requests.memory",type="hard"} > 0.9
          for: 5m
          labels:
            severity: critical
          annotations:
            summary: "Namespace {{ $labels.namespace }} al 90% della quota memoria"

Çoklu Kiracılığa İlişkin En İyi Uygulamalar

Çoklu Kiracılı Üretim Kontrol Listesi

Ekip ortamı başına bir ad alanı: takım-alfa-geliştirme, takım-alfa-hazırlama, takım-alfa-ürün; Aynı ad alanındaki ortamları karıştırmaktan kaçının
ResourceQuota her zaman tanımlanır: kota olmadan bir ekip tüm küme kaynaklarını tüketebilir ve diğer kiracıları etkileyebilir
Varsayılanlar için LimitRange: Kaynak istekleri olmayan Pod'ların ResourceQuota'ları ve küme planlamasını işe yaramaz hale getirmesini önler
NetworkPolicy varsayılan reddetme: her ad alanının tüm yetkisiz ad alanları arası trafiği engelleyen bir politikası olmalıdır
Pod Güvenlik Standartları kısıtlandı: kısıtlı düzeyi tüm kiracı ad alanlarına uygular (bkz. makale 6)
RBAC en az ayrıcalığı: geliştiriciler ClusterRole'u kullanıyor edit, Olumsuz admin o cluster-admin
Erişim denetimi: her ad alanında kimin neye eriştiğini izlemek için denetim günlüğünü etkinleştirin
Katılımı otomatikleştirin: tüm kiracı nesnelerini tutarlı bir şekilde oluşturmak için Capsule'ü, özel bir Operatörü veya GitOps bildirimini kullanın

Çok Kiracılı Kubernetes'in Tuzakları

Ad alanı tam izolasyon değildir: bazı küme kapsamlı nesneler (ClusterRole, PersistentVolume, Node) tüm kiracılar tarafından görülebilir; tam izolasyona ihtiyacınız varsa vcluster kullanın
Paylaşılan çekirdek güvenlik açıkları: tüm kiracılar aynı Linux çekirdeğini paylaşır; çekirdekteki bir güvenlik açığından yararlanan bir konteyner diğer kiracıları etkileyebilir; Hassas verilere sahip kiracılar için özel düğümleri değerlendirin
DNS sızıntısı: Varsayılan olarak Pod'lar, Hizmet adlarını diğer ad alanlarına çözümleyebilir (service.namespace.svc.cluster.local); Gerekirse ad alanları arası DNS trafiğini de engellemek için NetworkPolicy'yi kullanın
LimitRange olmadan KaynakKotası: LimitRange yoksa, kaynak istekleri olmayan Kapsüller ResourceQuota'yı yok sayar ve kota doğru şekilde ölçeklenmez

Sonuçlar ve Sonraki Adımlar

Kubernetes'teki çoklu kiracılık, operasyonel basitlik ile yalıtım arasında bir sürekliliktir güçlü. Dahili ekiplere sahip çoğu iş senaryosu için ResourceQuota'ya sahip ad alanları, Uygun LimitRange, NetworkPolicy ve RBAC ile yeterli izolasyon sağlanır. minimum operasyonel masraf. Kurumsal müşteriler veya uyumluluk gereksinimleri olan senaryolar için vcluster, avantajları korurken çok daha güçlü bir izolasyon düzeyi sunar Kaynak verimliliği açısından paylaşılan bir kümenin.

HNC, ad alanı hiyerarşilerinin yönetimini ölçeklenebilir bir şeye dönüştürüyor: RBAC ve NetworkPolicy'yi her alt ad alanında manuel olarak kopyalamak zorunda olan politikaları üst ad alanına bir kez yerleştirir ve otomatik olarak yayılır. Platformlar için Düzinelerce ekiple bu, bakımı yapılabilir bir sistem ile bakım gerektiren bir sistem arasındaki farkı yaratır. yalnızca ad alanı yapılandırmasını yönetmek için özel bir ekip.

Kubernetes at Scale Serisinde Yaklaşan Makaleler

Önceki Makaleler

İlgili Seriler

Kubernetes güvenliği — RBAC ve Pod Güvenlik Standartları, çoklu kiracılığın önkoşulları
Platform Mühendisliği — Dahili Geliştirici Platformlarının temeli olarak çoklu kiracılık
Kubernetes için FinOps — ad alanları ve kiracılar için maliyet yönetimi