translate "version skew"

af12066 · af12066 · commit 422f5b0e6a0c · 2019-08-24T16:18:24.000+09:00
#15903 (comment) バージョン間の差異 となる タイトルは原文どおりに用語として残し、初回の文でskew=差異であることを明示する 以降はskewを翻訳する
diff --git a/content/ja/docs/setup/release/version-skew-policy.md b/content/ja/docs/setup/release/version-skew-policy.md
@@ -5,7 +5,7 @@ weight: 30
 ---
 
 {{% capture overview %}}
-このドキュメントでは、さまざまなKubernetesコンポーネント間でサポートされる最大のバージョンスキューについて説明します。特定のクラスターデプロイツールは、バージョンスキューに追加の制限を加える場合があります。
+このドキュメントでは、さまざまなKubernetesコンポーネント間でサポートされる最大のバージョンの差異（バージョンスキュー）について説明します。特定のクラスターデプロイツールは、バージョンの差異に追加の制限を加える場合があります。
 {{% /capture %}}
 
 {{% capture body %}}
@@ -41,7 +41,7 @@ Kubernetesプロジェクトでは、最新の3つのマイナーリリースに
 * `kubelet`は**1.13**、**1.12**および**1.11**をサポートします
 
 {{< note >}}
-HAクラスター内の`kube-apiserver`間にバージョンスキューがある場合、有効な`kubelet`バージョンは少なくなります。
+HAクラスター内の`kube-apiserver`間にバージョンの差異がある場合、有効な`kubelet`バージョンは少なくなります。
 {{</ note >}}
 
 例:
@@ -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 >}}
 
 例:
@@ -77,7 +77,7 @@ HAクラスター内の`kube-apiserver`間にバージョンスキューがあ
 * `kubectl`は**1.14**、**1.13**および**1.12**をサポートします
 
 {{< note >}}
-HAクラスター内の`kube-apiserver`間にバージョンスキューがある場合、有効な`kubectl`バージョンは少なくなります。
+HAクラスター内の`kube-apiserver`間にバージョンの差異がある場合、有効な`kubectl`バージョンは少なくなります。
 {{< /note >}}
 
 例:
@@ -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`インスタンスが送信するこれらのデータを扱うことができます:
