kubernetes
diff --git a/‎content/ru/docs/concepts/overview/components.md
+4-4 b/‎content/ru/docs/concepts/overview/components.md
+4-4
diff --git a/‎content/ru/docs/concepts/overview/kubernetes-api.md
+2-2 b/‎content/ru/docs/concepts/overview/kubernetes-api.md
+2-2
diff --git a/‎content/ru/docs/concepts/overview/what-is-kubernetes.md
+1-1 b/‎content/ru/docs/concepts/overview/what-is-kubernetes.md
+1-1
diff --git a/‎content/ru/docs/concepts/overview/working-with-objects/kubernetes-objects.md
+3-3 b/‎content/ru/docs/concepts/overview/working-with-objects/kubernetes-objects.md
+3-3
@@ -11,13 +11,13 @@ card:
 
 <!-- overview -->
 При развёртывании Kubernetes вы имеете дело с кластером.
-{{< glossary_definition term_id="cluster" length="all" prepend="Кластер Kubernetes cluster состоит из">}}
+{{< glossary_definition term_id="cluster" length="all" prepend="Kubernetes-кластер состоит из">}}
 
-На этой странице в общих чертах описывается различные компоненты, необходимые для работы кластера Kubernetes.
+На этой странице в общих чертах описываются различные компоненты, необходимые для работы кластера Kubernetes.
 
 Ниже показана диаграмма кластера Kubernetes со всеми связанными компонентами.
 
-![Компоненты Kubernetes](/images/docs/components-of-kubernetes.png)
+![Компоненты Kubernetes](/images/docs/components-of-kubernetes.svg)
 
 
 
@@ -27,7 +27,7 @@ card:
 
 Компоненты управляющего слоя (control plane) отвечают за основные операции кластера (например, планирование), а также обрабатывают события кластера (например, запускают новый {{< glossary_tooltip text="под" term_id="pod">}}, когда поле `replicas` развертывания не соответствует требуемому количеству реплик).
 
-Компоненты управляющего слоя могут быть запущены на любой машине в кластере. Однако для простоты сценарии настройки обычно запускают все компоненты управляющего слоя на одном компьютере и в то же время не позволяют запускать пользовательские контейнеры на этом компьютере. Смотрите страницу [Создание высоконадёжных кластеров](/docs/admin/high-availability/) для примера настройки нескольких ведущих виртуальных машин.
+Компоненты управляющего слоя могут быть запущены на любой машине в кластере. Однако, для простоты, сценарии настройки обычно запускают все компоненты управляющего слоя на одном компьютере и в то же время не позволяют запускать пользовательские контейнеры на этом компьютере. Смотрите страницу [Создание высоконадёжных кластеров](/docs/admin/high-availability/) для примера настройки нескольких ведущих виртуальных машин.
 
 ### kube-apiserver
 
 
@@ -75,9 +75,9 @@ GET /swagger-2.0.0.pb-v1.gz | GET /openapi/v2 **Accept**: application/com.github
   - Рекомендуется для использования только в тестировочных кластерах с коротким жизненным циклом из-за высокого риска наличия багов и отсутствия долгосрочной поддержки.
 - Бета-версии:
   - Названия версий включают надпись `beta` (например, `v2beta3`).
-  - Код хорошо протестирован. Активация этой функциональности — безопасно. Поэтому она включена по умолчанию.
+  - Код хорошо протестирован. Активация этой функциональности — безопасна. Поэтому она включена по умолчанию.
   - Поддержка функциональности в целом не будет прекращена, хотя кое-что может измениться.
-  - Схема и/или семантика объектов может стать несовместимой с более поздними бета-версиями или стабильными выпусками. Когда это случится, мы даем инструкции по миграции на следующую версию. Это обновление может включать удаление, редактирование и повторного создание API-объектов. Этот процесс может потребовать тщательного анализа. Кроме этого, это может привести к простою приложений, которые используют данную функциональность.
+  - Схема и/или семантика объектов может стать несовместимой с более поздними бета-версиями или стабильными выпусками. Когда это случится, мы даем инструкции по миграции на следующую версию. Это обновление может включать удаление, редактирование и повторное создание API-объектов. Этот процесс может потребовать тщательного анализа. Кроме этого, это может привести к простою приложений, которые используют данную функциональность.
   - Рекомендуется только для неосновного производственного использования из-за риска возникновения возможных несовместимых изменений с будущими версиями. Если у вас есть несколько кластеров, которые возможно обновить независимо, вы можете снять это ограничение.
   - **Пожалуйста, попробуйте в действии бета-версии функциональности и поделитесь своими впечатлениями! После того как функциональность выйдет из бета-версии, нам может быть нецелесообразно что-то дальше изменять.**
 - Стабильные версии:
 
