gc_typos

content/ru/docs/concepts/architecture/garbage-collection.md

@@ -23,7 +23,7 @@ weight: 50
 Многие объекты в Kubernetes ссылаются друг на друга через [*ссылки владельцев*](/docs/concepts/overview/working-with-objects/owners-dependents/). 
 Ссылки владельцев сообщают плоскости управления какие объекты зависят от других.
 Kubernetes использует ссылки владельцев, чтобы предоставить плоскости управления и другим API
-клиентам, возможность очистить связанные ресурсы передудалением объекта. В большинстве случаев, Kubernetes автоматический управляет ссылками владельцев.
+клиентам, возможность очистить связанные ресурсы перед удалением объекта. В большинстве случаев, Kubernetes автоматический управляет ссылками владельцев.
 
 Владелец отличается от [меток и селекторов](/docs/concepts/overview/working-with-objects/labels/)
 которые также используют некоторые ресурсы. Например, рассмотрим
@@ -36,15 +36,15 @@ Kubernetes использует ссылки владельцев, чтобы п
 {{< note >}}
 Ссылки на владельцев перекрестных пространств имен запрещены по дизайну.
 Зависимости пространства имен могут указывать на область действия кластера или владельцев пространства имен.
-Владелец пространства имен **должен** быть в том же пространстве имен что и зависимости.
+Владелец пространства имен **должен** быть в том же пространстве имен, что и зависимости.
-Если это не возможно, cсылка владельца считается отсутствующей и зависимый объект подлежит удалению, как только будет проверено отсутствие всех владельцев.
+Если это не возможно, ссылка владельца считается отсутствующей и зависимый объект подлежит удалению, как только будет проверено отсутствие всех владельцев.
 
 Зависимости области действия кластер может указывать только владельцев области действия кластера.
 В версии v1.20+, если зависимость с областью действия кластера указывает на пространство имен как владелец, 
 тогда он рассматривается как имеющий неразрешимую ссылку на владельца и не может быть обработан сборщиком мусора.
 
 В версии v1.20+, если сборщик мусора обнаружит недопустимое перекрестное пространство имен `ownerReference`,
-или зависящие от облости действия кластера `ownerReference` ссылка на тип пространства имен, предупреждающее событие с причиной `OwnerRefInvalidNamespace` и `involvedObject` сообщающеся о не действительной зависимости.
+или зависящие от области действия кластера `ownerReference` ссылка на тип пространства имен, предупреждающее событие с причиной `OwnerRefInvalidNamespace` и `involvedObject` сообщающее о недействительной зависимости.
 Вы можете проверить наличие такого рода событий, выполнив `kubectl get events -A --field-selector=reason=OwnerRefInvalidNamespace`.
 {{< /note >}}
 
@@ -52,22 +52,22 @@ Kubernetes использует ссылки владельцев, чтобы п
 
 Kubernetes проверяет и удаляет объекты, на которые больше нет ссылок владельцев, так же как и pod-ов, оставленных после удаления ReplicaSet. Когда Вы удаляете объект, вы можете контролировать автоматический ли Kubernetes удаляет зависимые объекты автоматически в процессе вызова *каскадного удаления*. Существует два типа каскадного удаления, а именно: 
 
-  * Каскадное удалени Foreground
+  * Каскадное удаление Foreground
   * Каскадное удаление Background
 
 Вы так же можете управлять как и когда сборщик мусора удаляет ресурсы, на которые ссылаются владельцы с помощью Kubernetes {{<glossary_tooltip text="finalizers" term_id="finalizer">}}. 
 
-### Каскадное удалени Foreground {#foreground-deletion}
+### Каскадное удаление Foreground {#foreground-deletion}
 
-В Каскадном удалени Foreground, объект владельца, который вы удаляете, сначало переходить в состояние *в процессе удаления*. В этом состоянии с объектом-владельцем происходить следующее: 
+В Каскадном удалении Foreground, объект владельца, который вы удаляете, сначала переходить в состояние *в процессе удаления*. В этом состоянии с объектом-владельцем происходить следующее: 
 
   * Сервер Kubernetes API устанавливает полю объекта `metadata.deletionTimestamp`
     время, когда объект был помечен для удаления.
   * Сервер Kubernetes API так же устанавливает метку  `metadata.finalizers`для поля
     `foregroundDeletion`. 
-  * Объект остается видимым блогодоря Kubernetes API пока процесс удаления не завершиться
+  * Объект остается видимым благодаря Kubernetes API пока процесс удаления не завершиться
 
