Skip to content

Commit

Permalink
translate "version skew"
Browse files Browse the repository at this point in the history
#15903 (comment)

バージョン間の差異 となる
タイトルは原文どおりに用語として残し、初回の文でskew=差異であることを明示する
以降はskewを翻訳する
  • Loading branch information
af12066 committed Aug 24, 2019
1 parent c137da6 commit 422f5b0
Showing 1 changed file with 6 additions and 6 deletions.
12 changes: 6 additions & 6 deletions content/ja/docs/setup/release/version-skew-policy.md
Original file line number Diff line number Diff line change
Expand Up @@ -5,7 +5,7 @@ weight: 30
---

{{% capture overview %}}
このドキュメントでは、さまざまなKubernetesコンポーネント間でサポートされる最大のバージョンスキューについて説明します。特定のクラスターデプロイツールは、バージョンスキューに追加の制限を加える場合があります
このドキュメントでは、さまざまなKubernetesコンポーネント間でサポートされる最大のバージョンの差異(バージョンスキュー)について説明します。特定のクラスターデプロイツールは、バージョンの差異に追加の制限を加える場合があります
{{% /capture %}}

{{% capture body %}}
Expand Down Expand Up @@ -41,7 +41,7 @@ Kubernetesプロジェクトでは、最新の3つのマイナーリリースに
* `kubelet`**1.13****1.12**および**1.11**をサポートします

{{< note >}}
HAクラスター内の`kube-apiserver`間にバージョンスキューがある場合、有効な`kubelet`バージョンは少なくなります。
HAクラスター内の`kube-apiserver`間にバージョンの差異がある場合、有効な`kubelet`バージョンは少なくなります。
{{</ note >}}

例:
Expand All @@ -59,7 +59,7 @@ HAクラスター内の`kube-apiserver`間にバージョンスキューがあ
* `kube-controller-manager``kube-scheduler`および`cloud-controller-manager`**1.13**および**1.12**をサポートします

{{< note >}}
HAクラスター内の`kube-apiserver`間にバージョンスキューがあり、これらのコンポーネントがクラスター内のいずれかの`kube-apiserver`と通信する場合(たとえばロードバランサーを経由して)、コンポーネントの有効なバージョンは少なくなります。
HAクラスター内の`kube-apiserver`間にバージョンの差異があり、これらのコンポーネントがクラスター内のいずれかの`kube-apiserver`と通信する場合(たとえばロードバランサーを経由して)、コンポーネントの有効なバージョンは少なくなります。
{{< /note >}}

例:
Expand All @@ -77,7 +77,7 @@ HAクラスター内の`kube-apiserver`間にバージョンスキューがあ
* `kubectl`**1.14****1.13**および**1.12**をサポートします

{{< note >}}
HAクラスター内の`kube-apiserver`間にバージョンスキューがある場合、有効な`kubectl`バージョンは少なくなります。
HAクラスター内の`kube-apiserver`間にバージョンの差異がある場合、有効な`kubectl`バージョンは少なくなります。
{{< /note >}}

例:
Expand All @@ -87,14 +87,14 @@ HAクラスター内の`kube-apiserver`間にバージョンスキューがあ

## サポートされるコンポーネントのアップグレード順序

コンポーネント間のサポートされるバージョンスキューは、コンポーネントをアップグレードする順序に影響されます。このセクションでは、既存のクラスターをバージョン**1.n**から**1.(n+1)**へ移行するために、コンポーネントをアップグレードする順序を説明します。
コンポーネント間でサポートされるバージョンの差異は、コンポーネントをアップグレードする順序に影響されます。このセクションでは、既存のクラスターをバージョン**1.n**から**1.(n+1)**へ移行するために、コンポーネントをアップグレードする順序を説明します。

### kube-apiserver

前提条件:

* シングルインスタンスのクラスターにおいて、既存の`kube-apiserver`インスタンスは**1.n**とします
* HAクラスターにおいて、既存の`kube-apiserver`**1.n**または**1.(n+1)**とします(最新と最古の間で、最大で1つのマイナーバージョンのスキューとなります
* HAクラスターにおいて、既存の`kube-apiserver`**1.n**または**1.(n+1)**とします(最新と最古の間で、最大で1つのマイナーバージョンの差異となります
* サーバーと通信する`kube-controller-manager``kube-scheduler`および`cloud-controller-manager`はバージョン**1.n**とします(必ず既存のAPIサーバーのバージョンよりも新しいものでなく、かつ新しいAPIサーバーのバージョンの1つ以内のマイナーバージョンとなります)
* すべてのノードの`kubelet`インスタンスはバージョン**1.n**または**1.(n-1)**とします(必ず既存のAPIサーバーよりも新しいバージョンでなく、かつ新しいAPIサーバーのバージョンの2つ以内のマイナーバージョンとなります)
* 登録されたAdmission webhookは、新しい`kube-apiserver`インスタンスが送信するこれらのデータを扱うことができます:
Expand Down

0 comments on commit 422f5b0

Please sign in to comment.