Глоссарий#
Ниже приведены фирменные термины, терминология и аббревиатуры, которые встречаются в этом документе.
| Glossary | Description |
|---|---|
| Cluster | Кластер Kubernetes управляет инфраструктурными ресурсами, необходимыми для запуска контейнеров в платформе контейнеров Kubernetes, и связан с различными ресурсами, такими как несколько узлов, балансировщики нагрузки и приватные сети. Кластер с одной точкой имеет только один управляющий узел, тогда как высокодоступный кластер имеет не менее 3 управляющих узлов. |
| Node | Узел в кластере делится на два типа: управляющие узлы (Master) и вычислительные узлы (Node). Управляющие узлы отвечают за запуск kube-apiserver, kube-scheduler, kube-controller-manager, etcd, сетей контейнеров и некоторых компонентов управления платформой. Вычислительные узлы — это узлы в Kubernetes кластере, которые несут нагрузку, и могут быть виртуальными или физическими машинами. Вычислительные узлы отвечают за фактическое планирование Pod и взаимодействие с управляющими узлами. |
| Project | Проекты (тенанты) платформы могут гибко разделяться на независимые и изолированные пространства ресурсов, и каждый проект имеет независимую проектную среду, которая может представлять разные дочерние компании, отделы или проектные команды внутри предприятия. Через управление проектами легко достигать изоляции ресурсов между проектными командами и управления квотами внутри тенантов. |
| Namespace | Kubernetes Namespace — это более мелкое пространство ресурсов, изолированное от других namespace в проекте на платформе, а также рабочее пространство для пользователей для реализации производственных задач. Под одним проектом можно создавать несколько namespace, и общий лимит ресурсов, который может быть занят, не может превышать квоту проекта. За счёт дробления квот ресурсов на более мелкие namespace ограничивается также размер контейнеров (CPU, память) в namespace, что эффективно повышает использование ресурсов. |
| Image | Образ контейнера — это стандартный формат упаковки контейнерных приложений. При развертывании контейнеризованных приложений можно указывать образы, которые могут поступать из публичных репозиториев образов, репозитория образов платформы DevOps компании или из приватного репозитория пользователя. Идентификатор образа может быть однозначно определён URI репозитория образов и тегом образа (по умолчанию latest). |
| Container | Процесс, который запускается на хосте и создаётся на основе образа. |
| Pod | Pod — это наименьшая базовая единица для развертывания приложений или сервисов в Kubernetes. Pod инкапсулирует несколько контейнеров приложений (или только один контейнер), ресурсы хранения, независимый сетевой IP и параметры политики, управляющие способом запуска контейнеров. |
| Workload | Компоненты, составляющие приложение на платформе, и в совокупности называемые программами, которые могут комбинироваться для предоставления сервисов или работать автономно, создаются на основе образов. |
| Replication Controller | RC обеспечивает, что в Kubernetes кластере всегда запущено заданное количество реплик Pod. Отслеживая запущенные Pod, RC гарантирует, что в кластере работает заданное количество реплик Pod. Заданное количество может быть больше одного или равно одному. Если количество меньше заданного, RC запускает новые реплики Pod. Если больше — RC завершает избыточные реплики Pod. |
| ReplicaSet | ReplicaSet (RS) — это усовершенствованная версия RC, единственное отличие — поддержка селекторов. RS поддерживает больше типов шаблонов сопоставления. Объекты ReplicaSet обычно не используются самостоятельно, а служат параметрами желаемого состояния для Deployments. |
| Deployment | Deployment обеспечивает декларативные обновления для ReplicaSets (контроллеров репликации) и Pod (групп контейнеров). Описывая желаемое состояние для реплик (число Pod) и контейнеров, контроллер Deployment изменяет фактическое состояние Pod и ReplicaSets на желаемое. |
| Configmap | Kubernetes ConfigMap использует пары ключ-значение для хранения конфигурационных данных, которые могут содержать отдельные атрибуты или конфигурационные файлы. Управление конфигурациями для контейнеризованных приложений достигается с помощью ConfigMap, отделяя конфигурации от содержимого образа и сохраняя переносимость контейнеризованных приложений. |
| Secret | Kubernetes Secret используется для хранения конфиденциальной информации или конфигураций в Kubernetes кластере, таких как пароли пользователей, OAuth токены, приватные SSH ключи, данные аутентификации для доступа к репозиториям образов и т. п. Рекомендуется использовать Secret для приоритетного хранения конфиденциальных словарей. |
| Service | Kubernetes Service определяет логическую коллекцию Pod и поддерживает настройку политик доступа для вычислительных компонентов внутри кластера. Он эквивалентен внутреннему сервису в кластере и предоставляет единый входной пункт доступа для других вычислительных компонентов или посетителей, находящихся внутри кластера, обеспечивая функцию внутреннего обнаружения вычислительных компонентов. |
| CustomResourceDefinition | В Kubernetes API ресурс — это конечная точка, используемая для хранения коллекции объектов API определённого типа. Объект CRD определяет новый уникальный тип объекта в кластере и позволяет серверу API Kubernetes управлять полным жизненным циклом объекта. Kubernetes поддерживает пользователей в настройке расширенных ресурсов Kubernetes через API CustomResourceDefinition и обеспечивает быструю регистрацию и использование новых ресурсов. |
| Domain | Администраторы могут использовать функцию управления доменными именами для централизованного управления ресурсами доменных имён корпоративной сети, используемых для этой платформы, а также распределять и управлять доменными именами между проектами путём привязки доменов к проектам. |
| Role | Роль — это набор прав на операции. Права на операции с ресурсами на платформе включают создание, просмотр, обновление и удаление. Платформа классифицирует и комбинирует права на операции с разными ресурсами через роли. Роль может содержать одно или несколько прав на операции для одного или нескольких типов ресурсов. Назначая конкретные роли пользователям, можно быстро открывать или ограничивать права на операции с указанными ресурсами. |
| Event | Платформа интегрируется с событиями Kubernetes, записывая важные изменения статуса ресурсов Kubernetes и различные события изменения состояния во время выполнения. Через события можно анализировать конкретные причины аномалий в конкретных ресурсах, таких как кластеры, приложения, задачи и др. |
| Audit | Платформа интегрируется с аудитом Kubernetes, предоставляя хронологически упорядоченные записи операций, связанных с безопасностью, включая время, источник, результат операции, пользователя, инициировавшего операцию, ресурсы, с которыми производились операции, и подробную информацию о запросах/ответах и т. п. Через аудит аудиторы платформы могут чётко понимать изменения в Kubernetes кластере. |
| Log | Платформа интегрируется с логами Kubernetes, что позволяет быстро собирать логи контейнеров в Kubernetes кластере, включая стандартный вывод контейнеров и текстовые файлы внутри контейнеров. Одновременно поддерживается сбор логов Kubelet, runtime контейнеров и компонентов 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 и namespace внутри проекта. |