Fix errors
* Fix home page name * Remove untranslated * Localize left panel in Getting Started * Fix left menu button on mobile and add redirect * Implement review suggestions Co-authored-by: Anastasiya Kulyk <nastya.kulyk@gmail.com> Co-authored-by: Maksym Vlasov <MaxymVlasov@users.noreply.github.com>
This commit is contained in:
MaxymVlasov
@@ -41,13 +41,13 @@ Before walking through each tutorial, you may want to bookmark the
|
||||
|
||||
* [Configuring Redis Using a ConfigMap](/docs/tutorials/configuration/configure-redis-using-configmap/)
|
||||
|
||||
## Застосунки без стану (Stateless Applications)
|
||||
## Застосунки без стану (Stateless Applications) {#застосунки-без-стану}
|
||||
|
||||
* [Exposing an External IP Address to Access an Application in a Cluster](/docs/tutorials/stateless-application/expose-external-ip-address/)
|
||||
|
||||
* [Example: Deploying PHP Guestbook application with Redis](/docs/tutorials/stateless-application/guestbook/)
|
||||
|
||||
## Застосунки зі станом (Stateful Applications)
|
||||
## Застосунки зі станом (Stateful Applications) {#застосунки-зі-станом}
|
||||
|
||||
* [StatefulSet Basics](/docs/tutorials/stateful-application/basic-stateful-set/)
|
||||
|
||||
|
||||
@@ -109,12 +109,12 @@ tutorial has only one Container. A Kubernetes
|
||||
Pod and restarts the Pod's Container if it terminates. Deployments are the
|
||||
recommended way to manage the creation and scaling of Pods.
|
||||
-->
|
||||
[*Под*](/docs/concepts/workloads/pods/pod/) у Kubernetes -- це група з одного або декількох контейнерів, що об'єднані разом з метою адміністрування і роботи у мережі. У цьому навчальному матеріалі Под має лише один контейнер. Kubernetes [*Deployment*](/docs/concepts/workloads/controllers/deployment/) перевіряє стан Пода і перезапускає контейнер Пода, якщо контейнер перестає працювати. Створювати і масштабувати Поди рекомендується за допомогою Deployment'ів.
|
||||
[*Pod*](/docs/concepts/workloads/pods/pod/) у Kubernetes -- це група з одного або декількох контейнерів, що об'єднані разом з метою адміністрування і роботи у мережі. У цьому навчальному матеріалі Pod має лише один контейнер. Kubernetes [*Deployment*](/docs/concepts/workloads/controllers/deployment/) перевіряє стан Pod'а і перезапускає контейнер Pod'а, якщо контейнер перестає працювати. Створювати і масштабувати Pod'и рекомендується за допомогою Deployment'ів.
|
||||
|
||||
<!--1. Use the `kubectl create` command to create a Deployment that manages a Pod. The
|
||||
Pod runs a Container based on the provided Docker image.
|
||||
-->
|
||||
1. За допомогою команди `kubectl create` створіть Deployment, який керуватиме Подом. Под запускає контейнер на основі наданого Docker образу.
|
||||
1. За допомогою команди `kubectl create` створіть Deployment, який керуватиме Pod'ом. Pod запускає контейнер на основі наданого Docker образу.
|
||||
|
||||
```shell
|
||||
kubectl create deployment hello-node --image=gcr.io/hello-minikube-zero-install/hello-node
|
||||
@@ -139,7 +139,7 @@ Pod runs a Container based on the provided Docker image.
|
||||
|
||||
<!--3. View the Pod:
|
||||
-->
|
||||
3. Перегляньте інформацію про запущені Поди:
|
||||
3. Перегляньте інформацію про запущені Pod'и:
|
||||
|
||||
```shell
|
||||
kubectl get pods
|
||||
@@ -176,18 +176,18 @@ Pod runs a Container based on the provided Docker image.
|
||||
|
||||
<!--## Create a Service
|
||||
-->
|
||||
## Створення Сервісу
|
||||
## Створення Service
|
||||
|
||||
<!--By default, the Pod is only accessible by its internal IP address within the
|
||||
Kubernetes cluster. To make the `hello-node` Container accessible from outside the
|
||||
Kubernetes virtual network, you have to expose the Pod as a
|
||||
Kubernetes [*Service*](/docs/concepts/services-networking/service/).
|
||||
-->
|
||||
За умовчанням, Под доступний лише за внутрішньою IP-адресою у межах Kubernetes кластера. Для того, щоб контейнер `hello-node` став доступний за межами віртуальної мережі Kubernetes, Под необхідно відкрити як Kubernetes [*Сервіс*](/docs/concepts/services-networking/service/).
|
||||
За умовчанням, Pod доступний лише за внутрішньою IP-адресою у межах Kubernetes кластера. Для того, щоб контейнер `hello-node` став доступний за межами віртуальної мережі Kubernetes, Pod необхідно відкрити як Kubernetes [*Service*](/docs/concepts/services-networking/service/).
|
||||
|
||||
<!--1. Expose the Pod to the public internet using the `kubectl expose` command:
|
||||
-->
|
||||
1. Відкрийте Под для публічного доступу з інтернету за допомогою команди `kubectl expose`:
|
||||
1. Відкрийте Pod для публічного доступу з інтернету за допомогою команди `kubectl expose`:
|
||||
|
||||
```shell
|
||||
kubectl expose deployment hello-node --type=LoadBalancer --port=8080
|
||||
@@ -196,11 +196,11 @@ Kubernetes [*Service*](/docs/concepts/services-networking/service/).
|
||||
<!--The `--type=LoadBalancer` flag indicates that you want to expose your Service
|
||||
outside of the cluster.
|
||||
-->
|
||||
Прапорець `--type=LoadBalancer` вказує, що ви хочете відкрити доступ до Сервісу за межами кластера.
|
||||
Прапорець `--type=LoadBalancer` вказує, що ви хочете відкрити доступ до Service за межами кластера.
|
||||
|
||||
<!--2. View the Service you just created:
|
||||
-->
|
||||
2. Перегляньте інформацію за Сервісом, який ви щойно створили:
|
||||
2. Перегляньте інформацію про Service, який ви щойно створили:
|
||||
|
||||
```shell
|
||||
kubectl get services
|
||||
@@ -221,7 +221,7 @@ Kubernetes [*Service*](/docs/concepts/services-networking/service/).
|
||||
the `LoadBalancer` type makes the Service accessible through the `minikube service`
|
||||
command.
|
||||
-->
|
||||
Для хмарних провайдерів, що підтримують балансування навантаження, доступ до Сервісу надається через зовнішню IP-адресу. Для Minikube, тип `LoadBalancer` робить Сервіс доступним ззовні за допомогою команди `minikube service`.
|
||||
Для хмарних провайдерів, що підтримують балансування навантаження, доступ до Service надається через зовнішню IP-адресу. Для Minikube, тип `LoadBalancer` робить Service доступним ззовні за допомогою команди `minikube service`.
|
||||
|
||||
<!--3. Run the following command:
|
||||
-->
|
||||
@@ -301,7 +301,7 @@ Minikube має ряд вбудованих {{< glossary_tooltip text="розш
|
||||
|
||||
<!--3. View the Pod and Service you just created:
|
||||
-->
|
||||
3. Перегляньте інформацію про Под і Сервіс, які ви щойно створили:
|
||||
3. Перегляньте інформацію про Pod і Service, які ви щойно створили:
|
||||
|
||||
```shell
|
||||
kubectl get pod,svc -n kube-system
|
||||
@@ -389,6 +389,6 @@ minikube delete
|
||||
* Дізнайтеся більше про [розгортання застосунків](/docs/user-guide/deploying-applications/).
|
||||
<!--* Learn more about [Service objects](/docs/concepts/services-networking/service/).
|
||||
-->
|
||||
* Дізнайтеся більше про [об'єкти сервісу](/docs/concepts/services-networking/service/).
|
||||
* Дізнайтеся більше про [об'єкти Service](/docs/concepts/services-networking/service/).
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
@@ -43,16 +43,16 @@ weight: 10
|
||||
</p>
|
||||
-->
|
||||
<p>
|
||||
Після того, як ви запустили Kubernetes кластер, ви можете розгортати в ньому контейнеризовані застосунки. Для цього вам необхідно створити <b>Deployment</b> конфігурацію. Вона інформує Kubernetes, як створювати і оновлювати Поди для вашого застосунку. Після того, як ви створили Deployment, Kubernetes master розподіляє ці Поди по окремих вузлах кластера.
|
||||
Після того, як ви запустили Kubernetes кластер, ви можете розгортати в ньому контейнеризовані застосунки. Для цього вам необхідно створити <b>Deployment</b> конфігурацію. Вона інформує Kubernetes, як створювати і оновлювати Pod'и для вашого застосунку. Після того, як ви створили Deployment, Kubernetes master розподіляє ці Pod'и по окремих вузлах кластера.
|
||||
</p>
|
||||
|
||||
<!--<p>Once the application instances are created, a Kubernetes Deployment Controller continuously monitors those instances. If the Node hosting an instance goes down or is deleted, the Deployment controller replaces the instance with an instance on another Node in the cluster. <b>This provides a self-healing mechanism to address machine failure or maintenance.</b></p>
|
||||
-->
|
||||
<p>Після створення Поди застосунку безперервно моніторяться контролером Kubernetes Deployment. Якщо вузол, на якому розміщено Под, зупинив роботу або був видалений, Deployment контролер переміщає цей Под на інший вузол кластера. <b>Так працює механізм самозцілення, що підтримує робочий стан кластера у разі апаратного збою чи технічних робіт.</b></p>
|
||||
<p>Після створення Pod'и застосунку безперервно моніторяться контролером Kubernetes Deployment. Якщо вузол, на якому розміщено Pod, зупинив роботу або був видалений, Deployment контролер переміщає цей Pod на інший вузол кластера. <b>Так працює механізм самозцілення, що підтримує робочий стан кластера у разі апаратного збою чи технічних робіт.</b></p>
|
||||
|
||||
<!--<p>In a pre-orchestration world, installation scripts would often be used to start applications, but they did not allow recovery from machine failure. By both creating your application instances and keeping them running across Nodes, Kubernetes Deployments provide a fundamentally different approach to application management. </p>
|
||||
-->
|
||||
<p>До появи оркестрації застосунки часто запускали за допомогою скриптів установлення. Однак скрипти не давали можливості відновити працездатний стан застосунку після апаратного збою. Завдяки створенню Подів та їхньому запуску на вузлах кластера, Kubernetes Deployment надає цілковито інший підхід до управління застосунками. </p>
|
||||
<p>До появи оркестрації застосунки часто запускали за допомогою скриптів установлення. Однак скрипти не давали можливості відновити працездатний стан застосунку після апаратного збою. Завдяки створенню Pod'ів та їхньому запуску на вузлах кластера, Kubernetes Deployment надає цілковито інший підхід до управління застосунками. </p>
|
||||
|
||||
</div>
|
||||
|
||||
@@ -74,7 +74,7 @@ weight: 10
|
||||
</i></p>
|
||||
-->
|
||||
<p><i>
|
||||
Deployment відповідає за створення і оновлення Подів для вашого застосунку
|
||||
Deployment відповідає за створення і оновлення Pod'ів для вашого застосунку
|
||||
</i></p>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: Ознайомлення з Подами і вузлами (nodes)
|
||||
title: Ознайомлення з Pod'ами і вузлами (nodes)
|
||||
weight: 10
|
||||
---
|
||||
|
||||
@@ -25,7 +25,7 @@ weight: 10
|
||||
<ul>
|
||||
<!--<li>Learn about Kubernetes Pods.</li>
|
||||
-->
|
||||
<li>Дізнатися, що таке Поди Kubernetes.</li>
|
||||
<li>Дізнатися, що таке Pod'и Kubernetes.</li>
|
||||
<!--<li>Learn about Kubernetes Nodes.</li>
|
||||
-->
|
||||
<li>Дізнатися, що таке вузли Kubernetes.</li>
|
||||
@@ -38,35 +38,35 @@ weight: 10
|
||||
<div class="col-md-8">
|
||||
<!--<h2>Kubernetes Pods</h2>
|
||||
-->
|
||||
<h2>Поди Kubernetes</h2>
|
||||
<h2>Pod'и Kubernetes</h2>
|
||||
<!--<p>When you created a Deployment in Module <a href="/docs/tutorials/kubernetes-basics/deploy-intro/">2</a>, Kubernetes created a <b>Pod</b> to host your application instance. A Pod is a Kubernetes abstraction that represents a group of one or more application containers (such as Docker or rkt), and some shared resources for those containers. Those resources include:</p>
|
||||
-->
|
||||
<p>Коли ви створили Deployment у модулі <a href="/docs/tutorials/kubernetes-basics/deploy-intro/">2</a>, Kubernetes створив <b>Под</b>, щоб розмістити ваш застосунок. Под - це абстракція в Kubernetes, що являє собою групу з одного або декількох контейнерів застосунку (як Docker або rkt) і ресурси, спільні для цих контейнерів. До цих ресурсів належать:</p>
|
||||
<p>Коли ви створили Deployment у модулі <a href="/docs/tutorials/kubernetes-basics/deploy-intro/">2</a>, Kubernetes створив <b>Pod</b>, щоб розмістити ваш застосунок. Pod - це абстракція в Kubernetes, що являє собою групу з одного або декількох контейнерів застосунку (як Docker або rkt) і ресурси, спільні для цих контейнерів. До цих ресурсів належать:</p>
|
||||
<ul>
|
||||
<!--<li>Shared storage, as Volumes</li>
|
||||
-->
|
||||
<li>Спільні сховища даних, або Volumes</li>
|
||||
<!--<li>Networking, as a unique cluster IP address</li>
|
||||
-->
|
||||
<li>Мережа, адже кожен Под у кластері має унікальну IP-адресу</li>
|
||||
<li>Мережа, адже кожен Pod у кластері має унікальну IP-адресу</li>
|
||||
<!--<li>Information about how to run each container, such as the container image version or specific ports to use</li>
|
||||
-->
|
||||
<li>Інформація з запуску кожного контейнера, така як версія образу контейнера або використання певних портів</li>
|
||||
</ul>
|
||||
<!--<p>A Pod models an application-specific "logical host" and can contain different application containers which are relatively tightly coupled. For example, a Pod might include both the container with your Node.js app as well as a different container that feeds the data to be published by the Node.js webserver. The containers in a Pod share an IP Address and port space, are always co-located and co-scheduled, and run in a shared context on the same Node.</p>
|
||||
-->
|
||||
<p>Под моделює специфічний для даного застосунку "логічний хост" і може містити різні, але доволі щільно зв'язані контейнери. Наприклад, в одному Поді може бути контейнер з вашим Node.js застосунком та інший контейнер, що передає дані для публікації Node.js вебсерверу. Контейнери в межах Пода мають спільну IP-адресу і порти, завжди є сполученими, плануються для запуску разом і запускаються у спільному контексті на одному вузлі.</p>
|
||||
<p>Pod моделює специфічний для даного застосунку "логічний хост" і може містити різні, але доволі щільно зв'язані контейнери. Наприклад, в одному Pod'і може бути контейнер з вашим Node.js застосунком та інший контейнер, що передає дані для публікації Node.js вебсерверу. Контейнери в межах Pod'а мають спільну IP-адресу і порти, завжди є сполученими, плануються для запуску разом і запускаються у спільному контексті на одному вузлі.</p>
|
||||
|
||||
<!--<p>Pods are the atomic unit on the Kubernetes platform. When we create a Deployment on Kubernetes, that Deployment creates Pods with containers inside them (as opposed to creating containers directly). Each Pod is tied to the Node where it is scheduled, and remains there until termination (according to restart policy) or deletion. In case of a Node failure, identical Pods are scheduled on other available Nodes in the cluster.</p>
|
||||
-->
|
||||
<p>Под є неподільною одиницею платформи Kubernetes. Коли ви створюєте Deployment у Kubernetes, цей Deployment створює Поди вже з контейнерами всередині, на відміну від створення контейнерів окремо. Кожен Под прив'язаний до вузла, до якого його було розподілено, і лишається на ньому до припинення роботи (згідно з політикою перезапуску) або видалення. У разі відмови вузла ідентичні Поди розподіляються по інших доступних вузлах кластера.</p>
|
||||
<p>Pod є неподільною одиницею платформи Kubernetes. Коли ви створюєте Deployment у Kubernetes, цей Deployment створює Pod'и вже з контейнерами всередині, на відміну від створення контейнерів окремо. Кожен Pod прив'язаний до вузла, до якого його було розподілено, і лишається на ньому до припинення роботи (згідно з політикою перезапуску) або видалення. У разі відмови вузла ідентичні Pod'и розподіляються по інших доступних вузлах кластера.</p>
|
||||
|
||||
</div>
|
||||
<div class="col-md-4">
|
||||
<div class="content__box content__box_lined">
|
||||
<h3>Зміст:</h3>
|
||||
<ul>
|
||||
<li>Поди</li>
|
||||
<li>Pod'и</li>
|
||||
<li>Вузли</li>
|
||||
<li>Основні команди kubectl</li>
|
||||
</ul>
|
||||
@@ -77,7 +77,7 @@ weight: 10
|
||||
</i></p>
|
||||
-->
|
||||
<p><i>
|
||||
Под - це група з одного або декількох контейнерів (таких як Docker або rkt), що має спільне сховище даних (volumes), унікальну IP-адресу і містить інформацію як їх запустити.
|
||||
Pod - це група з одного або декількох контейнерів (таких як Docker або rkt), що має спільне сховище даних (volumes), унікальну IP-адресу і містить інформацію як їх запустити.
|
||||
</i></p>
|
||||
</div>
|
||||
</div>
|
||||
@@ -86,7 +86,7 @@ weight: 10
|
||||
|
||||
<div class="row">
|
||||
<div class="col-md-8">
|
||||
<h2 style="color: #3771e3;">Узагальнена схема Подів</h2>
|
||||
<h2 style="color: #3771e3;">Узагальнена схема Pod'ів</h2>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
@@ -104,7 +104,7 @@ weight: 10
|
||||
<h2>Вузли</h2>
|
||||
<!--<p>A Pod always runs on a <b>Node</b>. A Node is a worker machine in Kubernetes and may be either a virtual or a physical machine, depending on the cluster. Each Node is managed by the Master. A Node can have multiple pods, and the Kubernetes master automatically handles scheduling the pods across the Nodes in the cluster. The Master's automatic scheduling takes into account the available resources on each Node.</p>
|
||||
-->
|
||||
<p>Под завжди запускається на <b>вузлі</b>. Вузол - це робоча машина в Kubernetes, віртуальна або фізична, в залежності від кластера. Функціонування кожного вузла контролюється master'ом. Вузол може мати декілька Подів. Kubernetes master автоматично розподіляє Поди по вузлах кластера з урахуванням ресурсів, наявних на кожному вузлі.</p>
|
||||
<p>Pod завжди запускається на <b>вузлі</b>. Вузол - це робоча машина в Kubernetes, віртуальна або фізична, в залежності від кластера. Функціонування кожного вузла контролюється master'ом. Вузол може мати декілька Pod'ів. Kubernetes master автоматично розподіляє Pod'и по вузлах кластера з урахуванням ресурсів, наявних на кожному вузлі.</p>
|
||||
|
||||
<!--<p>Every Kubernetes Node runs at least:</p>
|
||||
-->
|
||||
@@ -112,7 +112,7 @@ weight: 10
|
||||
<ul>
|
||||
<!--<li>Kubelet, a process responsible for communication between the Kubernetes Master and the Node; it manages the Pods and the containers running on a machine.</li>
|
||||
-->
|
||||
<li>kubelet - процес, що забезпечує обмін даними між Kubernetes master і робочим вузлом; kubelet контролює Поди і контейнери, запущені на машині.</li>
|
||||
<li>kubelet - процес, що забезпечує обмін даними між Kubernetes master і робочим вузлом; kubelet контролює Pod'и і контейнери, запущені на машині.</li>
|
||||
<!--<li>A container runtime (like Docker, rkt) responsible for pulling the container image from a registry, unpacking the container, and running the application.</li>
|
||||
-->
|
||||
<li>оточення для контейнерів (таке як Docker, rkt), що забезпечує завантаження образу контейнера з реєстру, розпакування контейнера і запуск застосунку.</li>
|
||||
@@ -124,7 +124,7 @@ weight: 10
|
||||
<div class="content__box content__box_fill">
|
||||
<!--<p><i> Containers should only be scheduled together in a single Pod if they are tightly coupled and need to share resources such as disk. </i></p>
|
||||
-->
|
||||
<p><i> Контейнери повинні бути разом в одному Поді, лише якщо вони щільно зв'язані і мають спільні ресурси, такі як диск. </i></p>
|
||||
<p><i> Контейнери повинні бути разом в одному Pod'і, лише якщо вони щільно зв'язані і мають спільні ресурси, такі як диск. </i></p>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
@@ -161,10 +161,10 @@ weight: 10
|
||||
<li><b>kubectl describe</b> - показати детальну інформацію про ресурс</li>
|
||||
<!--<li><b>kubectl logs</b> - print the logs from a container in a pod</li>
|
||||
-->
|
||||
<li><b>kubectl logs</b> - вивести логи контейнера, розміщеного в Поді</li>
|
||||
<li><b>kubectl logs</b> - вивести логи контейнера, розміщеного в Pod'і</li>
|
||||
<!--<li><b>kubectl exec</b> - execute a command on a container in a pod</li>
|
||||
-->
|
||||
<li><b>kubectl exec</b> - виконати команду в контейнері, розміщеному в Поді</li>
|
||||
<li><b>kubectl exec</b> - виконати команду в контейнері, розміщеному в Pod'і</li>
|
||||
</ul>
|
||||
|
||||
<!--<p>You can use these commands to see when applications were deployed, what their current statuses are, where they are running and what their configurations are.</p>
|
||||
@@ -180,7 +180,7 @@ weight: 10
|
||||
<div class="content__box content__box_fill">
|
||||
<!--<p><i> A node is a worker machine in Kubernetes and may be a VM or physical machine, depending on the cluster. Multiple Pods can run on one Node. </i></p>
|
||||
-->
|
||||
<p><i> Вузол - це робоча машина в Kubernetes, віртуальна або фізична, в залежності від кластера. На одному вузлі можуть бути запущені декілька Подів. </i></p>
|
||||
<p><i> Вузол - це робоча машина в Kubernetes, віртуальна або фізична, в залежності від кластера. На одному вузлі можуть бути запущені декілька Pod'ів. </i></p>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
@@ -41,35 +41,35 @@ weight: 10
|
||||
|
||||
<!--<p>Kubernetes <a href="/docs/concepts/workloads/pods/pod-overview/">Pods</a> are mortal. Pods in fact have a <a href="/docs/concepts/workloads/pods/pod-lifecycle/">lifecycle</a>. When a worker node dies, the Pods running on the Node are also lost. A <a href="/docs/concepts/workloads/controllers/replicaset/">ReplicaSet</a> might then dynamically drive the cluster back to desired state via creation of new Pods to keep your application running. As another example, consider an image-processing backend with 3 replicas. Those replicas are exchangeable; the front-end system should not care about backend replicas or even if a Pod is lost and recreated. That said, each Pod in a Kubernetes cluster has a unique IP address, even Pods on the same Node, so there needs to be a way of automatically reconciling changes among Pods so that your applications continue to function.</p>
|
||||
-->
|
||||
<p><a href="/docs/concepts/workloads/pods/pod-overview/">Поди</a> Kubernetes "смертні" і мають власний <a href="/docs/concepts/workloads/pods/pod-lifecycle/">життєвий цикл</a>. Коли робочий вузол припиняє роботу, ми також втрачаємо всі Поди, запущені на ньому. <a href="/docs/concepts/workloads/controllers/replicaset/">ReplicaSet</a> здатна динамічно повернути кластер до бажаного стану шляхом створення нових Подів, забезпечуючи безперебійність роботи вашого застосунку. Як інший приклад, візьмемо бекенд застосунку для обробки зображень із трьома репліками. Ці репліки взаємозамінні; система фронтенду не повинна зважати на репліки бекенду чи на втрату та перестворення Поду. Водночас, кожний Под у Kubernetes кластері має унікальну IP-адресу, навіть Поди на одному вузлі. Відповідно, має бути спосіб автоматично синхронізувати зміни між Подами для того, щоб ваші застосунки продовжували працювати.</p>
|
||||
<p><a href="/docs/concepts/workloads/pods/pod-overview/">Pod'и</a> Kubernetes "смертні" і мають власний <a href="/docs/concepts/workloads/pods/pod-lifecycle/">життєвий цикл</a>. Коли робочий вузол припиняє роботу, ми також втрачаємо всі Pod'и, запущені на ньому. <a href="/docs/concepts/workloads/controllers/replicaset/">ReplicaSet</a> здатна динамічно повернути кластер до бажаного стану шляхом створення нових Pod'ів, забезпечуючи безперебійність роботи вашого застосунку. Як інший приклад, візьмемо бекенд застосунку для обробки зображень із трьома репліками. Ці репліки взаємозамінні; система фронтенду не повинна зважати на репліки бекенду чи на втрату та перестворення Pod'а. Водночас, кожний Pod у Kubernetes кластері має унікальну IP-адресу, навіть Pod'и на одному вузлі. Відповідно, має бути спосіб автоматично синхронізувати зміни між Pod'ами для того, щоб ваші застосунки продовжували працювати.</p>
|
||||
|
||||
<!--<p>A Service in Kubernetes is an abstraction which defines a logical set of Pods and a policy by which to access them. Services enable a loose coupling between dependent Pods. A Service is defined using YAML <a href="/docs/concepts/configuration/overview/#general-configuration-tips">(preferred)</a> or JSON, like all Kubernetes objects. The set of Pods targeted by a Service is usually determined by a <i>LabelSelector</i> (see below for why you might want a Service without including <code>selector</code> in the spec).</p>
|
||||
-->
|
||||
<p>Сервіс у Kubernetes - це абстракція, що визначає логічний набір Подів і політику доступу до них. Сервіси уможливлюють слабку зв'язаність між залежними Подами. Для визначення Сервісу використовують YAML-файл <a href="/docs/concepts/configuration/overview/#general-configuration-tips">(рекомендовано)</a> або JSON, як для решти об'єктів Kubernetes. Набір Подів, призначених для Сервісу, зазвичай визначається через <i>LabelSelector</i> (нижче пояснюється, чому параметр <code>selector</code> іноді не включають у специфікацію сервісу).</p>
|
||||
<p>Service у Kubernetes - це абстракція, що визначає логічний набір Pod'ів і політику доступу до них. Services уможливлюють слабку зв'язаність між залежними Pod'ами. Для визначення Service використовують YAML-файл <a href="/docs/concepts/configuration/overview/#general-configuration-tips">(рекомендовано)</a> або JSON, як для решти об'єктів Kubernetes. Набір Pod'ів, призначених для Service, зазвичай визначається через <i>LabelSelector</i> (нижче пояснюється, чому параметр <code>selector</code> іноді не включають у специфікацію Service).</p>
|
||||
|
||||
<!--<p>Although each Pod has a unique IP address, those IPs are not exposed outside the cluster without a Service. Services allow your applications to receive traffic. Services can be exposed in different ways by specifying a <code>type</code> in the ServiceSpec:</p>
|
||||
-->
|
||||
<p>Попри те, що кожен Под має унікальний IP, ці IP-адреси не видні за межами кластера без Сервісу. Сервіси уможливлюють надходження трафіка до ваших застосунків. Відкрити Сервіс можна по-різному, вказавши потрібний <code>type</code> у ServiceSpec:</p>
|
||||
<p>Попри те, що кожен Pod має унікальний IP, ці IP-адреси не видні за межами кластера без Service. Services уможливлюють надходження трафіка до ваших застосунків. Відкрити Service можна по-різному, вказавши потрібний <code>type</code> у ServiceSpec:</p>
|
||||
<ul>
|
||||
<!--<li><i>ClusterIP</i> (default) - Exposes the Service on an internal IP in the cluster. This type makes the Service only reachable from within the cluster.</li>
|
||||
-->
|
||||
<li><i>ClusterIP</i> (типове налаштування) - відкриває доступ до Сервісу у кластері за внутрішнім IP. Цей тип робить Сервіс доступним лише у межах кластера.</li>
|
||||
<li><i>ClusterIP</i> (типове налаштування) - відкриває доступ до Service у кластері за внутрішнім IP. Цей тип робить Service доступним лише у межах кластера.</li>
|
||||
<!--<li><i>NodePort</i> - Exposes the Service on the same port of each selected Node in the cluster using NAT. Makes a Service accessible from outside the cluster using <code><NodeIP>:<NodePort></code>. Superset of ClusterIP.</li>
|
||||
-->
|
||||
<li><i>NodePort</i> - відкриває доступ до Сервісу на однаковому порту кожного обраного вузла в кластері, використовуючи NAT. Робить Сервіс доступним поза межами кластера, використовуючи <code><NodeIP>:<NodePort></code>. Є надмножиною відносно ClusterIP.</li>
|
||||
<li><i>NodePort</i> - відкриває доступ до Service на однаковому порту кожного обраного вузла в кластері, використовуючи NAT. Робить Service доступним поза межами кластера, використовуючи <code><NodeIP>:<NodePort></code>. Є надмножиною відносно ClusterIP.</li>
|
||||
<!--<li><i>LoadBalancer</i> - Creates an external load balancer in the current cloud (if supported) and assigns a fixed, external IP to the Service. Superset of NodePort.</li>
|
||||
-->
|
||||
<li><i>LoadBalancer</i> - створює зовнішній балансувальник навантаження у хмарі (за умови хмарної інфраструктури) і призначає Сервісу статичну зовнішню IP-адресу. Є надмножиною відносно NodePort.</li>
|
||||
<li><i>LoadBalancer</i> - створює зовнішній балансувальник навантаження у хмарі (за умови хмарної інфраструктури) і призначає Service статичну зовнішню IP-адресу. Є надмножиною відносно NodePort.</li>
|
||||
<!--<li><i>ExternalName</i> - Exposes the Service using an arbitrary name (specified by <code>externalName</code> in the spec) by returning a CNAME record with the name. No proxy is used. This type requires v1.7 or higher of <code>kube-dns</code>.</li>
|
||||
-->
|
||||
<li><i>ExternalName</i> - відкриває доступ до Сервісу, використовуючи довільне ім'я (визначається параметром <code>externalName</code> у специфікації), повертає запис CNAME. Проксі не використовується. Цей тип потребує версії <code>kube-dns</code> 1.7 і вище.</li>
|
||||
<li><i>ExternalName</i> - відкриває доступ до Service, використовуючи довільне ім'я (визначається параметром <code>externalName</code> у специфікації), повертає запис CNAME. Проксі не використовується. Цей тип потребує версії <code>kube-dns</code> 1.7 і вище.</li>
|
||||
</ul>
|
||||
<!--<p>More information about the different types of Services can be found in the <a href="/docs/tutorials/services/source-ip/">Using Source IP</a> tutorial. Also see <a href="/docs/concepts/services-networking/connect-applications-service">Connecting Applications with Services</a>.</p>
|
||||
-->
|
||||
<p>Більше інформації про різні типи Сервісів ви знайдете у навчальному матеріалі <a href="/docs/tutorials/services/source-ip/">Використання вихідної IP-адреси</a>. Дивіться також <a href="/docs/concepts/services-networking/connect-applications-service">Поєднання застосунків з Сервісами</a>.</p>
|
||||
<p>Більше інформації про різні типи Services ви знайдете у навчальному матеріалі <a href="/docs/tutorials/services/source-ip/">Використання вихідної IP-адреси</a>. Дивіться також <a href="/docs/concepts/services-networking/connect-applications-service">Поєднання застосунків з Services</a>.</p>
|
||||
<!--<p>Additionally, note that there are some use cases with Services that involve not defining <code>selector</code> in the spec. A Service created without <code>selector</code> will also not create the corresponding Endpoints object. This allows users to manually map a Service to specific endpoints. Another possibility why there may be no selector is you are strictly using <code>type: ExternalName</code>.</p>
|
||||
-->
|
||||
<p>Також зауважте, що для деяких сценаріїв використання Сервісів параметр <code>selector</code> не задається у специфікації Сервісу. Сервіс, створений без визначення параметра <code>selector</code>, також не створюватиме відповідного Endpoint об'єкта. Це дозволяє користувачам вручну спроектувати Сервіс на конкретні кінцеві точки (endpoints). Інший випадок, коли селектор може бути не потрібний - використання строго заданого параметра <code>type: ExternalName</code>.</p>
|
||||
<p>Також зауважте, що для деяких сценаріїв використання Services параметр <code>selector</code> не задається у специфікації Service. Service, створений без визначення параметра <code>selector</code>, також не створюватиме відповідного Endpoint об'єкта. Це дозволяє користувачам вручну спроектувати Service на конкретні кінцеві точки (endpoints). Інший випадок, коли Селектор може бути не потрібний - використання строго заданого параметра <code>type: ExternalName</code>.</p>
|
||||
</div>
|
||||
<div class="col-md-4">
|
||||
<div class="content__box content__box_lined">
|
||||
@@ -79,10 +79,10 @@ weight: 10
|
||||
<ul>
|
||||
<!--<li>Exposing Pods to external traffic</li>
|
||||
-->
|
||||
<li>Відкриття Подів для зовнішнього трафіка</li>
|
||||
<li>Відкриття Pod'ів для зовнішнього трафіка</li>
|
||||
<!--<li>Load balancing traffic across multiple Pods</li>
|
||||
-->
|
||||
<li>Балансування навантаження трафіка між Подами</li>
|
||||
<li>Балансування навантаження трафіка між Pod'ами</li>
|
||||
<!--<li>Using labels</li>
|
||||
-->
|
||||
<li>Використання міток</li>
|
||||
@@ -91,7 +91,7 @@ weight: 10
|
||||
<div class="content__box content__box_fill">
|
||||
<!--<p><i>A Kubernetes Service is an abstraction layer which defines a logical set of Pods and enables external traffic exposure, load balancing and service discovery for those Pods.</i></p>
|
||||
-->
|
||||
<p><i>Сервіс Kubernetes - це шар абстракції, який визначає логічний набір Подів і відкриває їх для зовнішнього трафіка, балансує навантаження і здійснює виявлення цих Подів.</i></p>
|
||||
<p><i>Service Kubernetes - це шар абстракції, який визначає логічний набір Pod'ів і відкриває їх для зовнішнього трафіка, балансує навантаження і здійснює виявлення цих Pod'ів.</i></p>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
@@ -101,7 +101,7 @@ weight: 10
|
||||
<div class="col-md-8">
|
||||
<!--<h3>Services and Labels</h3>
|
||||
-->
|
||||
<h3>Сервіси і мітки</h3>
|
||||
<h3>Services і мітки</h3>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
@@ -115,10 +115,10 @@ weight: 10
|
||||
<div class="col-md-8">
|
||||
<!--<p>A Service routes traffic across a set of Pods. Services are the abstraction that allow pods to die and replicate in Kubernetes without impacting your application. Discovery and routing among dependent Pods (such as the frontend and backend components in an application) is handled by Kubernetes Services.</p>
|
||||
-->
|
||||
<p>Сервіс маршрутизує трафік між Подами, що входять до його складу. Сервіс - це абстракція, завдяки якій Поди в Kubernetes "вмирають" і відтворюються, не впливаючи на роботу вашого застосунку. Сервіси в Kubernetes здійснюють виявлення і маршрутизацію між залежними Подами (як наприклад, фронтенд- і бекенд-компоненти застосунку).</p>
|
||||
<p>Service маршрутизує трафік між Pod'ами, що входять до його складу. Service - це абстракція, завдяки якій Pod'и в Kubernetes "вмирають" і відтворюються, не впливаючи на роботу вашого застосунку. Services в Kubernetes здійснюють виявлення і маршрутизацію між залежними Pod'ами (як наприклад, фронтенд- і бекенд-компоненти застосунку).</p>
|
||||
<!--<p>Services match a set of Pods using <a href="/docs/concepts/overview/working-with-objects/labels">labels and selectors</a>, a grouping primitive that allows logical operation on objects in Kubernetes. Labels are key/value pairs attached to objects and can be used in any number of ways:</p>
|
||||
-->
|
||||
<p>Сервіси співвідносяться з набором Подів за допомогою <a href="/docs/concepts/overview/working-with-objects/labels">міток і селекторів</a> -- примітивів групування, що роблять можливими логічні операції з об'єктами у Kubernetes. Мітки являють собою пари ключ/значення, що прикріплені до об'єктів і можуть використовуватися для різних цілей:</p>
|
||||
<p>Services співвідносяться з набором Pod'ів за допомогою <a href="/docs/concepts/overview/working-with-objects/labels">міток і Селекторів</a> -- примітивів групування, що роблять можливими логічні операції з об'єктами у Kubernetes. Мітки являють собою пари ключ/значення, що прикріплені до об'єктів і можуть використовуватися для різних цілей:</p>
|
||||
<ul>
|
||||
<!--<li>Designate objects for development, test, and production</li>
|
||||
-->
|
||||
@@ -136,7 +136,7 @@ weight: 10
|
||||
<div class="content__box content__box_fill">
|
||||
<!--<p><i>You can create a Service at the same time you create a Deployment by using<br><code>--expose</code> in kubectl.</i></p>
|
||||
-->
|
||||
<p><i>Ви можете створити Сервіс одночасно із Deployment, виконавши команду <br><code>--expose</code> в kubectl.</i></p>
|
||||
<p><i>Ви можете створити Service одночасно із Deployment, виконавши команду <br><code>--expose</code> в kubectl.</i></p>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
@@ -153,7 +153,7 @@ weight: 10
|
||||
<div class="col-md-8">
|
||||
<!--<p>Labels can be attached to objects at creation time or later on. They can be modified at any time. Let's expose our application now using a Service and apply some labels.</p>
|
||||
-->
|
||||
<p>Мітки можна прикріпити до об'єктів під час створення або пізніше. Їх можна змінити у будь-який час. А зараз давайте відкриємо наш застосунок за допомогою Сервісу і прикріпимо мітки.</p>
|
||||
<p>Мітки можна прикріпити до об'єктів під час створення або пізніше. Їх можна змінити у будь-який час. А зараз давайте відкриємо наш застосунок за допомогою Service і прикріпимо мітки.</p>
|
||||
</div>
|
||||
</div>
|
||||
<br>
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: Запуск вашого застосунку на декількох Подах
|
||||
title: Запуск вашого застосунку на декількох Pod'ах
|
||||
weight: 10
|
||||
---
|
||||
|
||||
@@ -35,7 +35,7 @@ weight: 10
|
||||
|
||||
<!--<p>In the previous modules we created a <a href="/docs/concepts/workloads/controllers/deployment/">Deployment</a>, and then exposed it publicly via a <a href="/docs/concepts/services-networking/service/">Service</a>. The Deployment created only one Pod for running our application. When traffic increases, we will need to scale the application to keep up with user demand.</p>
|
||||
-->
|
||||
<p>У попередніх модулях ми створили <a href="/docs/concepts/workloads/controllers/deployment/">Deployment</a> і відкрили його для зовнішнього трафіка за допомогою <a href="/docs/concepts/services-networking/service/">Сервісу</a>. Deployment створив лише один Под для запуску нашого застосунку. Коли трафік збільшиться, нам доведеться масштабувати застосунок, аби задовольнити вимоги користувачів.</p>
|
||||
<p>У попередніх модулях ми створили <a href="/docs/concepts/workloads/controllers/deployment/">Deployment</a> і відкрили його для зовнішнього трафіка за допомогою <a href="/docs/concepts/services-networking/service/">Service</a>. Deployment створив лише один Pod для запуску нашого застосунку. Коли трафік збільшиться, нам доведеться масштабувати застосунок, аби задовольнити вимоги користувачів.</p>
|
||||
|
||||
<!--<p><b>Scaling</b> is accomplished by changing the number of replicas in a Deployment</p>
|
||||
-->
|
||||
@@ -56,7 +56,7 @@ weight: 10
|
||||
<div class="content__box content__box_fill">
|
||||
<!--<p><i> You can create from the start a Deployment with multiple instances using the --replicas parameter for the kubectl run command </i></p>
|
||||
-->
|
||||
<p><i> Кількість Подів можна вказати одразу при створенні Deployment'а за допомогою параметра --replicas, під час запуску команди kubectl run </i></p>
|
||||
<p><i> Кількість Pod'ів можна вказати одразу при створенні Deployment'а за допомогою параметра --replicas, під час запуску команди kubectl run </i></p>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
@@ -104,11 +104,11 @@ weight: 10
|
||||
|
||||
<!--<p>Scaling out a Deployment will ensure new Pods are created and scheduled to Nodes with available resources. Scaling will increase the number of Pods to the new desired state. Kubernetes also supports <a href="/docs/user-guide/horizontal-pod-autoscaling/">autoscaling</a> of Pods, but it is outside of the scope of this tutorial. Scaling to zero is also possible, and it will terminate all Pods of the specified Deployment.</p>
|
||||
-->
|
||||
<p>Масштабування Deployment'а забезпечує створення нових Подів і їх розподілення по вузлах з доступними ресурсами. Масштабування збільшить кількість Подів відповідно до нового бажаного стану. Kubernetes також підтримує <a href="/docs/user-guide/horizontal-pod-autoscaling/">автоматичне масштабування</a>, однак це виходить за межі даного матеріалу. Масштабування до нуля також можливе - це призведе до видалення всіх Подів у визначеному Deployment'і.</p>
|
||||
<p>Масштабування Deployment'а забезпечує створення нових Pod'ів і їх розподілення по вузлах з доступними ресурсами. Масштабування збільшить кількість Pod'ів відповідно до нового бажаного стану. Kubernetes також підтримує <a href="/docs/user-guide/horizontal-pod-autoscaling/">автоматичне масштабування</a>, однак це виходить за межі даного матеріалу. Масштабування до нуля також можливе - це призведе до видалення всіх Pod'ів у визначеному Deployment'і.</p>
|
||||
|
||||
<!--<p>Running multiple instances of an application will require a way to distribute the traffic to all of them. Services have an integrated load-balancer that will distribute network traffic to all Pods of an exposed Deployment. Services will monitor continuously the running Pods using endpoints, to ensure the traffic is sent only to available Pods.</p>
|
||||
-->
|
||||
<p>Запустивши застосунок на декількох Подах, необхідно розподілити між ними трафік. Сервіси мають інтегрований балансувальник навантаження, що розподіляє мережевий трафік між усіма Подами відкритого Deployment'а. Сервіси безперервно моніторять запущені Поди за допомогою кінцевих точок, для того щоб забезпечити надходження трафіка лише на доступні Поди.</p>
|
||||
<p>Запустивши застосунок на декількох Pod'ах, необхідно розподілити між ними трафік. Services мають інтегрований балансувальник навантаження, що розподіляє мережевий трафік між усіма Pod'ами відкритого Deployment'а. Services безперервно моніторять запущені Pod'и за допомогою кінцевих точок, для того щоб забезпечити надходження трафіка лише на доступні Pod'и.</p>
|
||||
|
||||
</div>
|
||||
<div class="col-md-4">
|
||||
|
||||
@@ -36,12 +36,12 @@ weight: 10
|
||||
|
||||
<!--<p>Users expect applications to be available all the time and developers are expected to deploy new versions of them several times a day. In Kubernetes this is done with rolling updates. <b>Rolling updates</b> allow Deployments' update to take place with zero downtime by incrementally updating Pods instances with new ones. The new Pods will be scheduled on Nodes with available resources.</p>
|
||||
-->
|
||||
<p>Користувачі очікують від застосунків високої доступності у будь-який час, а розробники - оновлення цих застосунків декілька разів на день. У Kubernetes це стає можливим завдяки послідовному оновленню. <b>Послідовні оновлення</b> дозволяють оновити Deployment без простою, шляхом послідовної заміни одних Подів іншими. Нові Поди розподіляються по вузлах з доступними ресурсами.</p>
|
||||
<p>Користувачі очікують від застосунків високої доступності у будь-який час, а розробники - оновлення цих застосунків декілька разів на день. У Kubernetes це стає можливим завдяки послідовному оновленню. <b>Послідовні оновлення</b> дозволяють оновити Deployment без простою, шляхом послідовної заміни одних Pod'ів іншими. Нові Pod'и розподіляються по вузлах з доступними ресурсами.</p>
|
||||
|
||||
<!--<p>In the previous module we scaled our application to run multiple instances. This is a requirement for performing updates without affecting application availability. By default, the maximum number of Pods that can be unavailable during the update and the maximum number of new Pods that can be created, is one. Both options can be configured to either numbers or percentages (of Pods).
|
||||
In Kubernetes, updates are versioned and any Deployment update can be reverted to a previous (stable) version.</p>
|
||||
-->
|
||||
<p>У попередньому модулі ми масштабували наш застосунок, запустивши його на декількох Подах. Масштабування - необхідна умова для проведення оновлень без шкоди для доступності застосунку. За типовими налаштуваннями, максимальна кількість Подів, недоступних під час оновлення, і максимальна кількість нових Подів, які можуть бути створені, дорівнює одиниці. Обидві опції можна налаштувати в числовому або відсотковому (від кількості Подів) еквіваленті.
|
||||
<p>У попередньому модулі ми масштабували наш застосунок, запустивши його на декількох Pod'ах. Масштабування - необхідна умова для проведення оновлень без шкоди для доступності застосунку. За типовими налаштуваннями, максимальна кількість Pod'ів, недоступних під час оновлення, і максимальна кількість нових Pod'ів, які можуть бути створені, дорівнює одиниці. Обидві опції можна налаштувати в числовому або відсотковому (від кількості Pod'ів) еквіваленті.
|
||||
У Kubernetes оновлення версіонуються, тому кожне оновлення Deployment'а можна відкотити до попередньої (стабільної) версії.</p>
|
||||
|
||||
</div>
|
||||
@@ -59,7 +59,7 @@ weight: 10
|
||||
<div class="content__box content__box_fill">
|
||||
<!--<p><i>Rolling updates allow Deployments' update to take place with zero downtime by incrementally updating Pods instances with new ones. </i></p>
|
||||
-->
|
||||
<p><i>Послідовне оновлення дозволяє оновити Deployment без простою шляхом послідовної заміни одних Подів іншими. </i></p>
|
||||
<p><i>Послідовне оновлення дозволяє оновити Deployment без простою шляхом послідовної заміни одних Pod'ів іншими. </i></p>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
@@ -115,7 +115,7 @@ weight: 10
|
||||
|
||||
<!--<p>Similar to application Scaling, if a Deployment is exposed publicly, the Service will load-balance the traffic only to available Pods during the update. An available Pod is an instance that is available to the users of the application.</p>
|
||||
-->
|
||||
<p>Як і у випадку з масштабуванням, якщо Deployment "відкритий у світ", то під час оновлення Сервіс розподілятиме трафік лише на доступні Поди. Під доступним мається на увазі Под, готовий до експлуатації користувачами застосунку.</p>
|
||||
<p>Як і у випадку з масштабуванням, якщо Deployment "відкритий у світ", то під час оновлення Service розподілятиме трафік лише на доступні Pod'и. Під доступним мається на увазі Pod, готовий до експлуатації користувачами застосунку.</p>
|
||||
|
||||
<!--<p>Rolling updates allow the following actions:</p>
|
||||
-->
|
||||
@@ -138,7 +138,7 @@ weight: 10
|
||||
<div class="content__box content__box_fill">
|
||||
<!--<p><i>If a Deployment is exposed publicly, the Service will load-balance the traffic only to available Pods during the update. </i></p>
|
||||
-->
|
||||
<p><i>Якщо Deployment "відкритий у світ", то під час оновлення сервіс розподілятиме трафік лише на доступні Поди. </i></p>
|
||||
<p><i>Якщо Deployment "відкритий у світ", то під час оновлення Service розподілятиме трафік лише на доступні Pod'и. </i></p>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
Reference in New Issue
Block a user