‫Podが動作するようになったので､ おそらくどこかの時点でそれらを外部サービスに公開する必要が出てくるでしょう｡
‫つまり､ 何らかの方法で､ クラスタ内またはクラスタ外からの接続を受け入れることができるようにすることです｡
‫Kubernetesでは､ サービスを作成する方法の1つとして､
‫kubectl exposeコマンドを使用します｡
‫先ほどから何度かサービスに触れていますが､ サービスとは何かをはっきりさせましょう｡
‫サービスとは､
‫クラスタ内外の他のものがアクセスできるように一貫性を持たせたエンドポイントです｡
‫KubernetesでPodを作成すると､
‫IPアドレスで外部接続するためのDNS名が自動的に取得されません､
‫タイトです｡
‫その既存のPodの上にサービスを作ることでそれを実現したいのでしょう｡
‫サービスを作るには､ このexposeコマンドの他にも様々な方法があります｡
‫共通することに注目しよう｡
‫ここで共通しているのは､ コアDNSということです｡
‫先ほど､ コントロールプレーンの中核機能の1つとして紹介したのを覚えていますか？
‫そのサービスは､ これらすべての名前を解決するためのDNSサーバーとなる予定です｡
‫その上で､ IPとポートを選び､ どのようにそれを行うか､
‫どのようにあなたのサービスに本質的にトラフィックを得るかは､ 4つの異なるサービスタイプのうちの1つの仕事です｡
‫それでは､
‫今からそれらについて説明し､ その後､ いくつかの例を挙げていきます｡ まずは､ デフォルトのサービスタイプであるClusterIPから見ていきましょう｡
‫この場合､ 最も重要な点は､ クラスタ内でしか利用できないことです｡
‫これは､ あるKubernetesのPodのセットが､
‫別のPodのセットと会話しているということです｡
‫これには､ 独自のDNSストレスがかかるんですね｡
‫それがコアDNSコントロールプレーンのDNSアドレスになる｡
‫クラスタ内の仮想IPアドレス空間でIPアドレスを取得することになります｡
‫これにより､ クラスタ内で動作している他のポッドが､ サービスのポートを使用してこのサービスと通信できるようになります｡
‫Nginxアプリを実行していて､
‫サービスを作成したときにポート80で動作していた場合､ そのサービスIPもポート80になる可能性があります｡
‫そうすることで､ ある種の一貫性を保つことができるのです｡
‫考えてみれば､ これはSwarmでサービスを作るときと非常によく似ています｡
‫彼らの周りには､
‫違う考え方がある｡
‫しかし､ 少なくともサービスを作るときには､ ロードバランサーの内部IPが与えられるので､
‫覚えていれば一貫性があります｡
‫アプリがあるポートで実行されます｡
‫今回は､ よく似たことをやっていますが､ これはexposeコマンドや後で説明する他のオプションで作成する必要があります｡
‫ここで次に紹介するのはNodePortですが､ これは微妙に違います｡
‫箱から出してみると､ ちょっと戸惑いますね｡
‫ClusterIPはデフォルトで､ 常にクラスタ内部で動作します｡
‫特別なものは必要ないのです｡ クラスターにトラフィックが到達するために､
‫クラスター外のファイアウォールルールを必要としない｡
‫しかし､ ClusterIPはクラスタ内だけで良いのです｡
‫それを忘れないでください｡ ClusterIP､ クラスタ内では良好です｡
‫NodePortは､ クラスタ外部のものがノード自身のIPアドレスを通じてサービスと対話するために設計されています｡
‫NodePortを作成すると､ このサービスに割り当てられている各ノードのハイポートが取得されることになります｡
‫それを手に入れたら､ このポートについて知る必要のある他のものをアップデートすることができます｡
‫このポートは高いポートになりそうです｡
‫このタイプを使う場合､ 例えば80番ポートを使うことはないでしょう｡
‫この2つは､
‫どのKubernetesクラスタでも常に利用できることがポイントです｡
‫クラウドベンダーのソリューションを使っているか､ 自社でKubernetesを展開しているか､
‫Docker EnterpriseやRancherといったパッケージのものを導入しているかにかかわらずです｡
‫これらは､ 必ずアウトオブボックスで動作するものです｡
‫次は､ ロードバランサーのタイプです｡
‫これは主にクラウドで使われています｡
‫このアイデアは､ Kubernetesのコマンドラインから外部のロードバランサーを制御するというもので､
‫非常にクールなものです｡
‫本来､ これは自動化の塊なんです｡
‫ここでやっていることは､ バックグラウンドで､ このロードバランサーを作成するときに､
‫NodePortにClusterIPを自動的に作成し､ それらが利用できるようにすることです｡
‫そして､
‫外部のシステムと話をすることになる｡ AWSのロードバランサーとか､ 他のクラウドベンダーかもしれませんね｡
‫基本的に､
‫これらはインフラストラクチャ・プロバイダーから来るもので､ Kubernetesが何らかのリモートAPIを通じて彼らと会話し､
‫あなたのためにそれらを構成することを許可します｡
‫AWSロードバランサーの場合､
‫これを作成すると､ バックエンドにNodePortsとClusterIPを作成するだけでなく､ AWSロードバランサーにNodePortsと話すように指示することになります｡
‫本来､ これは単なる自動化ですよね｡
‫これは､ AWSのコマンドラインやウェブインタフェースを実行して､
‫ロードバランサーを自動的にセットアップする手間を省くのに役立つ｡
‫今回の2つのポイントは､ あくまで外部ソースからクラスタに流入してくるトラフィックに対するものだと考えることです｡
‫そのためには､ Kubernetesにリモートで会話する能力を与えるインフラプロバイダーが必要です｡
‫4つのサービスタイプのうち､ 最後に紹介するのが「ExternalName」です｡
‫これはあまり使われず､ サービスへのインバウンドトラフィックをコントロールすることとは関係がありません｡
‫これは､ クラスタ内のものが外部のサービスと話をする必要があるということです｡
‫クラスタが外部で管理していないExternalNamesを解決できるように､
‫コアDNSシステムでDNS名を作成したいとします｡
‫ExternalNameを使用する理由の1つは､
‫物事のマイグレーションを行うときです｡
‫リモートアプリケーションの場合について考えてみましょう｡
‫Kubernetesクラスタの外にあるそのリモートアプリケーションは､
‫おそらくすでにDNS名を持っています､ きつい｡
‫もし､ 外部サービスから内部サービスに何かを移動させようとしているのであれば､
‫Kubernetesのワークフロー内でDNSを制御するためにExternalNameを代用する方法を検討してもいいかもしれません｡
‫Kubernetesのコマンドラインは1つで､
‫「外部DNSを変更したいから､ そのDNSサービスのために別のユーティリティを実行しなければならない」ということはありません｡
‫あるいは､ 背後にAPIすらないようなものもあるかもしれません｡
‫エンタープライズDNSのようなものでしょうか｡
‫これをクラスタ内部で使用すると､
‫クラスタ内部のサービスが､ 以前は外部であったものとは異なるエンドポイントを解決するようになります｡
‫私は､
‫自分のものが自分のクラスタから外部のサービスに出る方法を変更する必要があるときだけ､
‫本当にこれを使うことにしていますが､ そういった他のもののDNSをリモートで制御する方法は持っていません｡
‫だから､
‫Kubernetesの中でやって､ 自分のもののためにExternalNamesをいくつか作る方がいいんです｡
‫そして､ Kubernetesで自分のクラスタ内のものを動的に変更したい場合､
‫他のものと会話することなく､ 非常に簡単に変更できます｡
‫わかりました｡ 以上､ 4つのサービスタイプについてまとめましたが､
‫他にもトラフィックがクラスタ内部に侵入する方法があります｡
‫それはIngressを通じてです｡
‫それについては､ 後ほどお話します｡
‫これはHTTPトラフィックに特化して設計されているんだ｡
‫そのレクチャーを受けると､ なぜそれがこれらのサービスタイプとは少し違うのか､
‫ご理解いただけると思います｡