-После того, как владелец объекта переходит в состояние прогресса удаления, контроллер удаляет зависимые объекты. После удаления всех зависимых объектов, контроллер удаляет объект владельца. На этом этапе, объект больше не отображается в Kubernetes API. 
+После того как владелец объекта переходит в состояние прогресса удаления, контроллер удаляет зависимые объекты. После удаления всех зависимых объектов, контроллер удаляет объект владельца. На этом этапе, объект больше не отображается в Kubernetes API. 
 
 Во время каскадного удаления foreground, единственным зависимым, которые блокируют удаления владельца, являются те, у кого имеется поле `ownerReference.blockOwnerDeletion=true`.
 Чтобы узнать больше. Смотрите [Использование каскадного удаления foreground](/docs/tasks/administer-cluster/use-cascading-deletion/#use-foreground-cascading-deletion).
@@ -80,16 +80,16 @@ Kubernetes проверяет и удаляет объекты, на котор
 
 ### Осиротевшие зависимости
 
-Когда Kubernetes удаляет владельца объекта, оставшиеся зависимости называются *осиротевшыми* объектами. По умолчанию, Kubernetes удаляет зависимые объекты. Чтобы узнать, как переопределить это повидение смотрите [Удаление объектов владельца и осиротевших зависимостей](/docs/tasks/administer-cluster/use-cascading-deletion/#set-orphan-deletion-policy).
+Когда Kubernetes удаляет владельца объекта, оставшиеся зависимости называются *осиротевшими* объектами. По умолчанию, Kubernetes удаляет зависимые объекты. Чтобы узнать, как переопределить это поведение смотрите [Удаление объектов владельца и осиротевших зависимостей](/docs/tasks/administer-cluster/use-cascading-deletion/#set-orphan-deletion-policy).
 
-## Сбор мусора из неиспользуемых контейнеров и изобробразов {#containers-images}
+## Сбор мусора из неиспользуемых контейнеров и изображений {#containers-images}
 
 {{<glossary_tooltip text="kubelet" term_id="kubelet">}} выполняет сбор мусора для неиспользуемых образов каждые пять минут и для неиспользуемых контейнеров каждую минуту. Вам следует избегать использования внешних инструментов для сборки мусора, так как они могут
 нарушить поведение kubelet и удалить контейнеры, которые должны существовать. 
 
-Чтобы настроить параметры для сборшика мусора для неиспользуемого контейнера и сборки мусора образа, подстройте 
+Чтобы настроить параметры для сборщика мусора для неиспользуемого контейнера и сборки мусора образа, подстройте 
 kubelet использую [конфигурационный файл](/docs/tasks/administer-cluster/kubelet-config-file/)
-и измените параметры, связанные со сборшиком мусора используя тип ресурса
+и измените параметры, связанные со сборщиком мусора используя тип ресурса
 [`KubeletConfiguration`](/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration).
 
 ### Жизненный цикл контейнерных образов Container image lifecycle
@@ -99,19 +99,19 @@ Kubernetes управляет жизненным циклом всех обра
   * `HighThresholdPercent`
   * `LowThresholdPercent`
 
-Использование диска выше настроенного значения `HighThresholdPercent` запускает сборку мусора, которая удаляет образы в порядке основанном на последнем использовании, начиная с самого старого. kubelet удлаяет образы до тех пор, пока использование диска не достигнет значения  `LowThresholdPercent`.
+Использование диска выше настроенного значения `HighThresholdPercent` запускает сборку мусора, которая удаляет образы в порядке основанном на последнем использовании, начиная с самого старого. Kubelet удаляет образы до тех пор, пока использование диска не достигнет значения  `LowThresholdPercent`.
 
 ### Сборщик мусора контейнерных образов {#container-image-garbage-collection}
 
-kubelet собирает не используемые контейнеры на основе следующих переменных, которые вы можете определить: 
+Kubelet собирает не используемые контейнеры на основе следующих переменных, которые вы можете определить: 
 
   * `MinAge`: минимальный возраст, при котором kubelet может начать собирать мусор контейнеров. Отключить, установив значение `0`.
-  * `MaxPerPodContainer`: максимальное количество некативныз контейнеров, которое может быть у каджой пары Pod-ов. Отключить, установив значение меньше чем `0`.
+  * `MaxPerPodContainer`: максимальное количество неактивных контейнеров, которое может быть у каждой пары Pod-ов. Отключить, установив значение меньше чем `0`.
   * `MaxContainers`: максимальное количество не используемых контейнеров, которые могут быть в кластере. Отключить, установив значение меньше чем `0`. 
 
 В дополнение к этим переменным, kubelet собирает неопознанные и удаленные контейнеры, обычно начиная с самого старого. 
 
-`MaxPerPodContainer` и `MaxContainer` могут потенциально конфликтовать друг с другом в ситуациях, когда требуется максимальное количество контейнеров в Pod-е (`MaxPerPodContainer`) выйдет за пределы допустимого общего количества глобальных не используемых контейнеров (`MaxContainers`). В этой ситуации kubelet регулирует `MaxPodPerContainer` для устранения конфликта. наихудшим сценарием было бы понизить `MaxPerPodContainer` да `1` и изгнать самые старые контейнеры.
+`MaxPerPodContainer` и `MaxContainer` могут потенциально конфликтовать друг с другом в ситуациях, когда требуется максимальное количество контейнеров в Pod-е (`MaxPerPodContainer`) выйдет за пределы допустимого общего количества глобальных не используемых контейнеров (`MaxContainers`). В этой ситуации kubelet регулирует `MaxPodPerContainer` для устранения конфликта. Наихудшим сценарием было бы понизить `MaxPerPodContainer` да `1` и изгнать самые старые контейнеры.
 Кроме того, владельцы контейнеров в pod-е могут быть удалены, как только они становятся старше чем `MinAge`.
 
 {{<note>}}
@@ -120,7 +120,7 @@ Kubelet собирает мусор только у контейнеров, ко
 
 ## Настройка сборщик мусора {#configuring-gc}
 
-Вы можете настроить сборку мусора ресурсов, настроив параметры, специфичные для контроллеров, управляющих этими ресурсами. В последующих страницах показанно, как настроить сборку мусора:
+Вы можете настроить сборку мусора ресурсов, настроив параметры, специфичные для контроллеров, управляющих этими ресурсами. В последующих страницах показано, как настроить сборку мусора:
 
   * [Настройка каскадного удаления объектов Kubernetes](/docs/tasks/administer-cluster/use-cascading-deletion/)
   * [Настройка очистки завершенных заданий](/docs/concepts/workloads/controllers/ttlafterfinished/)