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,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>
|
||||
|
||||
Reference in New Issue
Block a user