Глоссарий#
Ниже приведены фирменные термины, терминология и аббревиатуры, которые встречаются в этом документе.
| 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 | Образ контейнера — это стандартный формат упаковки контейнерных приложений. При развертывании контейнеризованных приложений можно указывать образы, которые могут поступать из Docker Hub, репозитория образов платформы DevOps компании или из приватного репозитория пользователя. Идентификатор образа однозначно определяется URI репозитория образов и тегом образа (по умолчанию latest). |
| Container | Процесс, который запускается на хосте и создаётся на основе образа. |
| Pod | Pod — это наименьшая базовая единица для развертывания приложений или сервисов в Kubernetes. Pod инкапсулирует несколько контейнеров приложения (или только один контейнер), ресурсы хранения, независимый сетевой IP и политики, контролирующие способ запуска контейнеров. |
| Workload | Компоненты, составляющие приложение на платформе, и в совокупности называемые программами, которые могут комбинироваться для предоставления сервисов или работать автономно, создаются на основе образов. |
| Replication Controller | RC обеспечивает, что в Kubernetes кластере постоянно запущено заданное количество реплик Pod. Наблюдая за запущенными Pod, RC гарантирует, что в кластере работает заданное количество реплик 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 | В Kubernetes API ресурс — это конечная точка, используемая для хранения коллекции объектов API определённого типа. Объект CRD определяет новый уникальный тип объекта в кластере и позволяет Kubernetes API серверу управлять полным жизненным циклом объекта. 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 и namespace внутри проекта. |