Вопросы на собеседовании: Kubernetes-инженер

Controller постоянно сравнивает наблюдаемое состояние кластера с объявленным желаемым состоянием и уменьшает расхождение.

• Пользователь передаёт intent через API objects, а не отправляет узлам фиксированную последовательность команд.
• Controllers наблюдают resources и используют labels, selectors и owner references для управления зависимыми объектами.
• Reconciliation повторяется и должен быть idempotent, потому что events могут дублироваться, а state меняться между наблюдениями.
• Status хранит наблюдаемый результат, а spec остаётся запрошенным состоянием, к которому стремится controller.

Deployment управляет stateless replicated Pods через ReplicaSets и предоставляет declarative rollout и rollback.

• Его selector находит принадлежащие ему Pods, а Pod template задаёт желаемую revision.
• Изменение template создаёт новый ReplicaSet и переносит replicas согласно update strategy.
• Controller заменяет failed или deleted Pods, поддерживая заданное число replicas.
• Имена и identity Pods являются disposable, поэтому durable identity или storage не должны зависеть от конкретной replica.

maxSurge ограничивает дополнительные Pods сверх желаемого числа replicas, а maxUnavailable ограничивает число недоступных желаемых replicas во время rollout.

• Больший surge ускоряет замену, но требует свободной cluster capacity.
• Меньшая unavailability защищает serving capacity, но замедляет progress при постепенном запуске новых Pods.
• Оба значения принимают абсолютные числа или проценты с правилами округления Deployment controller.
• Readiness определяет, считается ли новый Pod доступным, поэтому безопасность rollout зависит от осмысленной readiness probe.

StatefulSet подходит, когда replicas требуют стабильной identity, упорядоченного lifecycle или отдельного persistent storage.

• Pods получают предсказуемые ordinal names и стабильную network identity после rescheduling.
• volumeClaimTemplates создаёт отдельный PVC для каждого ordinal вместо одного disposable shared volume.
• OrderedReady управляет стандартным порядком создания, scaling и updates, а Parallel pod management ослабляет часть порядка.
• StatefulSet не делает приложение распределённым и не реплицирует данные, эти свойства должен реализовать сам workload.

Headless Service предоставляет стабильные DNS records отдельных StatefulSet Pods без virtual Service IP перед ними.

• clusterIP None заставляет DNS возвращать Pod addresses вместо одного load-balanced address.
• Каждый ordinal получает предсказуемое имя вида pod-0.service.namespace.svc.
• Peer-aware systems используют эти records для discovery, membership или leader coordination.
• Readiness и publishNotReadyAddresses выбираются осознанно, если peers должны находить друг друга до готовности.

DaemonSet запускает Pod на каждом подходящем node или на каждом node, совпадающем с его scheduling constraints.

• Типичные применения: log collectors, node monitoring agents, CNI components и storage node plugins.
• Новые подходящие nodes автоматически получают Pod, а Pods исчезают при уходе своих nodes из кластера.
• Node selectors, affinity и taints определяют, какие классы nodes фактически запускают daemon.
• Application replicas, масштабируемые по traffic, обычно принадлежат Deployment, а не DaemonSet.

Job создаёт Pods, пока не получит заданное число успешных completions или пока failure policy не остановит попытки.

• completions задаёт нужное число успехов, а parallelism ограничивает число одновременно работающих Pods.
• backoffLimit ограничивает retries, а activeDeadlineSeconds ограничивает общее время выполнения.
• restartPolicy должна быть Never или OnFailure, потому что успешные Job Pods не должны перезапускаться бесконечно.
• Indexed Jobs дают параллельным workers стабильные completion indexes, если input можно детерминированно разделить.

CronJob создаёт Jobs по расписанию и требует явных правил для пропущенных запусков, пересечений, time zones и history.

• concurrencyPolicy определяет, разрешить overlapping runs, пропустить их или заменить.
• startingDeadlineSeconds ограничивает опоздание, при котором пропущенное расписание ещё может создать Job.
• Поле timeZone явно задаёт трактовку расписания вместо зависимости от defaults controller.
• Successful и failed history limits не дают старым Job objects накапливаться без ограничений.

OnFailure может перезапустить failed container внутри того же Pod, а Never оставляет Pod в terminal state и позволяет Job создать новый.

• Pod-level restarts сохраняют identity Pod, но историю attempts сложнее видеть как отдельные objects.
• Never представляет каждую failed attempt отдельным Pod, упрощая inspection ценой большего числа объектов.
• backoffLimit всё равно управляет retries Job, хотя per-index policies уточняют indexed workloads.
• Task должна выдерживать retries, потому что Kubernetes не гарантирует отсутствие внешнего side effect у failed attempt.

Selector controller задаёт владение совпадающими Pods, поэтому должен соответствовать labels template и не пересекаться с другими controllers.

• Selector, не совпадающий с Pod template, отклоняется для controllers вроде Deployment.
• Пересекающиеся selectors заставляют controllers конкурировать за похожие Pods и создают небезопасные предположения о владении.
• Selectors Deployment immutable в стабильном API, поэтому смена identity обычно требует нового Deployment.
• Labels только для release или observability следует отделять от стабильных labels, задающих identity controller.

