Translate Kubernetes Components page into Russian (#19657)
* Translate Kubernetes Components page into Russian * Apply suggestions from code review Co-Authored-By: Nikita Potapenko <dev.potapy4@hotmail.com> * Update service.md * Update kube-scheduler.md * Update control-plane.md * Update kube-scheduler.md Co-authored-by: Nikita Potapenko <dev.potapy4@hotmail.com>
This commit is contained in:
Alexey Pyltsyn
GitHub
parent
763c5a4216
commit
a97e5ef287
|
|
@ -0,0 +1,118 @@
|
|||
---
|
||||
reviewers:
|
||||
- lavalamp
|
||||
title: Компоненты Kubernetes
|
||||
content_template: templates/concept
|
||||
weight: 20
|
||||
card:
|
||||
name: concepts
|
||||
weight: 20
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
При развёртывании Kubernetes вы имеете дело с кластером.
|
||||
{{< glossary_definition term_id="cluster" length="all" prepend="Кластер Kubernetes cluster состоит из">}}
|
||||
|
||||
На этой странице в общих чертах описывается различные компоненты, необходимые для работы кластера Kubernetes.
|
||||
|
||||
Ниже показана диаграмма кластера Kubernetes со всеми связанными компонентами.
|
||||
|
||||
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
## Панель управления компонентами
|
||||
|
||||
Компоненты панели управления отвечают за основные операции кластера (например, планирование), а также обрабатывают события кластера (например, запускают новый {{< glossary_tooltip text="под" term_id="pod">}}, когда поле `replicas` развертывания не соответствует требуемому количеству реплик).
|
||||
|
||||
Компоненты панели управления могут быть запущены на любой машине в кластере. Однако для простоты сценарии настройки обычно запускают все компоненты панели управления на одном компьютере и в то же время не позволяют запускать пользовательские контейнеры на этом компьютере. Смотрите страницу [Создание высоконадёжных кластеров](/docs/admin/high-availability/) для примера настройки нескольких ведущих виртуальных машин.
|
||||
|
||||
### kube-apiserver
|
||||
|
||||
{{< glossary_definition term_id="kube-apiserver" length="all" >}}
|
||||
|
||||
### etcd
|
||||
|
||||
{{< glossary_definition term_id="etcd" length="all" >}}
|
||||
|
||||
### kube-scheduler
|
||||
|
||||
{{< glossary_definition term_id="kube-scheduler" length="all" >}}
|
||||
|
||||
### kube-controller-manager
|
||||
|
||||
{{< glossary_definition term_id="kube-controller-manager" length="all" >}}
|
||||
|
||||
Эти контроллеры включают:
|
||||
|
||||
* Контроллер узла (Node Controller): уведомляет и реагирует на сбои узла.
|
||||
* Контроллер репликации (Replication Controller): поддерживает правильное количество подов для каждого объекта контроллера репликации в системе.
|
||||
* Контроллер конечных точек (Endpoints Controller): заполняет объект конечных точек (Endpoints), то есть связывает сервисы (Services) и поды (Pods).
|
||||
* Контроллеры учетных записей и токенов (Account & Token Controllers): создают стандартные учетные записи и токены доступа API для новых пространств имен.
|
||||
|
||||
### cloud-controller-manager
|
||||
|
||||
[cloud-controller-manager](/docs/tasks/administer-cluster/running-cloud-controller/) запускает контроллеры, которые взаимодействуют с основными облачными провайдерами. Двоичный файл cloud-controller-manager — это альфа-функциональность, появившиеся в Kubernetes 1.6.
|
||||
|
||||
cloud-controller-manager запускает только циклы контроллера, относящиеся к облачному провайдеру. Вам нужно отключить эти циклы контроллера в kube-controller-manager. Вы можете отключить циклы контроллера, установив флаг `--cloud-provider` со значением `external` при запуске kube-controller-manager.
|
||||
|
||||
С помощью cloud-controller-manager код как облачных провайдеров, так и самого Kubernetes может разрабатываться независимо друг от друга. В предыдущих версиях код ядра Kubernetes зависел от кода, предназначенного для функциональности облачных провайдеров. В будущих выпусках код, специфичный для облачных провайдеров, должен поддерживаться самим облачным провайдером и компоноваться с cloud-controller-manager во время запуска Kubernetes.
|
||||
|
||||
Следующие контроллеры зависят от облачных провайдеров:
|
||||
|
||||
* Контроллер узла (Node Controller): проверяет облачный провайдер, чтобы определить, был ли удален узел в облаке после того, как он перестал работать
|
||||
* Контроллер маршрутов (Route Controller): настраивает маршруты в основной инфраструктуре облака
|
||||
* Контроллер сервисов (Service Controller): создаёт, обновляет и удаляет балансировщики нагрузки облачного провайдера.
|
||||
* Контроллер тома (Volume Controller): создаёт, присоединяет и монтирует тома, а также взаимодействует с облачным провайдером для оркестрации томов.
|
||||
|
||||
## Компоненты узла
|
||||
|
||||
Компоненты узла работают на каждом узле, поддерживая работу подов и среды выполнения Kubernetes.
|
||||
|
||||
### kubelet
|
||||
|
||||
{{< glossary_definition term_id="kubelet" length="all" >}}
|
||||
|
||||
### kube-proxy
|
||||
|
||||
{{< glossary_definition term_id="kube-proxy" length="all" >}}
|
||||
|
||||
### Среда выполнения контейнера
|
||||
|
||||
{{< glossary_definition term_id="container-runtime" length="all" >}}
|
||||
|
||||
## Дополнения
|
||||
|
||||
Дополнения используют ресурсы Kubernetes ({{< glossary_tooltip term_id="daemonset" >}}, {{< glossary_tooltip term_id="deployment" >}} и т.д.) для расширения функциональности кластера. Поскольку дополнения охватывают весь кластер, ресурсы относятся к пространству имен `kube-system`.
|
||||
|
||||
Некоторые из дополнений описаны ниже; более подробный список доступных расширений вы можете найти на странице [Дополнения](/docs/concepts/cluster-administration/addons/).
|
||||
|
||||
### DNS
|
||||
|
||||
Хотя прочие дополнения не являются строго обязательными, однако при этом у всех Kubernetes-кластеров должен быть [кластерный DNS](/docs/concepts/services-networking/dns-pod-service/), так как многие примеры предполагают его наличие.
|
||||
|
||||
Кластерный DNS — это DNS-сервер наряду с другими DNS-серверами в вашем окружении, который обновляет DNS-записи для сервисов Kubernetes.
|
||||
|
||||
Контейнеры, запущенные посредством Kubernetes, автоматически включают этот DNS-сервер в свои DNS.
|
||||
|
||||
### Веб-интерфейс (Dashboard)
|
||||
|
||||
[Dashboard](/docs/tasks/access-application-cluster/web-ui-dashboard/) — это универсальный веб-интерфейс для кластеров Kubernetes. С помощью этой панели, пользователи могут управлять и устранять неполадки кластера и приложений, работающих в кластере.
|
||||
|
||||
### Мониторинг ресурсов контейнера
|
||||
|
||||
[Мониторинг ресурсов контейнера](/docs/tasks/debug-application-cluster/resource-usage-monitoring/) записывает общие метрики о контейнерах в виде временных рядов в центральной базе данных и предлагает пользовательский интерфейс для просмотра этих данных.
|
||||
|
||||
### Логирование кластера
|
||||
|
||||
Механизм [логирования кластера](/docs/concepts/cluster-administration/logging/) отвечает за сохранение логов контейнера в централизованном хранилище логов с возможностью их поиска/просмотра.
|
||||
|
||||
{{% /capture %}}
|
||||
{{% capture whatsnext %}}
|
||||
* Подробнее про [узлы](/docs/concepts/architecture/nodes/)
|
||||
* Подробнее про [контроллеры](/docs/concepts/architecture/controller/)
|
||||
* Подробнее про [kube-scheduler](/docs/concepts/scheduling/kube-scheduler/)
|
||||
* Официальная [документация](https://etcd.io/docs/) etcd
|
||||
{{% /capture %}}
|
||||
|
|
@ -2,16 +2,16 @@
|
|||
title: Кластер
|
||||
id: cluster
|
||||
date: 2019-06-15
|
||||
full_link:
|
||||
full_link:
|
||||
short_description: >
|
||||
Набор машин, называемых нодами, которые запускают контейнерные приложения, управляемые Kubernetes. Кластер имеет как минимум одну рабочую ноду и хотя бы одну главную ноду.
|
||||
Набор машин, так называемые узлы, которые запускают контейнеризированные приложения. Кластер имеет как минимум один рабочий узел.
|
||||
|
||||
aka:
|
||||
aka:
|
||||
tags:
|
||||
- fundamental
|
||||
- operation
|
||||
---
|
||||
Набор машин, называемых нодами, которые запускают контейнерные приложения, управляемые Kubernetes. Кластер имеет как минимум одну рабочую ноду и хотя бы одну главную ноду.
|
||||
Набор машин, так называемые узлы, которые запускают контейнеризированные приложения. Кластер имеет как минимум один рабочий узел.
|
||||
|
||||
<!--more-->
|
||||
Родительские ноды содержат дочерние ноды, являющиеся компонентами приложения. Главные ноды управляют родительскими нодами и модулями в кластере. Несколько главных нод используются для обеспечения отказоустойчивости кластера и высокой доступности.
|
||||
В рабочих узлах размещены поды, являющиеся компонентами приложения. Панель управления управляет рабочими узлами и подами в кластере. В промышленных средах панель управления обычно запускается на нескольких компьютерах, а кластер, как правило, развёртывается на нескольких узлах, гарантируя отказоустойчивость и высокую надёжность.
|
||||
|
|
|
|||
|
|
@ -0,0 +1,21 @@
|
|||
---
|
||||
title: Среда выполнения контейнера
|
||||
id: container-runtime
|
||||
date: 2019-06-05
|
||||
full_link: /docs/reference/generated/container-runtime
|
||||
short_description: >
|
||||
Среда выполнения контейнера — это программа, предназначенная для выполнения контейнеров.
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- fundamental
|
||||
- workload
|
||||
---
|
||||
Среда выполнения контейнера — это программа, предназначенная для выполнения контейнеров.
|
||||
|
||||
<!--more-->
|
||||
|
||||
Kubernetes поддерживает несколько сред для запуска контейнеров: {{< glossary_tooltip term_id="docker">}},
|
||||
{{< glossary_tooltip term_id="containerd" >}}, {{< glossary_tooltip term_id="cri-o" >}},
|
||||
и любая реализация [Kubernetes CRI (Container Runtime
|
||||
Interface)](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/container-runtime-interface.md).
|
||||
|
|
@ -0,0 +1,18 @@
|
|||
---
|
||||
title: Контейнер
|
||||
id: container
|
||||
date: 2018-04-12
|
||||
full_link: /docs/concepts/overview/what-is-kubernetes/#why-containers
|
||||
short_description: >
|
||||
Переносимый и не требовательный к ресурсам исполняемый экземпляр образа, содержащий приложение вместе со всеми его зависимостями.
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- fundamental
|
||||
- workload
|
||||
---
|
||||
Переносимый и не требовательный к ресурсам исполняемый экземпляр образа, содержащий приложение вместе со всеми его зависимостями.
|
||||
|
||||
<!--more-->
|
||||
|
||||
Контейнеры изолирует приложения от инфраструктуры хост-машины, чтобы обеспечить простое масштабирование и упростить развёртывание в различных средах облачных платформ или операционных систем.
|
||||
|
|
@ -0,0 +1,17 @@
|
|||
---
|
||||
title: containerd
|
||||
id: containerd
|
||||
date: 2019-05-14
|
||||
full_link: https://containerd.io/docs/
|
||||
short_description: >
|
||||
Среда выполнения контейнера с упором на простоту, надежность и переносимость
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- tool
|
||||
---
|
||||
Среда выполнения контейнера с упором на простоту, надежность и переносимость
|
||||
|
||||
<!--more-->
|
||||
|
||||
containerd — среда выполнения {{< glossary_tooltip text="контейнера" term_id="container" >}}, который представляет собой демон для Linux или Windows. containerd заботится о получении и хранении образов контейнеров, запуске контейнеров, осуществлять доступ по сети и т.д.
|
||||
|
|
@ -0,0 +1,13 @@
|
|||
---
|
||||
title: Плоскость управления (Control Plane)
|
||||
id: control-plane
|
||||
date: 2019-05-12
|
||||
full_link:
|
||||
short_description: >
|
||||
Уровень оркестрации контейнеров с API и интерфейсами для определения, развёртывания и управления жизненным циклом контейнеров.
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- fundamental
|
||||
---
|
||||
Уровень оркестрации контейнеров с API и интерфейсами для определения, развёртывания и управления жизненным циклом контейнеров.
|
||||
|
|
@ -0,0 +1,19 @@
|
|||
---
|
||||
title: CRI-O
|
||||
id: cri-o
|
||||
date: 2019-05-14
|
||||
full_link: https://cri-o.io/#what-is-cri-o
|
||||
short_description: >
|
||||
Оптимизированная среда выполнения контейнеров, разработанная специально для Kubernetes
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- tool
|
||||
---
|
||||
Инструмент, позволяющий использовать среды выполнения контейнеров формата OCI с помощью технологии Kubernetes CRI.
|
||||
|
||||
<!--more-->
|
||||
|
||||
CRI-O — это реализация {{< glossary_tooltip term_id="cri" >}}, позволяющая использовать среды выполнения {{< glossary_tooltip text="контейнеров" term_id="container" >}}, совместимые со [спецификацией исполняемой среды контейнеров](http://www.github.com/opencontainers/runtime-spec) Open Container Initiative (OCI).
|
||||
|
||||
Развертывание CRI-O позволяет Kubernetes использовать любую OCI-совместимую среду выполнения в качестве контейнерной среды выполнения для выполнения {{< glossary_tooltip text="подов" term_id="pod" >}} и загружать образы OCI-контейнера из удаленных реестров.
|
||||
|
|
@ -0,0 +1,17 @@
|
|||
---
|
||||
title: Container runtime interface (CRI)
|
||||
id: cri
|
||||
date: 2019-03-07
|
||||
full_link: /docs/concepts/overview/components/#container-runtime
|
||||
short_description: >
|
||||
API сред выполнения контейнеров для интеграции с kubelet
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- fundamental
|
||||
---
|
||||
Интерфейс среды выполнения контейнера (Container Runtime Interface, CRI) — это API сред выполнения контейнера, которая интегрируется с kubelet на узле.
|
||||
|
||||
<!--more-->
|
||||
|
||||
Для получения дополнительной информации смотрите API и спефикации [CRI](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/container-runtime-interface.md).
|
||||
|
|
@ -0,0 +1,19 @@
|
|||
---
|
||||
title: DaemonSet
|
||||
id: daemonset
|
||||
date: 2018-04-12
|
||||
full_link: /docs/concepts/workloads/controllers/daemonset
|
||||
short_description: >
|
||||
Гарантирует, что копия Pod выполняется в наборе узлов кластера.
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- fundamental
|
||||
- core-object
|
||||
- workload
|
||||
---
|
||||
Гарантирует, что копия {{< glossary_tooltip text="Pod" term_id="pod" >}} выполняется в наборе узлов {{< glossary_tooltip text="кластера" term_id="cluster" >}}.
|
||||
|
||||
<!--more-->
|
||||
|
||||
Используется для развертывания системных демонов, таких как сборщики логов и агенты мониторинга, которые, как правило, должны работать на каждом {{< glossary_tooltip text="узла" term_id="node" >}}.
|
||||
|
|
@ -0,0 +1,20 @@
|
|||
---
|
||||
title: Deployment
|
||||
id: deployment
|
||||
date: 2018-04-12
|
||||
full_link: /docs/concepts/workloads/controllers/deployment/
|
||||
short_description: >
|
||||
API-объект, управляющий реплицированным приложением.
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- fundamental
|
||||
- core-object
|
||||
- workload
|
||||
---
|
||||
API-объект, управляющий реплицированным приложением.
|
||||
|
||||
<!--more-->
|
||||
|
||||
Каждая реплика представляет {{< glossary_tooltip term_id="pod" >}}, а все Pod-объекты распределяются по узлам кластера.
|
||||
|
||||
|
|
@ -0,0 +1,17 @@
|
|||
---
|
||||
title: Docker
|
||||
id: docker
|
||||
date: 2018-04-12
|
||||
full_link: https://docs.docker.com/engine/
|
||||
short_description: >
|
||||
Docker — это программное обеспечение для виртуализации на уровне операционной системы, которая известна как контейнеризация.
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- fundamental
|
||||
---
|
||||
Docker (в частности, Docker Engine) — это программное обеспечение для виртуализации на уровне операционной системы, которая также известна как {{< glossary_tooltip text="контейнеризация" term_id="container" >}}.
|
||||
|
||||
<!--more-->
|
||||
|
||||
Docker использует возможности изоляции ресурсов ядра Linux, такие как cgroups и пространства имен ядра, а также каскадно-объединённую файловую систему, например, OverlayFS и другие, чтобы независимые друг от друга контейнеры могли работать в одном экземпляре Linux без накладных расходов на запуск и поддержку работы виртуальных машин (VM).
|
||||
|
|
@ -0,0 +1,20 @@
|
|||
---
|
||||
title: etcd
|
||||
id: etcd
|
||||
date: 2018-04-12
|
||||
full_link: /docs/tasks/administer-cluster/configure-upgrade-etcd/
|
||||
short_description: >
|
||||
Распределённое и высоконадёжное хранилище данных в формате "ключ-значение", которое используется как основное хранилище всех данных кластера в Kubernetes.
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- architecture
|
||||
- storage
|
||||
---
|
||||
Распределённое и высоконадёжное хранилище данных в формате "ключ-значение", которое используется как основное хранилище всех данных кластера в Kubernetes.
|
||||
|
||||
<!--more-->
|
||||
|
||||
Если ваш кластер Kubernetes использует etcd в качестве основного хранилища, убедитесь, что у вас [настроено резервное копирование](/docs/tasks/administer-cluster/configure-upgrade-etcd/#backing-up-an-etcd-cluster) данных.
|
||||
|
||||
Вы можете найти подробную информацию о etcd в [официальной документации](https://etcd.io/docs/).
|
||||
|
|
@ -0,0 +1,23 @@
|
|||
---
|
||||
title: API-сервер
|
||||
id: kube-apiserver
|
||||
date: 2018-04-12
|
||||
full_link: /docs/reference/generated/kube-apiserver/
|
||||
short_description: >
|
||||
Компонент панели управления, обслуживающий API Kubernetes.
|
||||
|
||||
aka:
|
||||
- kube-apiserver
|
||||
tags:
|
||||
- architecture
|
||||
- fundamental
|
||||
---
|
||||
Сервер API — компонент Kubernetes
|
||||
{{< glossary_tooltip text="панели управления" term_id="control-plane" >}}, который представляет API Kubernetes.
|
||||
API-сервер — это клиентская часть панели управления Kubernetes
|
||||
|
||||
<!--more-->
|
||||
|
||||
Основной реализацией API-сервера Kubernetes является [kube-apiserver](/docs/reference/generated/kube-apiserver/).
|
||||
kube-apiserver предназначен для горизонтального масштабирования, то есть развёртывание на несколько экземпляров.
|
||||
Вы можете запустить несколько экземпляров kube-apiserver и сбалансировать трафик между этими экземплярами.
|
||||
|
|
@ -0,0 +1,18 @@
|
|||
---
|
||||
title: kube-controller-manager
|
||||
id: kube-controller-manager
|
||||
date: 2018-04-12
|
||||
full_link: /docs/reference/command-line-tools-reference/kube-controller-manager/
|
||||
short_description: >
|
||||
Компонент Control Plane запускает процессы контроллера.
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- architecture
|
||||
- fundamental
|
||||
---
|
||||
Компонент Control Plane запускает процессы {{< glossary_tooltip text="контроллера" term_id="controller" >}}.
|
||||
|
||||
<!--more-->
|
||||
|
||||
Вполне логично, что каждый {{< glossary_tooltip text="контроллер" term_id="controller" >}} в свою очередь представляет собой отдельный процесс, и для упрощения все такие процессы скомпилированы в один двоичный файл и выполняются в одном процессе.
|
||||
|
|
@ -0,0 +1,20 @@
|
|||
---
|
||||
title: kube-proxy
|
||||
id: kube-proxy
|
||||
date: 2018-04-12
|
||||
full_link: /docs/reference/command-line-tools-reference/kube-proxy/
|
||||
short_description: >
|
||||
`kube-proxy` — сетевой прокси, работающий на каждом узле в кластере.
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- fundamental
|
||||
- networking
|
||||
---
|
||||
[kube-proxy](/docs/reference/command-line-tools-reference/kube-proxy/) — сетевой прокси, работающий на каждом узле в кластере, и реализующий часть концепции {{< glossary_tooltip text="сервис" term_id="service">}}.
|
||||
|
||||
<!--more-->
|
||||
|
||||
kube-proxy конфигурирует правила сети на узлах. При помощи них разрешаются сетевые подключения к вашими подам изнутри и снаружи кластера.
|
||||
|
||||
kube-proxy использует уровень фильтрации пакетов в операционной системы, если он доступен. В противном случае, kube-proxy сам обрабатывает передачу сетевого трафика.
|
||||
|
|
@ -0,0 +1,19 @@
|
|||
---
|
||||
title: kube-scheduler
|
||||
id: kube-scheduler
|
||||
date: 2018-04-12
|
||||
full_link: /docs/reference/generated/kube-scheduler/
|
||||
short_description: >
|
||||
Компонент плоскости управления, который отслеживает созданные поды без привязанного узла и выбирает узел, на котором они должны работать.
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- architecture
|
||||
---
|
||||
Компонент плоскости управления, который отслеживает созданные поды без привязанного узла и выбирает узел, на котором они должны работать.
|
||||
|
||||
<!--more-->
|
||||
|
||||
<!-- Factors taken into account for scheduling decisions include individual and collective resource requirements, hardware/software/policy constraints, affinity and anti-affinity specifications, data locality, inter-workload interference? and deadlines. -->
|
||||
|
||||
При планировании развёртывания подов на узлах учитываются множество факторов, включая требования к ресурсам, ограничения, связанные с аппаратными/программными политиками, принадлежности (affinity) и непринадлежности (anti-affinity) узлов/подов, местонахождения данных, предельных сроков.
|
||||
|
|
@ -0,0 +1,18 @@
|
|||
---
|
||||
title: Kubelet
|
||||
id: kubelet
|
||||
date: 2018-04-12
|
||||
full_link: /docs/reference/generated/kubelet
|
||||
short_description: >
|
||||
Агент, работающий на каждом узле в кластере. Он следит за тем, чтобы контейнеры были запущены в поде.
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- fundamental
|
||||
- core-object
|
||||
---
|
||||
Агент, работающий на каждом узле в кластере. Он следит за тем, чтобы контейнеры были запущены в поде.
|
||||
|
||||
<!--more-->
|
||||
|
||||
Утилита kubelet принимает набор PodSpecs, и гарантирует работоспособность и исправность определённых в них контейнеров. Агент kubelet не отвечает за контейнеры, не созданные Kubernetes.
|
||||
|
|
@ -0,0 +1,17 @@
|
|||
---
|
||||
title: Метка
|
||||
id: label
|
||||
date: 2018-04-12
|
||||
full_link: /docs/concepts/overview/working-with-objects/labels
|
||||
short_description: >
|
||||
Группирует объекты на основе произвольных критериев, по которым пользователи могут их идентифицировать.
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- fundamental
|
||||
---
|
||||
Группирует объекты на основе произвольных критериев, по которым пользователи могут их идентифицировать.
|
||||
|
||||
<!--more-->
|
||||
|
||||
Метки — это пары "ключ-значение", которые прикрепляются к таким объектам, как {{< glossary_tooltip text="Pod" term_id="pod" >}}. Они используются для организации и получения подмножеств объектов.
|
||||
|
|
@ -0,0 +1,17 @@
|
|||
---
|
||||
title: Node
|
||||
id: node
|
||||
date: 2018-04-12
|
||||
full_link: /docs/concepts/architecture/nodes/
|
||||
short_description: >
|
||||
Узел — рабочая машина в Kubernetes.
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- fundamental
|
||||
---
|
||||
Узел — рабочая машина в Kubernetes.
|
||||
|
||||
<!--more-->
|
||||
|
||||
Рабочий узел может быть как виртуальной, так и физической машиной, в зависимости от кластера. У него есть локальные демоны или сервисы, необходимые для запуска {{< glossary_tooltip text="подов" term_id="pod" >}}, а сам он управляется панелью управления. Демоны на узле включают в себя {{< glossary_tooltip text="kubelet" term_id="kubelet" >}}, {{< glossary_tooltip text="kube-proxy" term_id="kube-proxy" >}} и среду выполнения контейнера, основанную на {{< glossary_tooltip text="CRI" term_id="cri" >}}, например {{< glossary_tooltip term_id="docker" >}}.
|
||||
|
|
@ -0,0 +1,18 @@
|
|||
---
|
||||
title: Pod
|
||||
id: pod
|
||||
date: 2018-04-12
|
||||
full_link: /docs/concepts/workloads/pods/pod-overview/
|
||||
short_description: >
|
||||
Самый маленький и простой объект в Kubernetes. Под — это набор запущенных контейнеров в кластере.
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- core-object
|
||||
- fundamental
|
||||
---
|
||||
Самый маленький и простой объект в Kubernetes. Объект Pod — набор запущенных {{< glossary_tooltip text="контейнеров" term_id="container" >}} в кластере.
|
||||
|
||||
<!--more-->
|
||||
|
||||
Как правило, один под предназначен для выполнения одного основного контейнера. Он также может запускать дополнительные "прицепные" (sidecar) контейнеры, добавляющие новые функциональные возможности, например, логирование. Контейнеры обычно управляются {{< glossary_tooltip term_id="deployment" >}}.
|
||||
|
|
@ -0,0 +1,18 @@
|
|||
---
|
||||
title: Селектор
|
||||
id: selector
|
||||
date: 2018-04-12
|
||||
full_link: /docs/concepts/overview/working-with-objects/labels/
|
||||
short_description: >
|
||||
Позволяет пользователям фильтровать список ресурсов по меткам.
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- fundamental
|
||||
---
|
||||
Позволяет пользователям фильтровать список ресурсов по меткам.
|
||||
|
||||
<!--more-->
|
||||
|
||||
Селекторы применяются при создании запросов для фильтрации списков ресурсов по {{< glossary_tooltip text="меткам" term_id="label" >}}.
|
||||
|
||||
|
|
@ -0,0 +1,18 @@
|
|||
---
|
||||
title: Сервис (Service)
|
||||
id: service
|
||||
date: 2018-04-12
|
||||
full_link: /docs/concepts/services-networking/service/
|
||||
short_description: >
|
||||
Способ представления приложения, запущенного в наборе подов, в виде сетевого сервиса.
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- fundamental
|
||||
- core-object
|
||||
---
|
||||
Абстрактный способ представления приложения, запущенного в наборе {{< glossary_tooltip text="подов" term_id="pod" >}}, в виде сетевого сервиса.
|
||||
|
||||
<!--more-->
|
||||
|
||||
Набор подов, из которых состоит сервис, определяется (как правило) {{< glossary_tooltip text="селектором" term_id="selector" >}}. При добавлении или удалении подов, набор подов, соответствующий селектору, изменится. Сервис обеспечивает, что сетевой трафик может быть направлен на текущий набор подов для планирования рабочей нагрузки.
|
||||
Loading…
Reference in New Issue