[ja] Fix broken links due to using githubbranch param

Author: championshuttler

content/ja/docs/concepts/cluster-administration/manage-deployment.md

@@ -163,7 +163,7 @@ persistentvolumeclaim/my-pvc created
 
 これまで取り上げた例では、リソースに対して最大1つのラベルを適用してきました。リソースのセットを他のセットと区別するために、複数のラベルが必要な状況があります。
 
-例えば、異なるアプリケーション間では、異なる`app`ラベルを使用したり、[ゲストブックの例](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/)のようなマルチティアーのアプリケーションでは、各ティアーを区別する必要があります。frontendというティアーでは下記のラベルを持ちます。:
+例えば、異なるアプリケーション間では、異なる`app`ラベルを使用したり、[ゲストブックの例](https://github.com/kubernetes/examples/tree/master/guestbook/)のようなマルチティアーのアプリケーションでは、各ティアーを区別する必要があります。frontendというティアーでは下記のラベルを持ちます。:
 
 ```yaml
      labels:

content/ja/docs/concepts/configuration/overview.md

@@ -58,7 +58,7 @@ weight: 10
 
 ## ラベルの使用
 
-- `{ app: myapp, tier: frontend, phase: test, deployment: v3 }`のように、アプリケーションまたはデプロイメントの __セマンティック属性__ を識別する[ラベル](/ja/docs/concepts/overview/working-with-objects/labels/)を定義して使いましょう。これらのラベルを使用して、他のリソースに適切なPodを選択できます。例えば、すべての`tier：frontend`を持つPodを選択するServiceや、`app：myapp`に属するすべての`phase：test`コンポーネント、などです。このアプローチの例を知るには、[ゲストブック](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/)アプリも合わせてご覧ください。
+- `{ app: myapp, tier: frontend, phase: test, deployment: v3 }`のように、アプリケーションまたはデプロイメントの __セマンティック属性__ を識別する[ラベル](/ja/docs/concepts/overview/working-with-objects/labels/)を定義して使いましょう。これらのラベルを使用して、他のリソースに適切なPodを選択できます。例えば、すべての`tier：frontend`を持つPodを選択するServiceや、`app：myapp`に属するすべての`phase：test`コンポーネント、などです。このアプローチの例を知るには、[ゲストブック](https://github.com/kubernetes/examples/tree/master/guestbook/)アプリも合わせてご覧ください。
 
 セレクターからリリース固有のラベルを省略することで、Serviceを複数のDeploymentにまたがるように作成できます。 [Deployment](/ja/docs/concepts/workloads/controllers/deployment/)により、ダウンタイムなしで実行中のサービスを簡単に更新できます。
 

content/ja/docs/concepts/containers/container-environment.md

@@ -43,7 +43,7 @@ FOO_SERVICE_HOST=<サービスが実行されているホスト>
 FOO_SERVICE_PORT=<サービスが実行されているポート>
 ```
 
-サービスは専用のIPアドレスを持ち、[DNSアドオン](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/)が有効の場合、DNSを介してコンテナで利用可能です。
+サービスは専用のIPアドレスを持ち、[DNSアドオン](http://releases.k8s.io/{{< param "fullversion" >}}/cluster/addons/dns/)が有効の場合、DNSを介してコンテナで利用可能です。
 
 
 

content/ja/docs/concepts/services-networking/connect-applications-service.md

@@ -139,7 +139,7 @@ Service IPは完全に仮想的なもので、ホスト側のネットワーク
 ## Serviceにアクセスする
 
 Kubernetesは、環境変数とDNSの2つの主要なService検索モードをサポートしています。
-前者はそのまま使用でき、後者は[CoreDNSクラスタアドオン](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/coredns)を必要とします。
+前者はそのまま使用でき、後者は[CoreDNSクラスタアドオン](https://releases.k8s.io/{{< param "fullversion" >}}/cluster/addons/dns/coredns)を必要とします。
 {{< note >}}
 サービス環境変数が望ましくない場合(予想されるプログラム変数と衝突する可能性がある、処理する変数が多すぎる、DNSのみを使用するなど)、[Pod仕様](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)で`enableServiceLinks`フラグを`false`に設定することでこのモードを無効にできます。
 {{< /note >}}
@@ -234,7 +234,7 @@ Address 1: 10.0.162.149
 * 証明書を使用するように構成されたnginxサーバー
 * Podが証明書にアクセスできるようにする[Secret](/ja/docs/concepts/configuration/secret/)
 
-これらはすべて[nginx httpsの例](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/https-nginx/)から取得できます。
+これらはすべて[nginx httpsの例](https://github.com/kubernetes/examples/tree/master/staging/https-nginx/)から取得できます。
 これにはツールをインストールする必要があります。
 これらをインストールしたくない場合は、後で手動の手順に従ってください。つまり:
 
@@ -309,7 +309,7 @@ nginxsecret           kubernetes.io/tls                     2         1m
 nginx-secure-appマニフェストに関する注目すべき点:
 
 - 同じファイルにDeploymentとServiceの両方が含まれています。
-- [nginxサーバー](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/https-nginx/default.conf)はポート80のHTTPトラフィックと443のHTTPSトラフィックを処理し、nginx Serviceは両方のポートを公開します。
+- [nginxサーバー](https://github.com/kubernetes/examples/tree/master/staging/https-nginx/default.conf)はポート80のHTTPトラフィックと443のHTTPSトラフィックを処理し、nginx Serviceは両方のポートを公開します。
 - 各コンテナは`/etc/nginx/ssl`にマウントされたボリュームを介してキーにアクセスできます。
   これは、nginxサーバーが起動する*前に*セットアップされます。
 

content/ja/docs/concepts/services-networking/service.md

@@ -280,7 +280,7 @@ Kubernetesは、Serviceオブジェクトを見つけ出すために2つの主
 
 PodがNode上で稼働するとき、kubeletはアクティブな各Serviceに対して、環境変数のセットを追加します。
 これは[Docker links互換性](https://docs.docker.com/userguide/dockerlinks/)のある変数(
-[makeLinkVariables関数](https://releases.k8s.io/{{< param "githubbranch" >}}/pkg/kubelet/envvars/envvars.go#L72)を確認してください)や、より簡単な`{SVCNAME}_SERVICE_HOST`や、`{SVCNAME}_SERVICE_PORT`変数をサポートします。この変数名で使われるService名は大文字に変換され、`-`は`_`に変換されます。
+[makeLinkVariables関数](https://releases.k8s.io/{{< param "fullversion" >}}/pkg/kubelet/envvars/envvars.go#L72)を確認してください)や、より簡単な`{SVCNAME}_SERVICE_HOST`や、`{SVCNAME}_SERVICE_PORT`変数をサポートします。この変数名で使われるService名は大文字に変換され、`-`は`_`に変換されます。
 
 例えば、TCPポート6379番を公開していて、さらにclusterIPが10.0.0.11に割り当てられている`redis-master`というServiceは、下記のような環境変数を生成します。
 

content/ja/docs/concepts/workloads/controllers/statefulset.md

@@ -29,7 +29,7 @@ StatefulSetは下記の1つ以上の項目を要求するアプリケーショ
 
 ## 制限事項
 
-* 提供されたPodのストレージは、要求された`storage class`にもとづいて[PersistentVolume Provisioner](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/persistent-volume-provisioning/README.md)によってプロビジョンされるか、管理者によって事前にプロビジョンされなくてはなりません。
+* 提供されたPodのストレージは、要求された`storage class`にもとづいて[PersistentVolume Provisioner](https://github.com/kubernetes/examples/tree/master/staging/persistent-volume-provisioning/README.md)によってプロビジョンされるか、管理者によって事前にプロビジョンされなくてはなりません。
 * StatefulSetの削除もしくはスケールダウンをすることにより、StatefulSetに関連したボリュームは削除*されません* 。 これはデータ安全性のためで、関連するStatefulSetのリソース全てを自動的に削除するよりもたいてい有効です。
 * StatefulSetは現在、Podのネットワークアイデンティティーに責務をもつために[Headless Service](/ja/docs/concepts/services-networking/service/#headless-service)を要求します。ユーザーはこのServiceを作成する責任があります。
 * StatefulSetは、StatefulSetが削除されたときにPodの停止を行うことを保証していません。StatefulSetにおいて、規則的で安全なPodの停止を行う場合、削除のために事前にそのStatefulSetの数を0にスケールダウンさせることが可能です。

content/ja/docs/setup/best-practices/multiple-zones.md

@@ -15,7 +15,7 @@ This page describes how to run a cluster in multiple zones.
 ## 始めに
 
 Kubernetes 1.2より、複数のゾーンにおいて単一のクラスターを運用するサポートが追加されました(GCEでは単純に"ゾーン"，AWSは"アベイラビリティゾーン"と呼びますが、ここでは"ゾーン"とします)。
-これは、より範囲の広いCluster Federationの軽量バージョンです(以前は["Ubernetes"](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/design-proposals/multicluster/federation.md)の愛称で言及されていました)。
+これは、より範囲の広いCluster Federationの軽量バージョンです(以前は["Ubernetes"](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/multicluster/federation.md)の愛称で言及されていました)。
 完全なCluster Federationでは、異なるリージョンやクラウドプロバイダー(あるいはオンプレミスデータセンター)内の独立したKubernetesクラスターをまとめることが可能になります。しかしながら、多くのユーザーは単に1つのクラウドプロバイダーの複数のゾーンでより可用性の高いKubernetesクラスターを運用したいと考えており、バージョン1.2におけるマルチゾーンサポート(以前は"Ubernetes Lite"の愛称で使用されていました)ではこれが可能になります。
 
 マルチゾーンサポートは故意に限定されています: 1つのKubernetesクラスターは複数のゾーンで運用することができますが、同じリージョン(あるいはクラウドプロバイダー)のみです。現在はGCEとAWSのみが自動的にサポートされています(他のクラウドプロバイダーやベアメタル環境においても、単にノードやボリュームに追加する適切なラベルを用意して同様のサポートを追加することは容易ではありますが)。

content/ja/docs/setup/production-environment/turnkey/aws.md

@@ -53,9 +53,9 @@ export PATH=<path/to/kubernetes-directory>/platforms/linux/amd64:$PATH
 
 新しいクラスターを試すには、[簡単なnginxの例](/ja/docs/tasks/run-application/run-stateless-application-deployment/)を参照してください。
 
-"Guestbook"アプリケーションは、Kubernetesを始めるもう一つのポピュラーな例です: [guestbookの例](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/)
+"Guestbook"アプリケーションは、Kubernetesを始めるもう一つのポピュラーな例です: [guestbookの例](https://github.com/kubernetes/examples/tree/master/guestbook/)
 
-より完全なアプリケーションについては、[examplesディレクトリ](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/)を参照してください。
+より完全なアプリケーションについては、[examplesディレクトリ](https://github.com/kubernetes/examples/tree/master/)を参照してください。
 
 ## クラスターのスケーリング
 

content/ja/docs/setup/production-environment/turnkey/gce.md

@@ -146,7 +146,7 @@ Some of the pods may take a few seconds to start up (during this time they'll sh
 
 Then, see [a simple nginx example](/ja/docs/tasks/run-application/run-stateless-application-deployment/) to try out your new cluster.
 
-For more complete applications, please look in the [examples directory](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/).  The [guestbook example](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/) is a good "getting started" walkthrough.
+For more complete applications, please look in the [examples directory](https://github.com/kubernetes/examples/tree/master/).  The [guestbook example](https://github.com/kubernetes/examples/tree/master/guestbook/) is a good "getting started" walkthrough.
 
 ## クラスターの解体
 

content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md

@@ -131,7 +131,7 @@ kubeletはコンテナが問題なく動いていると判断します。
 
 200以上400未満のコードは成功とみなされ、その他のコードは失敗とみなされます。
 
-[server.go](https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/test/images/agnhost/liveness/server.go)
+[server.go](https://github.com/kubernetes/kubernetes/blob/master/test/images/agnhost/liveness/server.go)
 にてサーバーのソースコードを確認することができます。
 
 コンテナが生きている初めの10秒間は、`/healthz`ハンドラーが200ステータスを返します。