Ниже приведены фирменные термины, терминология и аббревиатуры, которые встречаются в этом документе.
Glossary | Description |
---|---|
Cluster | Кластер Kubernetes управляет инфраструктурными ресурсами, необходимыми для запуска контейнеров в платформе контейнеров Kubernetes, и связан с различными ресурсами, такими как несколько узлов, балансировщики нагрузки и приватные сети. Кластер с одной точкой имеет только один управляющий узел, тогда как высокодоступный кластер имеет не менее 3 управляющих узлов. |
Node | Узел в кластере делится на два типа: управляющие узлы (Master) и вычислительные узлы (Node). Управляющие узлы отвечают за запуск kube-apiserver, kube-scheduler, kube-controller-manager, etcd, сетей контейнеров и некоторых компонентов управления платформой. Вычислительные узлы — это узлы в кластере Kubernetes, которые несут нагрузку, и могут быть виртуальными или физическими машинами. Вычислительные узлы отвечают за фактическое планирование Pod и взаимодействие с управляющими узлами. |
Project | Проекты (тенанты) платформы могут гибко разделяться на независимые и изолированные пространства ресурсов, и каждый проект имеет независимую проектную среду, которая может представлять различные дочерние компании, отделы или проектные команды внутри предприятия. Через управление проектами легко обеспечить изоляцию ресурсов между проектными командами и управление квотами внутри тенантов. |
Namespace | Kubernetes Namespace — это более мелкое пространство ресурсов, изолированное от других пространств в проекте на платформе, а также рабочее пространство для пользователей для реализации производственных задач. Под одним проектом можно создавать несколько пространств имен, при этом общий лимит ресурсов не может превышать квоту проекта. За счёт деления квот ресурсов на более мелкие пространства, также ограничивается размер контейнеров (CPU, память) в пространстве, что эффективно повышает использование ресурсов. |
Image | Образ контейнера — это стандартный формат упаковки контейнерных приложений. При развертывании контейнеризованных приложений можно указывать образы, которые могут поступать из Docker Hub, репозитория образов платформы DevOps компании или из приватного репозитория пользователя. Идентификатор образа может быть однозначно определён URI репозитория образов и тегом образа (по умолчанию latest). |
Container | Процесс, который запускается на хосте и создаётся на основе образа. |
Pod | Pod — это наименьшая базовая единица для развертывания приложений или сервисов в Kubernetes. Pod инкапсулирует несколько контейнеров приложений (или только один контейнер), ресурсы хранения, независимый сетевой IP и параметры политики, контролирующие способ запуска контейнеров. |
Workload | Компоненты, составляющие приложение на платформе, и объединённые под общим названием программы, которые могут комбинироваться для предоставления сервисов или работать автономно, создаются на основе образов. |
Replication Controller | RC обеспечивает, что в кластере Kubernetes всегда запущено заданное количество реплик Pod. Контроллер отслеживает запущенные Pod и гарантирует, что в кластере работает указанное число реплик Pod. Это число может быть больше одного или равно 1. Если количество меньше заданного, RC запускает новые реплики Pod. Если больше — RC завершает избыточные реплики Pod. |
ReplicaSet | ReplicaSet (RS) — это усовершенствованная версия RC, единственное отличие — поддержка селекторов. RS поддерживает больше типов шаблонов сопоставления. Объекты ReplicaSet обычно не используются самостоятельно, а служат параметрами желаемого состояния для Deployments. |
Deployment | Deployment обеспечивает декларативные обновления для ReplicaSets (replication controllers) и Pods (групп контейнеров). Описывая желаемое состояние для реплик (число Pod) и контейнеров, контроллер Deployment изменяет фактическое состояние Pod и ReplicaSets на желаемое. |
Configmap | Kubernetes ConfigMap использует пары ключ-значение для хранения конфигурационных данных, которые могут содержать отдельные атрибуты или конфигурационные файлы. Управление конфигурациями для контейнеризованных приложений достигается с помощью ConfigMap, отделяя конфигурации от содержимого образа и сохраняя переносимость контейнеризованных приложений. |
Secret | Kubernetes Secret используется для хранения конфиденциальной информации или конфигураций в кластере Kubernetes, таких как пароли пользователей, OAuth-токены, приватные SSH-ключи, данные аутентификации для доступа к репозиториям образов и т. д. Рекомендуется в первую очередь использовать Secret для хранения секретных словарей. |
Service | Kubernetes Service определяет логическую коллекцию Pod и поддерживает настройку политик доступа для вычислительных компонентов внутри кластера. Это эквивалент внутреннего сервиса в кластере и обеспечивает единый вход для доступа другим вычислительным компонентам или посетителям, находящимся внутри кластера, реализуя функцию внутреннего обнаружения вычислительных компонентов. |
CustomResourceDefinition | В API Kubernetes ресурс — это конечная точка, используемая для хранения коллекции объектов API определённого типа. Объект CRD определяет новый уникальный тип объекта в кластере и позволяет API-серверу Kubernetes управлять полным жизненным циклом объекта. Kubernetes поддерживает пользователей в настройке расширенных ресурсов Kubernetes через API CustomResourceDefinition и обеспечивает быструю регистрацию и использование новых ресурсов. |
Domain | Администраторы могут использовать функцию управления доменными именами для централизованного управления ресурсами доменных имён корпоративной сети, используемых для этой платформы, а также распределять и управлять доменными именами между проектами путём привязки доменов к проектам. |
Role | Роль — это набор разрешений на операции. Разрешения на операции с ресурсами на платформе включают создание, просмотр, обновление и удаление. Платформа классифицирует и объединяет разрешения на операции с разными ресурсами через роли. Роль может содержать одно или несколько разрешений на операции для одного или нескольких типов ресурсов. Назначая конкретные роли пользователям, можно быстро открыть или ограничить разрешения на операции с указанными ресурсами. |
Event | Платформа интегрируется с событиями Kubernetes, записывая важные изменения статуса ресурсов Kubernetes и различные события изменения состояния во время выполнения. Через события можно анализировать конкретные причины аномалий в определённых ресурсах, таких как кластеры, приложения, задачи и т. д. |
Audit | Платформа интегрируется с аудитом Kubernetes, предоставляя хронологически упорядоченные записи операций, связанных с безопасностью, включая время, источник, результат операции, пользователя, инициировавшего операцию, ресурсы, с которыми производились действия, и подробную информацию о запросах/ответах и т. д. Через аудит аудиторы платформы могут чётко понимать изменения в кластере Kubernetes. |
Log | Платформа интегрируется с логами Kubernetes, что позволяет быстро собирать логи контейнеров в кластере Kubernetes, включая стандартный вывод контейнеров и текстовые файлы внутри контейнеров. Одновременно поддерживается сбор логов Kubelet, Docker и компонентов контейнеризации Kubernetes. |
Token | Токен, выдаваемый системой пользователю, несущий информацию, такую как идентичность пользователя и его права. При вызове API пользователем токен добавляется в заголовок сообщения запроса, и через аутентификацию личности можно получить разрешение на вызов ресурса операции API. |
Microservice | Микросервисы — это архитектура и метод организации разработки программного обеспечения, состоящие из небольших, независимых сервисов. Сервисы на платформе относятся к внутреннему маршрутизированию и связанным вычислительным компонентам. |
Microservice | Микросервисы — это архитектура и метод организации разработки программного обеспечения, состоящие из небольших, независимых сервисов. Сервисы на платформе относятся к внутреннему маршрутизированию и связанным вычислительным компонентам. |
Service Mesh | Service mesh — это настраиваемый инфраструктурный слой для приложений микросервисов. Он делает коммуникацию между каждым экземпляром сервиса более плавной, надёжной и быстрой. Service mesh предоставляет ряд функций, таких как обнаружение сервисов, балансировка нагрузки, шифрование, аутентификация личности, авторизация, поддержка паттерна Circuit Breaker и другие возможности. |
External Service | Внешний сервис — относительное понятие, и для сервисов внутри service mesh все сервисы вне service mesh считаются внешними сервисами. |
Microservice Gateway | Вход и выход архитектуры микросервисов, сервисный шлюз (Istio gateway) может обеспечивать маршрутизацию, управление API, фильтрацию проверки прав и другие возможности для платформ управления микросервисами. Сервисный шлюз включает ingress gateway и egress gateway. |
Ingress Gateway | Ingress gateway — один из важных объектов ресурсов в Istio, который определяет точку входа для всего входящего трафика, проходящего через service mesh. Он используется для управления входящим трафиком на границе mesh и маршрутизации этого трафика. |
Egress Gateway | Egress gateway — один из важных объектов ресурсов в Istio, который определяет точку выхода исходящего трафика из service mesh. Внешние сервисы, зарегистрированные в mesh, могут быть привязаны к egress gateway, благодаря чему трафик доступа наружу отправляется через egress gateway. |
Tracing | Трассировка — это цепочка процессов одного вызова запроса, а TraceID — уникальный идентификатор этого вызова запроса. При сложных отношениях вызовов несколько цепочек вызовов имеют одинаковый TraceID. |
Sidecar | Паттерн sidecar — это шаблон проектирования для распределённых архитектур, который разделяет управление и логику путём разделения функций приложения на отдельные процессы. В системе микросервисов функции сервиса, интегрированные в приложение, выносятся в sidecar, который может быть развернут как независимый процесс в приложении, предоставляя обнаружение сервисов, регистрацию, вызов сервисов, аутентификацию приложений, ограничение скорости и другие функции. |
Service Topology | Топология сервиса — это визуализированная диаграмма топологии отношений вызовов сервисов на платформе. Просматривая топологию сервиса, можно понять вызовы сервисов и их производительность на платформе за указанный период времени. |
API Group | Группировка API — это измерение для управления сервисами и API сервисов в проекте управления сервисным шлюзом. Она объединяет группу ресурсов доступа с общими сценариями и обеспечивает их единое управление и мониторинг. |
Envoy | Envoy — это L7-прокси и коммуникационная шина, разработанная для крупных современных SOA (Service-Oriented Architecture) архитектур. Это один из ключевых компонентов Istio, который запускается вместе с сервисами в режиме sidecar для перехвата и перенаправления трафика сервисов. Он предоставляет возможности маршрутизации трафика и управления трафиком. Learn more |
EnvoyFilter | EnvoyFilter предоставляет механизм для настройки конфигурации Envoy, генерируемой Istio Pilot. EnvoyFilter может изменять значения конкретных полей, добавлять специальные фильтры или полностью новые слушатели, кластеры и так далее. Эту функцию следует использовать с осторожностью, так как неправильная конфигурация может нарушить работу всего service mesh. Ресурсы EnvoyFilter на платформе являются ресурсами проекта и могут использоваться совместно сервисами в нескольких service mesh и пространствах имён внутри проекта. |