@@ -81,7 +81,7 @@ Kubernetes:
 * Не включает решения для ведения журнала, мониторинга или оповещения. Он обеспечивает некоторые интеграции в качестве доказательства концепции и механизмы для сбора и экспорта метрик.
 * Не указывает и не требует настройки языка/системы (например, Jsonnet). Он предоставляет декларативный API, который может быть нацелен на произвольные формы декларативных спецификаций.
 * Не предоставляет и не принимает никаких комплексных систем конфигурации, технического обслуживания, управления или самовосстановления.
-* Кроме того, Kubernetes — это не просто система оркестрации. Фактически, Kubernetes устраняет необходимость в этом. Техническое определение оркестрации — это выполнение определенного рабочего процесса: сначала сделай A, затем B, затем C. Напротив, Kubernetes содержит набор независимых, компонуемых процессов управления, которые непрерывно переводит текущее состояние к предполагаемому состоянию. Неважно, как добраться от А до С. Не требуется также централизованный контроль. Это делает систему более простой в использовании, более мощной, надежной, устойчивой и расширяемой.
+* Кроме того, Kubernetes — это не просто система оркестрации. Фактически, Kubernetes устраняет необходимость в этом. Техническое определение оркестрации — это выполнение определенного рабочего процесса: сначала сделай A, затем B, затем C. Напротив, Kubernetes содержит набор независимых, компонуемых процессов управления, которые непрерывно переводят текущее состояние к предполагаемому состоянию. Неважно, как добраться от А до С. Не требуется также централизованный контроль. Это делает систему более простой в использовании, более мощной, надежной, устойчивой и расширяемой.
 
 
 
 
@@ -21,11 +21,11 @@ card:
 
 * Какие контейнеризированные приложения запущены (и на каких узлах).
 * Доступные ресурсы для этих приложений.
-* Стратегии управления приложения, которые относятся, например, к перезапуску, обновлению или отказоустойчивости.
+* Стратегии управления приложением, которые относятся, например, к перезапуску, обновлению или отказоустойчивости.
 
 После создания объекта Kubernetes будет следить за существованием объекта. Создавая объект, вы таким образом указываете системе Kubernetes, какой должна быть рабочая нагрузка кластера; это *требуемое состояние* кластера.
 
-Для работы с объектами Kubernetes – будь то создание, изменение или удаление — нужно использовать [API Kubernetes](/docs/concepts/overview/kubernetes-api/). Например, при использовании CLI-инструмента `kubectl`, он обращается к API Kubernetes. С помощью одной из [клиентской библиотеки](/docs/reference/using-api/client-libraries/) вы также можете использовать API Kubernetes в собственных программах.
+Для работы с объектами Kubernetes – будь то создание, изменение или удаление — нужно использовать [API Kubernetes](/docs/concepts/overview/kubernetes-api/). Например, при использовании CLI-инструмента `kubectl`, он обращается к API Kubernetes. С помощью одной из [клиентских библиотек](/docs/reference/using-api/client-libraries/) вы также можете использовать API Kubernetes в собственных программах.
 
 ### Спецификация и статус объекта
 
@@ -34,7 +34,7 @@ card:
 
 Поле `status` описывает _текущее состояние_ объекта, которое создаётся и обновляется самим Kubernetes и его компонентами. {{< glossary_tooltip text="Управляющий слой" term_id="control-plane" >}} Kubernetes непрерывно управляет фактическим состоянием каждого объекта, чтобы оно соответствовало требуемому состоянию, которое было задано пользователем.
 
-Например: Deployment — это объект Kubernetes, представляющий работающее приложение в кластере. При создании объекта Deployment вы можете указать в его поле `spec`, что хотите иметь три реплики приложения. Система Kubernetes получит спецификацию объекта Deployment и запустит три экземпляра приложения, таким образом обновит статус (состояние) объекта, чтобы он соответствовал заданной спецификации. В случае сбоя одного из экземпляров (это влечет за собой изменение состояние), Kubernetes обнаружит несоответствие между спецификацией и статусом и исправит его, т.е. активирует новый экземпляр вместо того, который вышел из строя.
+Например: Deployment — это объект Kubernetes, представляющий работающее приложение в кластере. При создании объекта Deployment вы можете указать в его поле `spec`, что хотите иметь три реплики приложения. Система Kubernetes получит спецификацию объекта Deployment и запустит три экземпляра приложения, таким образом обновит статус (состояние) объекта, чтобы он соответствовал заданной спецификации. В случае сбоя одного из экземпляров (это влечет за собой изменение состояния), Kubernetes обнаружит несоответствие между спецификацией и статусом и исправит его, т.е. активирует новый экземпляр вместо того, который вышел из строя.
 
 Для получения дополнительной информации о спецификации объекта, статусе и метаданных смотрите документ с [соглашениями API Kubernetes](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md).