Тип Service определяет, как стабильный virtual endpoint открывается за пределами выбранных Pods.

• ClusterIP доступен внутри кластера и является default для internal service discovery.
• NodePort открывает одинаковый port на подходящих nodes и направляет traffic в Service, часто являясь building block, а не конечным public interface.
• LoadBalancer просит поддерживаемый cloud или implementation controller создать внешний load balancer, обычно поверх Service networking.
• Все три по-прежнему зависят от selectors или явных EndpointSlices, указывающих ready backends.

Ingress объявляет intent HTTP routing, а Ingress Controller наблюдает его и настраивает конкретный proxy или load balancer.

• Создание Ingress без подходящего controller не создаёт data-plane implementation.
• ingressClassName выбирает controller class, если в кластере несколько implementations.
• Host и path rules направляют requests в Kubernetes Services, а не напрямую в произвольные Pods.
• Controller-specific annotations добавляют возможности, но снижают portability за пределами стандартного Ingress API.

Ingress сопоставляет hosts и paths запросов с Service backends, а его TLS section связывает hosts с certificate Secrets.

• Exact точно совпадает с одним path, а Prefix сопоставляет path segments по правилам Kubernetes.
• ImplementationSpecific делегирует matching выбранному controller и менее portable.
• TLS Secret обычно содержит tls.crt и tls.key в том же namespace, что и Ingress.
• Termination на controller защищает client connection, а backend encryption требует отдельной настройки controller и service.

Gateway API разделяет infrastructure attachment и application routes и предоставляет более богатые typed routing resources.

• GatewayClass определяет implementation, Gateway задаёт listeners, а HTTPRoute и другие routes подключают traffic rules.
• allowedRoutes определяет, Routes из каких namespaces могут подключаться к Gateway, а ReferenceGrant разрешает cross-namespace references на объекты вроде backends.
• Status conditions стандартизированно показывают acceptance и attachment route.
• Ingress остаётся подходящим для простого HTTP routing, а Gateway API чище моделирует shared и multi-team traffic infrastructure.

Default-deny policy выбирает Pods и изолирует их так, чтобы принимался только traffic, разрешённый другими applicable policies.

• Ingress и egress isolation независимы и объявляются для нужных направлений denial.
• Пустой список ingress или egress rules не разрешает traffic в этом направлении для выбранных Pods.
• Policies складываются, поэтому последующая policy добавляет разрешённый traffic, а не переопределяет default-deny object.
• Enforcement требует network plugin, реализующего семантику NetworkPolicy.

Selectors внутри одной peer entry объединяются через AND, а отдельные peer entries представляют альтернативные разрешённые sources или destinations.

• podSelector без namespaceSelector выбирает matching Pods в namespace policy.
• namespaceSelector без podSelector выбирает все подходящие Pods в matching namespaces.
• Оба selectors в одной entry выбирают matching Pods только внутри matching namespaces.
• Отступы YAML важны, потому что разделение selectors на две entries расширяет доступ вместо его сужения.

Egress isolation обычно требует явного разрешения Pods обращаться к cluster DNS service до работы name-based application traffic.

• Policy может выбрать DNS Pods и разрешить UDP и TCP на настроенном DNS port.
• Фактические namespace и labels зависят от cluster DNS deployment и не должны угадываться по примерам.
• Стандартная NetworkPolicy управляет IP и port traffic, а не произвольными DNS names после resolution.
• Доступ к DNS сам по себе не разрешает resolved destination, которому всё ещё нужна отдельная egress rule.

Стандартная NetworkPolicy предоставляет namespaced L3 и L4 allow rules, но определяет не все возможности network security.

• В ней нет native deny-rule priority, потому что applicable allow policies складываются.
• HTTP paths, methods и другие L7 attributes требуют CNI-specific policy или другого proxy layer.
• Поведение policy для host networking и части node traffic зависит от network implementation.
• Такие продукты, как Cilium, расширяют модель, но их resources не являются portable Kubernetes NetworkPolicy.

Ephemeral storage следует lifecycle Pod или container, а persistent storage представлен отдельно и переживает замену Pod.

• emptyDir создаётся для Pod и удаляется, когда этот Pod окончательно покидает node.
• PVC ссылается на durable storage, чей lifecycle управляется claims, volumes и reclaim policy, а не одним container restart.
• ConfigMap, Secret и projected volumes предоставляют configuration data, а не общее durable application storage.
• Выбор volume начинается с требований durability, sharing, access mode и storage provider.

PVC запрашивает свойства storage, а Kubernetes привязывает его к одному совместимому PV или динамически создаёт подходящий volume.

• Совместимость включает requested capacity, access modes, storageClassName и selector constraints.
• Binding является one-to-one, даже если underlying storage поддерживает доступ нескольких Pods.
• PVC является namespaced, а PV представляет storage на cluster scope.
• Pod ссылается на PVC, а не provider-specific детали PV, отделяя intent workload от infrastructure.