Связаны ли Namespaces между собой в Kubernetes

Взаимосвязь Namespaces в Kubernetes

Namespaces в Kubernetes логически изолируют ресурсы внутри одного кластера, но они не полностью отрезаны друг от друга. Можно сказать, что они существуют в своего рода "слабосвязанном" состоянии, где по умолчанию изолированы, но при необходимости могут взаимодействовать через явную настройку. Давайте рассмотрим это подробнее с технической точки зрения.

Основная изоляция по умолчанию

По умолчанию ресурсы в разных пространствах имен не видны друг другу. Это фундаментальный принцип мультитенантности и организации в Kubernetes.

1. Изоляция ресурсов:

    *   Pod, Service, Deployment, ConfigMap, созданные в `namespace-a`, не будут доступны по умолчанию из `namespace-b`.
    *   Команда `kubectl get pods` покажет поды только в текущем или указанном namespace. Чтобы увидеть все, нужен флаг `--all-namespaces`.

1. Изоляция DNS:

    *   Service в Kubernetes получает DNS-запись вида `<service-name>.<namespace-name>.svc.cluster.local`.
    *   Если Pod из `namespace-a` обращается просто по имени сервиса `my-service`, система DNS автоматически дополнит его до `my-service.namespace-a.svc.cluster.local`.
    *   **Для доступа к сервису в другом namespace необходимо использовать полное доменное имя (FQDN):** `my-service.namespace-b.svc.cluster.local`.

# Пример Deployment и Service в namespace "backend"
apiVersion: v1
kind: Service
metadata:
  name: api-service
  namespace: backend # Сервис создается в namespace "backend"
spec:
  selector:
    app: api
  ports:
    - port: 80
---
# Pod в namespace "frontend" может подключиться к этому сервису,
# используя полное DNS-имя:
# api-service.backend.svc.cluster.local

Механизмы взаимодействия между Namespaces

Хотя изоляция есть, существует несколько важных способов организовать контролируемое взаимодействие.

1. Явное обращение по DNS (FQDN): Как уже упоминалось, это базовый способ. Любой Pod в любом namespace может подключиться к Service в другом namespace, если знает его полное DNS-имя и нет сетевых политик, блокирующих этот трафик.

2. Сетевые политики (Network Policies):

    *   Это механизм **не для связи, а для контроля** изоляции на сетевом уровне (L3/L4).
    *   По умолчанию, если не установлена ни одна политика, все Podы во всех namespaces могут общаться друг с другом (зависит от CNI-плагина).
    *   С помощью `NetworkPolicy` можно явно разрешить или запретить трафик между Podами, используя селекторы как по меткам, так и по **пространствам имен**.

# NetworkPolicy, разрешающая трафик из namespace "frontend"
# к Podам с label role=api в текущем namespace.
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-from-frontend-namespace
  namespace: backend
spec:
  podSelector:
    matchLabels:
      role: api
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: frontend # Важно: namespace должен иметь эту метку.

1. Общие ресурсы (Global Resources):

    *   Некоторые ресурсы кластера являются **глобальными (cluster-scoped)** и не принадлежат какому-либо namespace. Они доступны из всех namespaces.
    *   К ним относятся: `PersistentVolume` (PV), `StorageClass`, `CustomResourceDefinition` (CRD), `ClusterRole`, `Node`, сам `Namespace`.
    *   Например, Pod из любого namespace может запросить `PersistentVolumeClaim` (PVC), который привязан к глобальному PV.

1. RBAC и доступ к ресурсам в других namespaces:

    *   Роли (`Role`) привязаны к конкретному namespace.
    *   **Кластерные роли (`ClusterRole`)** могут предоставлять разрешения на:
        *   Глобальные ресурсы.
        *   Ресурсы во всех namespaces (например, `get pods` по всему кластеру).
        *   Ресурсы в конкретных namespaces через `ClusterRoleBinding`, ссылающийся на пользователя/группу и `ClusterRole`.

# ClusterRole, позволяющий просматривать Podы во ВСЕХ namespaces
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: global-pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]

Что строго изолировано?

• Имена ресурсов: Два Podа с именем app могут существовать одновременно в разных namespaces, потому что их полный идентификатор уникален за счет namespace.
• Метки и аннотации ресурсов: Они не пересекаются между namespaces.
• Квоты ресурсов (ResourceQuota): Устанавливаются и контролируются для каждого namespace независимо. Потребление CPU/RAM в namespace-a не влияет на лимиты в namespace-b.
• Политики безопасности (Pod Security Standards/Admission): Могут применяться с разной строгостью к разным namespaces.

Итог: Namespaces в Kubernetes логически связаны через DNS и общую сеть кластера, но административно и по умолчанию изолированы. Они не являются полноценными "виртуальными кластерами" (для этого есть проекты вроде vClusters или HNC), а скорее удобным инструментом группировки и разделения ресурсов внутри единого кластера. Их основная цель — предоставить область видимости для имен ресурсов и механизм для применения политик (сетевых, RBAC, квот) к группам ресурсов, что критически важно для мультитенантных сред, разделения staging/production или организации по микросервисам.