Review all glossary terms in Russian
Signed-off-by: Dmitry Shurupov <dmitry.shurupov@palark.com>pull/48791/head
parent
93d3c19e04
commit
b76e02e8ac
|
@ -5,20 +5,20 @@ date: 2021-04-27
|
|||
full_link: /docs/concepts/scheduling-eviction/api-eviction/
|
||||
short_description: >
|
||||
Вытеснение, инициированное через API — процесс, при котором с помощью Eviction API создается объект Eviction,
|
||||
который запускает корректное завершение работы Pod'а.
|
||||
который запускает корректное завершение работы пода.
|
||||
aka:
|
||||
tags:
|
||||
- operation
|
||||
---
|
||||
Вытеснение, инициированное через API — процесс, при котором с помощью [Eviction API](/docs/reference/generated/kubernetes-api/{{<param "version">}}/#create-eviction-pod-v1-core)
|
||||
создается объект `Eviction`, который запускает корректное завершение работы Pod'а.
|
||||
Вытеснение, инициированное через API, — процесс, при котором с помощью [Eviction API](/docs/reference/generated/kubernetes-api/{{<param "version">}}/#create-eviction-pod-v1-core)
|
||||
создается объект `Eviction`, который запускает корректное завершение работы пода.
|
||||
|
||||
<!--more-->
|
||||
|
||||
Вытеснение можно запросить через Eviction API, обратившись к нему напрямую, либо программно (через клиент API-сервера — например, с помощью команды `kubectl drain`). При этом будет создан объект `Eviction`, на основании которого API-сервер завершит работу Pod'а.
|
||||
Вытеснение можно запросить через Eviction API, обратившись к нему напрямую, либо программно (через клиент API-сервера — например, с помощью команды `kubectl drain`). При этом будет создан объект `Eviction`, на основании которого API-сервер завершит работу пода.
|
||||
|
||||
Вытеснения, инициированные через API, учитывают заданные параметры [`PodDisruptionBudget`](/docs/tasks/run-application/configure-pdb/) (минимальное количество реплик, которые должны быть доступны для данного развертывания в любой момент времени) и [`terminationGracePeriodSeconds`](/docs/concepts/workloads/pods/pod-lifecycle#pod-termination) (период ожидания корректного завершения работы Pod'а).
|
||||
Вытеснения, инициированные через API, учитывают заданные параметры [`PodDisruptionBudget`](/docs/tasks/run-application/configure-pdb/) и [`terminationGracePeriodSeconds`](/docs/concepts/workloads/pods/pod-lifecycle#pod-termination).
|
||||
|
||||
Обратите внимание: вытеснение, инициированное через API — не то же самое, что вытеснение из-за [дефицита ресурсов на узле](/docs/concepts/scheduling-eviction/node-pressure-eviction/).
|
||||
Вытеснение, инициированное через API, — не то же самое, что вытеснение из-за [дефицита ресурсов на узле](/docs/concepts/scheduling-eviction/node-pressure-eviction/).
|
||||
|
||||
* Дополнительная информация доступна в разделе ["Вытеснение, инициированное API"](/docs/concepts/scheduling-eviction/api-eviction/).
|
||||
* Дополнительная информация доступна в разделе ["Вытеснение, инициированное API"](/ru/docs/concepts/scheduling-eviction/api-eviction/).
|
||||
|
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
title: Диспетчер облачных контроллеров
|
||||
title: Cloud Controller Manager
|
||||
id: cloud-controller-manager
|
||||
date: 2018-04-12
|
||||
full_link: /docs/concepts/architecture/cloud-controller/
|
||||
|
@ -11,9 +11,15 @@ tags:
|
|||
- architecture
|
||||
- operation
|
||||
---
|
||||
Компонент {{< glossary_tooltip text="управляющего слоя" term_id="control-plane" >}} Kubernetes, встраивающий специфику облака в логику управления. Диспетчер облачных контроллеров позволяет связать кластер с API поставщика облачных услуг и отделить компоненты, взаимодействующие с этой облачной платформой, от компонентов, взаимодействующих только с вашим кластером.
|
||||
Диспетчер облачных контроллеров (Cloud Controller Manager, CCM) — компонент
|
||||
{{< glossary_tooltip text="управляющего слоя" term_id="control-plane" >}}
|
||||
Kubernetes, встраивающий специфику облака в логику управления. Он позволяет
|
||||
связать кластер с API поставщика облачных услуг и отделить компоненты,
|
||||
взаимодействующие с этой облачной платформой, от компонентов,
|
||||
взаимодействующих только с вашим кластером.
|
||||
|
||||
<!--more-->
|
||||
|
||||
Отделяя логику взаимодействия между Kubernetes и базовой облачной инфраструктурой, компонент cloud-controller-manager позволяет поставщикам облачных услуг выпускать функции в другом темпе по сравнению с основным проектом Kubernetes.
|
||||
|
||||
Отделяя логику взаимодействия между Kubernetes и базовой облачной инфраструктурой,
|
||||
компонент cloud-controller-manager позволяет поставщикам облачных услуг
|
||||
выпускать функции, не привязываясь к релизам основного проекта Kubernetes.
|
||||
|
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
title: Облачный Провайдер (Cloud Provider)
|
||||
title: Облачный провайдер
|
||||
id: cloud-provider
|
||||
date: 2018-04-12
|
||||
full_link: /docs/concepts/cluster-administration/cloud-providers
|
||||
|
@ -7,7 +7,7 @@ short_description: >
|
|||
Организация, которая предлагает платформу облачных вычислений.
|
||||
|
||||
aka:
|
||||
- Поставщик Облачных Услуг (Cloud Service Provider)
|
||||
- Поставщик облачных услуг (Cloud Service Provider)
|
||||
tags:
|
||||
- community
|
||||
---
|
||||
|
@ -15,17 +15,17 @@ tags:
|
|||
|
||||
<!--more-->
|
||||
|
||||
Облачные Провайдеры, иногда называемые Поставщиками Облачных Услуг (Cloud Service Provider, CSPs),
|
||||
Облачные провайдеры (Cloud Providers), иногда называемые Поставщиками облачных услуг (Cloud Service Provider, CSPs),
|
||||
предлагают облачные вычислительные платформы или услуги.
|
||||
|
||||
Многие облачные провайдеры предлагают управляемую инфраструктуру (также называемую
|
||||
Инфраструктура как Услуга (Infrastructure as a Service) или IaaS).
|
||||
Многие облачные провайдеры предлагают управляемую (managed) инфраструктуру, также называемую
|
||||
Инфраструктура как Услуга (Infrastructure as a Service, IaaS).
|
||||
С управляемой инфраструктурой облачный провайдер отвечает за
|
||||
сервера, хранилище и сеть, в то время как вы управляете слоями поверх этого,
|
||||
серверы, хранилище и сеть, в то время как вы управляете слоями поверх этого,
|
||||
такими как запуск Kubernetes кластера.
|
||||
|
||||
Вы также можете найти Kubernetes в качестве управляемого сервиса; иногда его называют
|
||||
Платформа как Услуга (Platform as a Service) или PaaS. С упарвляемым Kubernetes
|
||||
Вы также можете найти Kubernetes как управляемый сервис; иногда его называют
|
||||
Платформа как Услуга (Platform as a Service, PaaS). С managed Kubernetes
|
||||
ваш облачный провайдер отвечает за
|
||||
{{< glossary_tooltip term_id="control-plane" text="управляющий слой" >}} Kubernetes, а также за
|
||||
{{< glossary_tooltip term_id="node" text="узлы" >}} и инфраструктуру, на которую они полагаются:
|
||||
|
|
|
@ -4,14 +4,14 @@ id: cluster
|
|||
date: 2019-06-15
|
||||
full_link:
|
||||
short_description: >
|
||||
Набор машин, так называемые узлы, которые запускают контейнеризированные приложения. Кластер имеет как минимум один рабочий узел.
|
||||
Набор рабочих машин, называемых узлами, которые запускают контейнеризированные приложения. Кластер имеет как минимум один рабочий узел.
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- fundamental
|
||||
- operation
|
||||
---
|
||||
Набор машин, так называемые узлы, которые запускают контейнеризированные приложения. Кластер имеет как минимум один рабочий узел.
|
||||
Набор рабочих машин, называемых узлами, которые запускают контейнеризированные приложения. Кластер имеет как минимум один рабочий узел.
|
||||
|
||||
<!--more-->
|
||||
В рабочих узлах размещены поды, являющиеся компонентами приложения. Управляющий слой (control plane) управляет рабочими узлами и подами в кластере. В промышленных средах управляющий слой обычно запускается на нескольких компьютерах, а кластер, как правило, развёртывается на нескольких узлах, гарантируя отказоустойчивость и высокую надёжность.
|
||||
В рабочих узлах размещены поды, которые являются компонентами приложения. {{< glossary_tooltip text="Управляющий слой" term_id="control-plane" >}} управляет рабочими узлами и подами в кластере. В production-средах управляющий слой обычно запускается на нескольких компьютерах, а кластер, как правило, развёртывается на нескольких узлах, гарантируя отказоустойчивость и высокую доступность.
|
||||
|
|
|
@ -1,21 +1,20 @@
|
|||
---
|
||||
title: Иcполняемая среда контейнеров
|
||||
title: Container Runtime
|
||||
id: container-runtime
|
||||
date: 2019-06-05
|
||||
full_link: /docs/setup/production-environment/container-runtimes
|
||||
short_description: >
|
||||
Иcполняемая среда контейнеров — это программа, предназначенная для запуска контейнеров.
|
||||
Иcполняемая среда контейнеров — это программное обеспечение, предназначенное для запуска контейнеров.
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- fundamental
|
||||
- workload
|
||||
---
|
||||
Иcполняемая среда контейнера — это программа, предназначенная для запуска контейнера в Kubernetes.
|
||||
Фундаментальный компонент, который позволяет Kubernetes эффективно запускать контейнеры. Он отвечает за управление исполнением и жизненным циклом контейнеров в рамках Kubernetes.
|
||||
|
||||
<!--more-->
|
||||
|
||||
Kubernetes поддерживает различные среды для запуска контейнеров: {{< glossary_tooltip term_id="docker">}},
|
||||
{{< glossary_tooltip term_id="containerd" >}}, {{< glossary_tooltip term_id="cri-o" >}},
|
||||
и любые реализации [Kubernetes CRI (Container Runtime
|
||||
Kubernetes поддерживает различные среды для запуска контейнеров: {{< 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).
|
||||
|
|
|
@ -4,15 +4,16 @@ id: container
|
|||
date: 2018-04-12
|
||||
full_link: /docs/concepts/overview/what-is-kubernetes/#why-containers
|
||||
short_description: >
|
||||
Переносимый и не требовательный к ресурсам исполняемый экземпляр образа, содержащий приложение вместе со всеми его зависимостями.
|
||||
Легковесный и переносимый исполняемый образ, содержащий программное обеспечение вместе со всеми его зависимостями.
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- fundamental
|
||||
- workload
|
||||
---
|
||||
Переносимый и не требовательный к ресурсам исполняемый экземпляр образа, содержащий приложение вместе со всеми его зависимостями.
|
||||
Легковесный и переносимый исполняемый образ, содержащий программное обеспечение вместе со всеми его зависимостями.
|
||||
|
||||
<!--more-->
|
||||
|
||||
Контейнеры изолирует приложения от инфраструктуры хост-машины, чтобы обеспечить простое масштабирование и упростить развёртывание в различных средах облачных платформ или операционных систем.
|
||||
Контейнеры изолируют приложения от инфраструктуры хост-машины, чтобы обеспечить простое развёртывание в различных средах облачных платформ и операционных систем, а также упростить масштабирование.
|
||||
Приложения, запускаемые внутри контейнеров, называются контейнеризированными приложениями. Процесс упаковки этих приложений и их зависимостей в образ контейнера называется контейнеризацией.
|
||||
|
|
|
@ -4,14 +4,14 @@ 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 заботится о получении и хранении образов контейнеров, запуске контейнеров, осуществлять доступ по сети и т.д.
|
||||
containerd — исполяемая среда для {{< glossary_tooltip text="контейнеров" term_id="container" >}}, который запускается как демон в Linux или Windows. containerd заботится о получении и хранении образов контейнеров, запуске контейнеров, предоставлении сетевого доступа и т.д.
|
||||
|
|
|
@ -4,10 +4,10 @@ id: control-plane
|
|||
date: 2019-05-12
|
||||
full_link:
|
||||
short_description: >
|
||||
Уровень оркестрации контейнеров с API и интерфейсами для определения, развёртывания и управления жизненным циклом контейнеров.
|
||||
Уровень оркестрации контейнеров, предоставляющий API и интерфейсы для определения, развёртывания и управления жизненным циклом контейнеров.
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- fundamental
|
||||
---
|
||||
Уровень оркестрации контейнеров с API и интерфейсами для определения, развёртывания и управления жизненным циклом контейнеров.
|
||||
Уровень оркестрации контейнеров, предоставляющий API и интерфейсы для определения, развёртывания и управления жизненным циклом контейнеров.
|
||||
|
|
|
@ -4,14 +4,14 @@ id: controller
|
|||
date: 2018-04-12
|
||||
full_link: /docs/concepts/architecture/controller/
|
||||
short_description: >
|
||||
Управляющий цикл который отслеживает общее состояние кластера через API-сервер и вносит изменения пытаясь приветси текушее состояние к желаемому состоянию.
|
||||
Управляющий цикл, который отслеживает общее состояние кластера через API-сервер и вносит изменения, пытаясь привести текущее состояние к желаемому.
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- architecture
|
||||
- fundamental
|
||||
---
|
||||
Контроллеры в Kubernetes - управляющие циклы, которые отслеживают состояние вашего
|
||||
Контроллеры в Kubernetes — управляющие циклы (control loops), которые отслеживают состояние вашего
|
||||
{{< glossary_tooltip term_id="cluster" text="кластера">}}, затем вносят или запрашивают
|
||||
изменения там, где это необходимо.
|
||||
Каждый контроллер пытается привести текущее состояние кластера ближе к желаемому состоянию.
|
||||
|
@ -22,8 +22,7 @@ tags:
|
|||
{{< glossary_tooltip text="API-сервер" term_id="kube-apiserver" >}} (часть
|
||||
{{< glossary_tooltip text="управляющего слоя" term_id="control-plane" >}}).
|
||||
|
||||
Некоторые контроллеры также работают внутри управляющего слоя (control plane),
|
||||
обеспечивая управляющие циклы, которые являются ядром для операций Kubernetes. Например:
|
||||
контроллер развертывания (deployment controller), контроллер daemonset (daemonset controller),
|
||||
контроллер пространства имен (namespace controller) и контроллер постоянных томов (persistent volume
|
||||
controller) (и другие) работают с {{< glossary_tooltip term_id="kube-controller-manager" >}}.
|
||||
Некоторые контроллеры также работают внутри управляющего слоя, реализуя управляющие циклы,
|
||||
которые являются основой для операций Kubernetes. Например:
|
||||
контроллер деплоймента, контроллер DaemonSet'а, контроллер пространства имен
|
||||
и контроллер постоянных томов (и другие) работают с {{< glossary_tooltip term_id="kube-controller-manager" >}}.
|
||||
|
|
|
@ -4,16 +4,16 @@ id: cri-o
|
|||
date: 2019-05-14
|
||||
full_link: https://cri-o.io/#what-is-cri-o
|
||||
short_description: >
|
||||
Оптимизированная среда выполнения контейнеров, разработанная специально для Kubernetes
|
||||
Легковесная исполняемая среда для контейнеров, разработанная специально для Kubernetes
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- tool
|
||||
---
|
||||
Инструмент, позволяющий использовать среды выполнения контейнеров формата OCI с помощью технологии Kubernetes CRI.
|
||||
Инструмент, позволяющий использовать исполняемые среды для контейнеров стандарта 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 — это реализация {{< glossary_tooltip term_id="cri" >}}, позволяющая использовать исполняемые среды для {{< glossary_tooltip text="контейнеров" term_id="container" >}}, совместимые со [спецификацией runtime](http://www.github.com/opencontainers/runtime-spec) Open Container Initiative (OCI).
|
||||
|
||||
Развертывание CRI-O позволяет Kubernetes использовать любую OCI-совместимую среду выполнения в качестве контейнерной среды выполнения для выполнения {{< glossary_tooltip text="подов" term_id="pod" >}} и загружать образы OCI-контейнера из удаленных реестров.
|
||||
Развертывание CRI-O позволяет Kubernetes использовать любую OCI-совместимую исполняемую среду в качестве среды выполнения для {{< glossary_tooltip text="подов" term_id="pod" >}} и загружать контейнерные образы OCI из удаленных реестров.
|
||||
|
|
|
@ -2,16 +2,16 @@
|
|||
title: Container runtime interface (CRI)
|
||||
id: cri
|
||||
date: 2019-03-07
|
||||
full_link: /docs/concepts/overview/components/#container-runtime
|
||||
full_link: /ru/docs/concepts/overview/components/#container-runtime
|
||||
short_description: >
|
||||
API сред выполнения контейнеров для интеграции с kubelet
|
||||
API для исполняемых сред контейнеров для интеграции с kubelet
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- fundamental
|
||||
---
|
||||
Интерфейс среды выполнения контейнера (Container Runtime Interface, CRI) — это API сред выполнения контейнера, которая интегрируется с kubelet на узле.
|
||||
Container Runtime Interface (CRI) — это интерфейс API для исполняемых сред контейнеров, который интегрирует их с kubelet на узле.
|
||||
|
||||
<!--more-->
|
||||
|
||||
Для получения дополнительной информации смотрите API и спефикации [CRI](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/container-runtime-interface.md).
|
||||
Для получения дополнительной информации смотрите API и спецификации [CRI](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/container-runtime-interface.md).
|
||||
|
|
|
@ -4,7 +4,7 @@ id: daemonset
|
|||
date: 2018-04-12
|
||||
full_link: /docs/concepts/workloads/controllers/daemonset
|
||||
short_description: >
|
||||
Гарантирует, что копия Pod выполняется в наборе узлов кластера.
|
||||
Гарантирует, что копия пода выполняется на множестве узлов кластера.
|
||||
|
||||
aka:
|
||||
tags:
|
||||
|
@ -12,8 +12,8 @@ tags:
|
|||
- core-object
|
||||
- workload
|
||||
---
|
||||
Гарантирует, что копия {{< glossary_tooltip text="Pod" term_id="pod" >}} выполняется в наборе узлов {{< glossary_tooltip text="кластера" term_id="cluster" >}}.
|
||||
Гарантирует, что копия {{< glossary_tooltip text="пода" term_id="pod" >}} выполняется на множестве узлов {{< glossary_tooltip text="кластера" term_id="cluster" >}}.
|
||||
|
||||
<!--more-->
|
||||
|
||||
Используется для развертывания системных демонов, таких как сборщики логов и агенты мониторинга, которые, как правило, должны работать на каждом {{< glossary_tooltip text="узла" term_id="node" >}}.
|
||||
Используется для развертывания системных демонов, таких как сборщики логов и агенты мониторинга, которые, как правило, должны работать на каждом {{< glossary_tooltip text="узле" term_id="node" >}}.
|
||||
|
|
|
@ -1,10 +1,10 @@
|
|||
---
|
||||
title: Deployment
|
||||
title: Деплоймент (Deployment)
|
||||
id: deployment
|
||||
date: 2018-04-12
|
||||
full_link: /docs/concepts/workloads/controllers/deployment/
|
||||
short_description: >
|
||||
API-объект, управляющий реплицированным приложением.
|
||||
Управляет реплицированным приложением в кластере.
|
||||
|
||||
aka:
|
||||
tags:
|
||||
|
@ -12,9 +12,10 @@ tags:
|
|||
- core-object
|
||||
- workload
|
||||
---
|
||||
API-объект, управляющий реплицированным приложением.
|
||||
Объект API, который управляет реплицированным (т.е. имеющим копии) приложением, обычно путём запуска подов без локального хранения данных (т.е. stateless).
|
||||
|
||||
<!--more-->
|
||||
|
||||
Каждая реплика представляет {{< glossary_tooltip term_id="pod" >}}, а все Pod-объекты распределяются по узлам кластера.
|
||||
|
||||
Каждая реплика представлена {{< glossary_tooltip text="подом" term_id="pod" >}},
|
||||
а все поды распределяются по {{< glossary_tooltip text="узлам" term_id="node" >}} кластера.
|
||||
Для рабочих нагрузок, требующих локальное хранение данных, стоит обратить внимание на {{< glossary_tooltip term_id="StatefulSet" >}}.
|
||||
|
|
|
@ -4,14 +4,14 @@ id: docker
|
|||
date: 2018-04-12
|
||||
full_link: https://docs.docker.com/engine/
|
||||
short_description: >
|
||||
Docker — это программное обеспечение для виртуализации на уровне операционной системы, которая известна как контейнеризация.
|
||||
Docker — это программное обеспечение, реализующее виртуализацию на уровне операционной системы, которая известна как контейнеризация.
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- fundamental
|
||||
---
|
||||
Docker (в частности, Docker Engine) — это программное обеспечение для виртуализации на уровне операционной системы, которая также известна как {{< glossary_tooltip text="контейнеризация" term_id="container" >}}.
|
||||
Docker (в частности, Docker Engine) — это программное обеспечение, реализующее виртуализацию на уровне операционной системы, которая также известна как {{< glossary_tooltip text="контейнеризация" term_id="container" >}}.
|
||||
|
||||
<!--more-->
|
||||
|
||||
Docker использует возможности изоляции ресурсов ядра Linux, такие как cgroups и пространства имен ядра, а также каскадно-объединённую файловую систему, например, OverlayFS и другие, чтобы независимые друг от друга контейнеры могли работать в одном экземпляре Linux без накладных расходов на запуск и поддержку работы виртуальных машин (VM).
|
||||
Docker использует возможности изоляции ресурсов ядра Linux, такие как cgroups и пространства имен ядра, а также каскадную файловую систему (например, OverlayFS или другие), чтобы независимые контейнеры могли работать в одном экземпляре Linux без накладных расходов на запуск и поддержку работы виртуальных машин (VM).
|
||||
|
|
|
@ -4,14 +4,14 @@ id: etcd
|
|||
date: 2018-04-12
|
||||
full_link: /docs/tasks/administer-cluster/configure-upgrade-etcd/
|
||||
short_description: >
|
||||
Распределённое и высоконадёжное хранилище данных в формате "ключ-значение", которое используется как основное хранилище всех данных кластера в Kubernetes.
|
||||
Консистентное и высокодоступное хранилище данных в формате «ключ-значение», которое используется как основное хранилище всех данных кластера Kubernetes.
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- architecture
|
||||
- storage
|
||||
---
|
||||
Распределённое и высоконадёжное хранилище данных в формате "ключ-значение", которое используется как основное хранилище всех данных кластера в Kubernetes.
|
||||
Консистентное и высокодоступное хранилище данных в формате «ключ-значение», которое используется как основное хранилище всех данных кластера Kubernetes.
|
||||
|
||||
<!--more-->
|
||||
|
||||
|
|
|
@ -1,23 +1,23 @@
|
|||
---
|
||||
title: Сборшик мусора
|
||||
title: Сбор мусора
|
||||
id: garbage-collection
|
||||
date: 2021-07-07
|
||||
full_link: /docs/concepts/workloads/controllers/garbage-collection/
|
||||
short_description: >
|
||||
A collective term for the various mechanisms Kubernetes uses to clean up cluster
|
||||
resources.
|
||||
Сбор мусора — это собирательный термин для различных механизмов,
|
||||
используемых Kubernetes для очистки ресурсов кластера.
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- fundamental
|
||||
- operation
|
||||
---
|
||||
Сборщик мусора - это собирательный термин для различных механизмов? используемых Kubernetes для очистки ресурсов кластера.
|
||||
Сбор мусора — это собирательный термин для различных механизмов, используемых Kubernetes для очистки ресурсов кластера.
|
||||
|
||||
<!--more-->
|
||||
|
||||
Kubernetes использует сборку мусора для очистки таких ресурсов, как [неиспользуемые контейнеры и образы](/docs/concepts/workloads/controllers/garbage-collection/#containers-images),
|
||||
[неудачные Pod-ы](/docs/concepts/workloads/pods/pod-lifecycle/#pod-garbage-collection),
|
||||
[неисправные поды](/docs/concepts/workloads/pods/pod-lifecycle/#pod-garbage-collection),
|
||||
[объекты, принадлежащие целевому ресурсу](/docs/concepts/overview/working-with-objects/owners-dependents/),
|
||||
[завершенные задачи](/docs/concepts/workloads/controllers/ttlafterfinished/), and resources
|
||||
that have expired or failed.
|
||||
[завершенные задачи](/docs/concepts/workloads/controllers/ttlafterfinished/) и ресурсы,
|
||||
время работы которых истекло или которые завершились ошибкой.
|
||||
|
|
|
@ -4,7 +4,7 @@ id: kube-apiserver
|
|||
date: 2018-04-12
|
||||
full_link: /docs/reference/generated/kube-apiserver/
|
||||
short_description: >
|
||||
Компонент панели управления, обслуживающий API Kubernetes.
|
||||
Компонент управляющего слоя, предоставляющий Kubernetes API.
|
||||
|
||||
aka:
|
||||
- kube-apiserver
|
||||
|
@ -12,12 +12,11 @@ tags:
|
|||
- architecture
|
||||
- fundamental
|
||||
---
|
||||
Сервер API — компонент Kubernetes
|
||||
{{< glossary_tooltip text="панели управления" term_id="control-plane" >}}, который представляет API Kubernetes.
|
||||
API-сервер — это клиентская часть панели управления Kubernetes
|
||||
API-сервер — компонент {{< glossary_tooltip text="управляющего слоя" term_id="control-plane" >}} Kubernetes,
|
||||
который делаает доступным Kubernetes API. API-сервер — это фронтенд управляющего слоя Kubernetes.
|
||||
|
||||
<!--more-->
|
||||
|
||||
Основной реализацией API-сервера Kubernetes является [kube-apiserver](/docs/reference/generated/kube-apiserver/).
|
||||
kube-apiserver предназначен для горизонтального масштабирования, то есть развёртывание на несколько экземпляров.
|
||||
Вы можете запустить несколько экземпляров kube-apiserver и сбалансировать трафик между этими экземплярами.
|
||||
kube-apiserver предназначен для горизонтального масштабирования, то есть он масштабируется при развёртывании
|
||||
на множестве экземплярах. Вы можете запускать множество экземпляров kube-apiserver и балансировать трафик между ними.
|
||||
|
|
|
@ -4,15 +4,15 @@ 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" >}}.
|
||||
Компонент управляющего слоя, который запускает процессы {{< glossary_tooltip text="контроллера" term_id="controller" >}}.
|
||||
|
||||
<!--more-->
|
||||
|
||||
Вполне логично, что каждый {{< glossary_tooltip text="контроллер" term_id="controller" >}} в свою очередь представляет собой отдельный процесс, и для упрощения все такие процессы скомпилированы в один двоичный файл и выполняются в одном процессе.
|
||||
С логической точки зрения каждый {{< glossary_tooltip text="контроллер" term_id="controller" >}} представляет собой отдельный процесс. Но для упрощения все они скомпилированы в один бинарный файл и выполняются в одном процессе.
|
||||
|
|
|
@ -11,10 +11,10 @@ tags:
|
|||
- fundamental
|
||||
- networking
|
||||
---
|
||||
[kube-proxy](/docs/reference/command-line-tools-reference/kube-proxy/) — сетевой прокси, работающий на каждом узле в кластере, и реализующий часть концепции {{< glossary_tooltip text="сервис" term_id="service">}}.
|
||||
kube-proxy — сетевой прокси, работающий на каждом {{< glossary_tooltip text="узле" term_id="node">}} в кластере и реализующий часть концепции {{< glossary_tooltip text="сервиса" term_id="service">}} Kubernetes.
|
||||
|
||||
<!--more-->
|
||||
|
||||
kube-proxy конфигурирует правила сети на узлах. При помощи них разрешаются сетевые подключения к вашими подам изнутри и снаружи кластера.
|
||||
[kube-proxy](/docs/reference/command-line-tools-reference/kube-proxy/) поддерживает сетевые правила на узлах. Эти правила разрешают сетевое взаимодействие с вашимии подами из сетевых сессий внутри и снаружи кластера.
|
||||
|
||||
kube-proxy использует уровень фильтрации пакетов в операционной системы, если он доступен. В противном случае, kube-proxy сам обрабатывает передачу сетевого трафика.
|
||||
kube-proxy использует уровень фильтрации пакетов операционной системы, если он доступен. В ином случае kube-proxy сам перенаправляет трафик.
|
||||
|
|
|
@ -4,16 +4,18 @@ id: kube-scheduler
|
|||
date: 2018-04-12
|
||||
full_link: /docs/reference/generated/kube-scheduler/
|
||||
short_description: >
|
||||
Компонент управляющего слоя, который отслеживает созданные поды без привязанного узла и выбирает узел, на котором они должны работать.
|
||||
Компонент управляющего слоя, который отслеживает недавно созданные поды без назначенного для них узла и выбирает узел, на котором они должны работать.
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- architecture
|
||||
---
|
||||
Компонент управляющего слоя (control plane), который отслеживает созданные поды без привязанного узла и выбирает узел, на котором они должны работать.
|
||||
Компонент управляющего слоя (control plane), который отслеживает недавно созданные поды без назначенного для них узла и выбирает узел, на котором они должны работать.
|
||||
|
||||
<!--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) узлов/подов, местонахождения данных, предельных сроков.
|
||||
При планировании учитываются множество факторов, включая индивидуальные
|
||||
и общие требования к ресурсам, ограничения по железу/программному обеспечению/политикам,
|
||||
конфигурация принадлежности (affinity) и непринадлежности (anti-affinity)
|
||||
узлов/подов, местонахождение данных, взаимодействие между рабочими
|
||||
нагрузками и дедлайны.
|
||||
|
|
|
@ -15,4 +15,4 @@ tags:
|
|||
|
||||
<!--more-->
|
||||
|
||||
Утилита kubelet принимает набор PodSpecs, и гарантирует работоспособность и исправность определённых в них контейнеров. Агент kubelet не отвечает за контейнеры, не созданные Kubernetes.
|
||||
[Kubelet](/docs/reference/command-line-tools-reference/kubelet/) принимает набор PodSpecs, которые определяются разными способами и гарантируют работоспособность и исправность определённых в них контейнеров. Kubelet не отвечает за контейнеры, не созданные Kubernetes.
|
||||
|
|
|
@ -1,17 +1,17 @@
|
|||
---
|
||||
title: Метка
|
||||
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" >}}. Они используются для организации и получения подмножеств объектов.
|
||||
Лейблы — это пары «ключ-значение», которые прикрепляются к таким объектам, как {{< glossary_tooltip text="под" term_id="pod" >}}. Они используются для организации и получения подмножеств объектов.
|
||||
|
|
|
@ -14,4 +14,4 @@ tags:
|
|||
|
||||
<!--more-->
|
||||
|
||||
Указанное имя может иметь только один объект определённого типа. Но если вы удалите этот объект, вы можете создать новый с таким же именем
|
||||
Указанное имя может иметь только один объект определённого типа. Но если вы удалите этот объект, вы можете создать новый с таким же именем.
|
||||
|
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
title: Node
|
||||
title: Узел
|
||||
id: node
|
||||
date: 2018-04-12
|
||||
full_link: /docs/concepts/architecture/nodes/
|
||||
|
@ -10,8 +10,10 @@ aka:
|
|||
tags:
|
||||
- fundamental
|
||||
---
|
||||
Узел — рабочая машина в Kubernetes.
|
||||
Узел (node) — рабочая машина в Kubernetes.
|
||||
|
||||
<!--more-->
|
||||
|
||||
Рабочий узел может быть как виртуальной, так и физической машиной, в зависимости от кластера. У него есть локальные демоны или сервисы, необходимые для запуска {{< glossary_tooltip text="подов" term_id="pod" >}}, а сам он управляется управляющим слоем (control plane). Демоны на узле включают в себя {{< 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" >}}.
|
||||
Рабочий узел может быть как виртуальной, так и физической машиной, в зависимости от кластера. У него есть локальные демоны или сервисы, необходимые для запуска {{< glossary_tooltip text="подов" term_id="pod" >}}, а сам он управляется управляющим слоем (control plane). Демоны на узле включают в себя {{< 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" >}}).
|
||||
|
||||
В ранних версиях Kubernetes узлы назывались «миньонами» (Minions).
|
||||
|
|
|
@ -12,7 +12,7 @@ tags:
|
|||
Сущность в системе Kubernetes. Kubernetes использует их для представления состояния кластера.
|
||||
<!--more-->
|
||||
Объект Kubernetes обычно представляет собой «запись о намерениях»: как только объект создан,
|
||||
{{< glossary_tooltip text="слой управления" term_id="control-plane" >}} Kubernetes обеспечивает гарантию того,
|
||||
{{< glossary_tooltip text="управляющий слой" term_id="control-plane" >}} Kubernetes обеспечивает гарантию того,
|
||||
что элемент, который этот объект представляет, действительно существует.
|
||||
Создавая объект, вы фактически указываете системе Kubernetes, как должна
|
||||
выглядеть эта часть рабочей нагрузки кластера; это желаемое состояние вашего кластера.
|
||||
|
|
|
@ -1,10 +1,10 @@
|
|||
---
|
||||
id: pod-disruption
|
||||
title: Нарушение работы Pod'ов
|
||||
title: Нарушение работы подов
|
||||
full_link: /docs/concepts/workloads/pods/disruptions/
|
||||
date: 2021-05-12
|
||||
short_description: >
|
||||
Процесс, в ходе которого происходит плановое или принудительное завершение работы Pod'ов на узлах.
|
||||
Процесс, в ходе которого происходит плановое или принудительное завершение работы подов на узлах.
|
||||
|
||||
aka:
|
||||
related:
|
||||
|
@ -14,11 +14,11 @@ tags:
|
|||
- operation
|
||||
---
|
||||
|
||||
[Нарушение работы Pod'ов (Pod disruption)](/docs/concepts/workloads/pods/disruptions/) — процесс,
|
||||
в ходе которого происходит плановое или внеплановое (принудительное) завершение работы Pod'ов на узлах.
|
||||
[Нарушение работы подов (Pod disruption)](/docs/concepts/workloads/pods/disruptions/) — процесс,
|
||||
в ходе которого происходит плановое или внеплановое (принудительное) завершение работы подов на узлах.
|
||||
|
||||
<!--more-->
|
||||
|
||||
Плановое завершение работы Pod'ов инициируется владельцами приложений или администраторами
|
||||
Плановое завершение работы подов инициируется владельцами приложений или администраторами
|
||||
кластера. Внеплановое завершение работы обычно вызвано непредвиденными обстоятельствами различной природы,
|
||||
например, с недостатком ресурсов на узлах или случайными удалениями.
|
||||
например, недостатком ресурсов на узлах или случайными удалениями.
|
||||
|
|
|
@ -15,4 +15,4 @@ tags:
|
|||
|
||||
<!--more-->
|
||||
|
||||
Как правило, один под предназначен для выполнения одного основного контейнера. Он также может запускать дополнительные "прицепные" (sidecar) контейнеры, добавляющие новые функциональные возможности, например, логирование. Контейнеры обычно управляются {{< glossary_tooltip term_id="deployment" >}}.
|
||||
Как правило, один под предназначен для выполнения одного основного контейнера. Он также может запускать вспомогательные («прицепные») sidecar-контейнеры, добавляющие новые функциональные возможности, например, логирование. Поды обычно управляются {{< glossary_tooltip text="деплойментом" term_id="deployment" >}}.
|
||||
|
|
|
@ -1,18 +1,20 @@
|
|||
---
|
||||
title: Secret
|
||||
title: Секрет (Secret)
|
||||
id: secret
|
||||
date: 2018-04-12
|
||||
full_link: /docs/concepts/configuration/secret/
|
||||
short_description: >
|
||||
Хранит конфиденциальную информацию, такую как пароли, токены OAuth и ключи ssh.
|
||||
Хранит конфиденциальную информацию, такую как пароли, токены OAuth и ключи SSH.
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- core-object
|
||||
- security
|
||||
---
|
||||
Хранит конфиденциальную информацию, такую как пароли, токены OAuth и ключи ssh.
|
||||
Хранит конфиденциальную информацию, такую как пароли, токены OAuth и ключи SSH.
|
||||
|
||||
<!--more-->
|
||||
|
||||
Позволяет повысить контроль над использованием конфиденциальной информации и снизить риск ее случайного раскрытия. Секретные значения кодируются в формат base64 и по умолчанию хранятся в незашифрованном виде, но могут быть настроены на шифрование "at rest" (при записи в хранилище). {{< glossary_tooltip text="Pod" term_id="pod" >}} ссылается на Secret как на файл при монтировании тома. Secret также используется kubelet'ом при извлечении образов для Pod'а. Secret'ы отлично подходят для хранения конфиденциальных данных, [ConfigMaps](/docs/tasks/configure-pod-container/configure-pod-configmap/) – для неконфиденциальных.
|
||||
Позволяет повысить контроль над использованием конфиденциальной информации и снизить риск ее случайного раскрытия. Секретные значения кодируются в формат base64 и по умолчанию хранятся в незашифрованном виде, но могут быть настроены на [шифрование "at rest"](/docs/tasks/administer-cluster/encrypt-data/#ensure-all-secrets-are-encrypted) (при записи в хранилище).
|
||||
|
||||
{{< glossary_tooltip text="Под" term_id="pod" >}} ссылается на секрет разными способами — например, при монтировании тома или как переменную окружения. Секреты предназначены для конфиденциальных данных, а для неконфиденциальных данных предусмотрены [ConfigMaps](/docs/tasks/configure-pod-container/configure-pod-configmap/).
|
||||
|
|
|
@ -4,15 +4,15 @@ 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" >}}.
|
||||
Селекторы применяются при создании запросов для фильтрации списков ресурсов по {{< glossary_tooltip text="лейблам" term_id="label" >}}.
|
||||
|
||||
|
|
|
@ -4,15 +4,15 @@ id: service-account
|
|||
date: 2018-04-12
|
||||
full_link: /docs/tasks/configure-pod-container/configure-service-account/
|
||||
short_description: >
|
||||
Отвечает за идентификацию процессов, выполняющихся в Pod'е.
|
||||
Отвечает за идентификацию процессов, выполняющихся в поде.
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- fundamental
|
||||
- core-object
|
||||
---
|
||||
Отвечает за идентификацию процессов, выполняющихся в {{< glossary_tooltip text="Pod'е" term_id="pod" >}}.
|
||||
Отвечает за идентификацию процессов, выполняющихся в {{< glossary_tooltip text="поде" term_id="pod" >}}.
|
||||
|
||||
<!--more-->
|
||||
|
||||
Процессы внутри Pod'а аутентифицируются сервером API и относятся к определенной учетной записи (service account) (например, к `default`) для доступа к кластеру. Если при создании Pod'а служебная учетная запись не указана, ему автоматически присваивается service account по умолчанию в том же {{< glossary_tooltip text="пространстве имен" term_id="namespace" >}}.
|
||||
Процессы внутри пода аутентифицируются сервером API и относятся к определенной учетной записи (service account) (например, к `default`) для доступа к кластеру. Если при создании пода служебная учетная запись не указана, ему автоматически присваивается service account по умолчанию в том же {{< glossary_tooltip text="пространстве имен" term_id="namespace" >}}.
|
||||
|
|
|
@ -15,4 +15,8 @@ tags:
|
|||
|
||||
<!--more-->
|
||||
|
||||
Набор подов, из которых состоит сервис, определяется (как правило) {{< glossary_tooltip text="селектором" term_id="selector" >}}. При добавлении или удалении подов, набор подов, соответствующий селектору, изменится. Сервис обеспечивает, что сетевой трафик может быть направлен на текущий набор подов для планирования рабочей нагрузки.
|
||||
Набор подов, из которых состоит сервис, определяется (как правило) {{< glossary_tooltip text="селектором" term_id="selector" >}}. Если поды добавляются или удаляются, набор подов, соответствующий селектору, изменится. Сервис гарантирует, что сетевой трафик может быть направлен на текущий набор подов у рабочей нагрузки.
|
||||
|
||||
Сервисы Kubernetes используют либо IP-сеть (IPv4, IPv6 или оба), либо ссылаются на внешнее имя в системе DNS (Domain Name System).
|
||||
|
||||
Абстракция сервиса позволяет работать другим механизмам, такие как Ingress и Gateway.
|
||||
|
|
|
@ -14,4 +14,4 @@ tags:
|
|||
|
||||
<!--more-->
|
||||
|
||||
У каждого объекта, созданного в течение всего периода работы кластера Kubernetes, есть собственный уникальный идентификатор (UID). Он предназначен для выяснения различий между событиями похожих сущностей.
|
||||
У каждого объекта, созданного в течение всего периода работы кластера Kubernetes, есть собственный уникальный идентификатор (UID). Он предназначен для различения схожих сущностей, существовавших в кластере в разное время.
|
||||
|
|
Loading…
Reference in New Issue