本文ソース：微信号「鲜枣课堂」
2010年、IT業界の数人の若者がアメリカ・サンフランシスコで「dotCloud」という会社を設立しました。
この会社は主にPaaSベースのクラウドコンピューティング技術サービスを提供していました。具体的には、LXCに関連するコンテナ技術です。
LXCとは、Linuxコンテナ仮想技術（Linux container）のことです。
その後、dotCloud社は自社のコンテナ技術を簡素化・標準化し、Dockerと名付けました。
Docker技術が誕生した後も、業界の注目を集めることはありませんでした。また、小規模なスタートアップ企業であるdotCloud社は、激しい競争の中で苦戦を強いられていました。
彼らがもう持ちこたえられなくなりかけたとき、頭に「オープンソース」というアイデアが浮かびました。
「オープンソース」とは何か？オープンソースとは、ソースコードを公開することです。つまり、これまで社内で秘匿していたプログラムのソースコードをすべての人に公開し、誰もがコードや意見を提供できるようにすることです。
最初からオープンソースのソフトウェアもあれば、行き詰まってしまい、それでも諦めたくない創設者がオープンソースにするケースもあります。自分で育てられなければ、「みんなの力を借りる」ということですね。
2013年3月、dotCloud社の共同創業者の一人であり、Dockerの父とも呼ばれる28歳のSolomon Hykes氏は、Dockerプロジェクトをオープンソース化することを正式に決定しました。
公開しなければ何事もなく、公開すれば驚くべき結果に。
ますます多くのITエンジニアがDockerの利点に気づき、殺到してDockerオープンソースコミュニティに参加しました。
Dockerの人気は急速に高まり、その速さには目を見張るものがありました。
公開当月にDocker 0.1バージョンがリリースされました。その後毎月、Dockerは新バージョンをリリースし、2014年6月9日にはDocker 1.0バージョンが正式にリリースされました。
この時点でDockerは、業界で最も人気のあるオープンソース技術となり、Google、Microsoft、Amazon、VMwareといった巨大企業までもが好意的に受け入れ、全力でサポートする姿勢を示しました。
Dockerが火がついた後、dotCloud社は社名もDocker Inc.に変更しました。
なぜDockerとコンテナ技術はここまで爆発的に流行したのでしょうか？一言で言えば、「軽い」からです。
コンテナ技術以前、業界の人気者は仮想マシンでした。仮想マシン技術の代表格は、VMWareとOpenStackです。
多くの人が仮想マシンを使ったことがあるでしょう。仮想マシンとは、あなたのOSの中にソフトウェアをインストールし、そのソフトウェアを介して1台または複数の「サブPC」をシミュレートするものです。
仮想マシンは「サブPC」のようなもの
「サブPC」の中では、通常のPCと同じようにプログラムを実行できます。例えばQQを起動することも可能です。もし望めば、複数の「サブPC」を作り出し、それぞれでQQを起動することもできます。「サブPC」同士は相互に隔離されており、互いに影響を与えません。
仮想マシンは仮想化技術の一種です。一方、Dockerのようなコンテナ技術も仮想化技術であり、軽量な仮想化に分類されます。
仮想マシンは多くの「サブPC」を隔離できますが、占有スペースが大きく、起動が遅く、仮想マシンソフトウェアにお金がかかる場合もあります（例：VMWare）。
一方、コンテナ技術にはこれらの欠点がありません。OS全体を仮想化する必要はなく、小規模な環境（「サンドボックス」のようなもの）だけを仮想化すればよいのです。
起動時間は非常に短く、数秒で完了します。また、リソースの使用効率が非常に高く（1台のホストで数千のDockerコンテナを同時に実行可能）、占有スペースも非常に小さいです。仮想マシンは通常数GBから数十GBのスペースを必要としますが、コンテナはMB単位、場合によってはKB単位で済みます。
こうした理由から、コンテナ技術は熱烈な歓迎と支持を受け、急速に発展しました。
具体的にDockerを見てみましょう。
注意すべき点は、Docker自体はコンテナではなく、コンテナを作成するツール、アプリケーションコンテナエンジンであることです。
Dockerを理解するには、その2つのスローガンを見れば十分です。
最初のスローガンは、「Build, Ship and Run」 です。
つまり、「構築、送信、実行」の3つのステップです。
例を挙げましょう：
私は空き地に来て、家を建てたいと思いました。そこで石を運び、木を切り、設計図を描き、一連の作業を経て、ようやく家を建てました。
しばらく住んだ後、別の空き地に引っ越したくなりました。従来の方法では、再び石を運び、木を切り、設計図を描き、家を建てるしかありません。
しかし、一人の老婆が現れ、私に魔法を教えてくれました。
その魔法とは、建てた家をコピーして「イメージ」を作り、それを私のリュックに入れておくというものです。
別の空き地に着いたら、この「イメージ」を使って家のコピーを作り、そこに置いてすぐに住むことができます。
どうですか？とても不思議でしょう？
そこで、Dockerの2番目のスローガンは次の通りです：「Build once, Run anywhere（一度構築すれば、どこでも使える）」。
Docker技術の3つの核となる概念は、次のとおりです。
- イメージ（Image）
- コンテナ（Container）
- レジストリ（Repository）
先ほどの例で、リュックに入れた「イメージ」がDockerイメージです。そして私のリュックがDockerレジストリです。空き地で魔法を使って建てた家が、Dockerコンテナに相当します。
つまり、このDockerイメージは特殊なファイルシステムです。コンテナの実行に必要なプログラム、ライブラリ、リソース、設定などのファイルを提供するだけでなく、実行時に準備するいくつかの設定パラメータ（環境変数など）も含んでいます。イメージは動的なデータを含まず、構築後はその内容が変更されることはありません。
つまり、家を出現させるたびに家自体は同じですが、生活用品などは一切関知せず、住む人が自分で準備するということです。
各イメージからは一種類の家を出現させることができます。つまり、私は複数のイメージを持つことができるのです。
つまり、私が洋風の別荘を建ててイメージを作りました。別の人が中国風の四合院を建ててイメージを作りました。さらには、アフリカの茅葺き小屋を建ててイメージを作った人もいます。
そうなると、私たちはイメージを交換することができます。あなたのものを使い、私のものを使う、とても便利ですよね？
こうして、大きな公共のレジストリが誕生しました。
Dockerイメージを管理する役割を担うのは、Docker Registryサービス（倉庫管理者のようなもの）です。
誰が作ったイメージでもすべてが合法というわけではありません。もし誰かが問題のある家を建てたらどうでしょう？
そのため、Docker Registryサービスによるイメージの管理は非常に厳格です。
最もよく使われるRegistryの公開サービスは、公式のDocker Hubです。これがデフォルトのRegistryであり、多数の高品質な公式イメージを保有しています。
さて、Dockerについて説明したところで、次はK8Sに話を移しましょう。
Dockerコンテナ技術が熱く語られる中、人々はDockerを実際のビジネスに応用するには困難があることに気づきました。すなわち、オーケストレーション、管理、スケジューリングなどの面で容易ではないのです。そこで、Dockerやコンテナをより高度かつ柔軟に管理するための管理システムが強く求められるようになりました。
そんな折、K8Sが登場しました。
K8Sは、コンテナベースのクラスタ管理プラットフォームであり、正式名称はkubernetesです。
Kubernetesという単語はギリシャ語に由来し、舵手や航海士を意味します。K8Sはその略称で、「8」という数字が「ubernete」の8文字を置き換えています。
Dockerとは異なり、K8Sの生みの親は誰もが知る業界の巨人――Googleです。
しかし、K8Sは全く新しい発明ではありません。その前身は、Googleが十数年にわたって自社で作り上げてきたBorgシステムです。
K8Sは2014年6月にGoogle社によって正式に公開され、オープンソース化が宣言されました。
同年7月、Microsoft、Red Hat、IBM、Docker、CoreOS、Mesosphere、Saltstackなどの企業が相次いでK8Sに参加しました。
その後1年以内に、VMware、HP、Intelなども加わりました。
2015年7月、Googleは正式にOpenStack Foundationに加入しました。同時に、Kuberentes v1.0が正式リリースされました。
現在、kubernetesのバージョンはV1.13にまで発展しています。
K8Sのアーキテクチャはやや複雑ですが、簡単に見てみましょう。
一つのK8Sシステムは、通常K8Sクラスタ（Cluster） と呼ばれます。
このクラスタは主に2つの部分から構成されます。
- 1つのMasterノード（マスターノード）
- 一群のNodeノード（計算ノード）
一目でわかるように、Masterノードは主に管理と制御を担当します。Nodeノードはワークロードノードであり、内部に具体的なコンテナが存在します。
これらのノードをさらに詳しく見てみましょう。
まずMasterノードです。
Masterノードには、API Server、Scheduler、Controller manager、etcdが含まれます。
- API Serverはシステム全体の外部インターフェースであり、クライアントや他のコンポーネントから呼び出されます。いわば「営業所」です。
- Schedulerはクラスタ内部のリソーススケジューリングを担当します。いわば「指令室」です。
- Controller managerはコントローラの管理を担当します。いわば「大番頭」です。
次にNodeノードです。
Nodeノードには、Docker、kubelet、kube-proxy、Fluentd、kube-dns（オプション）、そしてPodが含まれます。
PodはKubernetesの最も基本的な操作単位です。1つのPodはクラスタ内で実行される1つのプロセスを表し、その内部には1つまたは複数の密接に関連するコンテナがカプセル化されています。Podの他に、K8SにはServiceという概念があります。Serviceは、同じサービスを提供するPod群への外部アクセスインターフェースと見なせます。この部分は少しわかりにくいので、飛ばしましょう。
- Dockerは言うまでもなく、コンテナを作成するものです。
- Kubeletは、自身のNode上に割り当てられたPodの監視を主に担当します。作成、変更、監視、削除などを行います。
- Kube-proxyは、主にPodオブジェクトにプロキシを提供します。
- Fluentdは、主にログの収集、保存、クエリを担当します。
ちょっと混乱しますよね？まあ、数語で説明するのは本当に難しいので、引き続き飛ばしましょう。
DockerとK8Sの紹介は以上です。しかし、記事はまだ終わりません。
次の部分は、コアネットワークエンジニア、さらにはすべての通信エンジニアに向けて書かれています。
数十年前の1Gから、現在の4G、そして将来の5Gへと、移動通信は劇的な変化を遂げ、コアネットワークも同様です。
しかし、これらの変化を注意深く観察すると、いわゆるコアネットワークは本質的には何も変わっていないことに気づきます。結局は多くのサーバーでしかありません。異なるコアネットワークの網元は、異なるサーバー、異なる計算ノードにすぎません。
変化しているのは、これらの「サーバー」の形態とインターフェースです。形態は、ラック搭載のシングルボードからラック搭載のブレードへ、ラック搭載のブレードからX86汎用ブレードサーバーへ。インターフェースは、中継ケーブルからLANケーブルへ、LANケーブルから光ファイバーへ。
どんなに変わっても、やはりサーバーであり、計算ノードであり、CPUです。
サーバーである以上、ITクラウドコンピューティングと同様に、仮想化の道を歩むことは避けられません。なぜなら、仮想化には多くの利点があるからです。例えば、前述した低コスト、高利用率、高い柔軟性、動的スケジューリングなどです。
数年前までは、仮想マシンがコアネットワークの究極の形態だと考えられていました。現在では、より可能性が高いのはコンテナ化です。ここ数年よく言われているNFV（ネットワーク機能仮想化）も、NFC（ネットワーク機能コンテナ化）と言い換えられるかもしれません。
VoLTEを例に取ると、以前の2G/3Gの方式では、多数の専用機器が必要であり、それぞれがEPCやIMSの異なる網元として機能していました。
VoLTE関連の網元
一方、コンテナを採用すれば、おそらく1台のサーバーだけで十分であり、十数個のコンテナを作成し、それぞれ異なるコンテナで異なる網元のサービスプログラムを実行できます。
これらのコンテナは、いつでも作成でき、いつでも破棄できます。また、サービスを停止することなく、自由に大きくしたり小さくしたり、強くしたり弱くしたりでき、性能と消費電力の間で動的にバランスを取ることができます。
まさに完璧です！
5G時代、コアネットワークがマイクロサービスアーキテクチャを採用することは、コンテナとの完璧な組み合わせでもあります。モノリシックアーキテクチャ（Monolithic）がマイクロサービスアーキテクチャ（Microservices）になることは、1つの全能型からN個の専能型に変わることを意味します。各専能型は隔離されたコンテナに割り当てられ、最大限の柔軟性が与えられます。
細分化された分業
このような発展の傾向に従えば、移動通信システムにおいて、アンテナ以外の残りの部分はすべて仮想化される可能性があります。コアネットワークは最初ですが、最後ではありません。仮想化された後のコアネットワークは、通信に属するというよりも、むしろITに分類されるべきでしょう。コアネットワークの機能は、コンテナ内の単なるソフトウェア機能の1つに過ぎなくなります。
そして、ここにいるコアネットワークエンジニアの皆さん、おめでとうございます。もうすぐ転身に成功しますよ！
