chore(wordlist): fix spelling errors delete wrong words

Signed-off-by: Evgeniy Frolov <evgeniy.frolov@flant.com>

_includes/en/guides/300_deployment_practices/030_resource_management.md.liquid

@@ -56,7 +56,7 @@ Suppose you have deployed a new app version with some new functions and it turns
 
 And, of course, the relevant requests and limits had been set for the app before an update begins. And now the application reaches the memory limit, and its Pod gets killed due to OOM. VPA can prevent this! At first glance, **VPA looks like a great tool that should be used whenever and wherever possible. But in real life that isn’t always necessarily the case**, and you have to bear in mind the finer details involved.
 
-The main problem (it isn’t solved yet) is that the Pod needs to be restarted for resource changes to take effect. In the future, VPA will modify them without restarting the Pod, but for now, it simply isn’t capable of doing that. But no need to worry. That isn’t a big deal if you have a “well-written” application that is always ready for redeployment (say, it has a large number of replicas; its PodAntiAffinity, PodDistruptionBudget, HorizontalPodAutoscaler are carefully configured; etc.). In that case, you (probably) won’t even notice the VPA activity.
+The main problem (it isn’t solved yet) is that the Pod needs to be restarted for resource changes to take effect. In the future, VPA will modify them without restarting the Pod, but for now, it simply isn’t capable of doing that. But no need to worry. That isn’t a big deal if you have a “well-written” application that is always ready for redeployment (say, it has a large number of replicas; its PodAntiAffinity, PodDisruptionBudget, HorizontalPodAutoscaler are carefully configured; etc.). In that case, you (probably) won’t even notice the VPA activity.
 
 Sadly, there are other less pleasant scenarios that may occur like: the application not taking redeployment very well, the number of replicas being limited due to a lack of nodes, our application running as a StatefulSet, etc. In the worst-case scenario, the Pods’ resource consumption grows due to an increased load, HPA starts to scale up the cluster, and then, suddenly, VPA proceeds to modify the resource parameters and restarts the Pods. As a result, this high load gets distributed across the rest of the Pods. Some of them may crash, rendering things even worse and resulting in a chain reaction of failure.
 

_includes/ru/guides/200_real_apps/030_assets/java_springboot/015_expected_result.md.liquid

@@ -40,4 +40,4 @@ TEST SUITE: None
 Running time 9.47 seconds
 ```
 
-> Мы не стали приводить здесь полный вывод сборки, т.к Maven в процессе скачивания всех зависимостоей генерирует очень много текста.
+> Мы не стали приводить здесь полный вывод сборки, т.к Maven в процессе скачивания всех зависимостей генерирует очень много текста.

_includes/ru/guides/300_deployment_practices/030_resource_management.md.liquid

@@ -57,7 +57,7 @@ end
 
 Конечно, актуальные для приложения (до этого обновления) *requests* и *limits* уже были выставлены. И вот теперь приложение достигает лимита по памяти, приходит мистер ООМ и совершает над Pod’ом насильственные действия. VPA может это предотвратить! Если посмотреть на ситуацию в таком срезе, то, казалось бы, это замечательный инструмент, который надо использовать всегда и везде. Но в реальности, конечно, все не так просто и важно понимать сопутствующие нюансы.
 
-Основная проблема, которая на текущий момент не решена, это изменение ресурсов через *перезапуск* Pod’а. В каком-то ближайшем будущем VPA научится их патчить и без рестарта приложения, но сейчас не умеет. Допустим, это не страшно для хорошо написанного приложения, всегда готового к перекату: приложение разворачивается Deployment’ом с кучей реплик, настроенными `PodAntiAffinity`, `PodDistruptionBudget`, `HorizontalPodAutoscaler`… В таком случае, если VPA изменит ресурсы и аккуратно (по одному) перезапустит Pod’ы, мы это переживем.
+Основная проблема, которая на текущий момент не решена, это изменение ресурсов через *перезапуск* Pod’а. В каком-то ближайшем будущем VPA научится их патчить и без рестарта приложения, но сейчас не умеет. Допустим, это не страшно для хорошо написанного приложения, всегда готового к перекату: приложение разворачивается Deployment’ом с кучей реплик, настроенными `PodAntiAffinity`, `PodDisruptionBudget`, `HorizontalPodAutoscaler`… В таком случае, если VPA изменит ресурсы и аккуратно (по одному) перезапустит Pod’ы, мы это переживем.
 
 Но бывает всё не так гладко: приложение не очень хорошо переживает перезапуск, или мы ограничены в репликах по причине малого количества узлов, или у нас вообще StatefulSet…. В худшем сценарии придет нагрузка, у Pod’ов вырастет потребление ресурсов, HPA начал масштабировать, а тут VPA: «О! Надо бы поднять ресурсы!» — и начнет перезапускать Pod’ы. Нагрузка начнет перераспределяться по оставшимся, из-за чего Pod может просто упасть, нагрузка уйдет на еще живые и в результате произойдет каскадное падение.
 

scripts/docs/spelling/wordlist

@@ -164,7 +164,6 @@ plugin
 PNG
 PodAntiAffinity
 PodDisruptionBudget
-PodDistruptionBudget
 PostgreSQL
 PowerShell
 pre
@@ -331,7 +330,6 @@ YouTube
 реверт
 токена
 штатно
-менятьcя
 ассетов
 бандлов
 гуглить
@@ -457,7 +455,6 @@ YouTube
 сгенерирован
 трудозатраты
 гитерминизмом
-зависимостоей
 запустившемся
 иммутабельный
 микросервисов