コンテナネットワークの基礎知識【第6回】
AWS、Azure、GCPの「Kubernetesサービス」とは? 可用性を高めるための工夫
Kubernetesクラスタの構築・運用は簡単ではありません。運用するインフラを問わず、Kubernetesの課題を解消するさまざまな製品やサービスが登場しています。大手クラウドベンダーの関連サービスを紹介します。
第5回「『Kubernetesクラスタ』の自前構築はなぜ難しい? Kubernetes運用の基礎知識」では、コンテナオーケストレーター「Kubernetes」における、コンテナクラスタの構築・運用を手作業で実施することの難しさを解説しました。その難しさを解消するには、どのような製品やサービスが有効なのでしょうか。
Kubernetesに注目が集まる中で、クラウドベンダーやオンプレミスのインフラ向け製品のベンダーも、Kubernetesを自社の製品やサービスの中に取り込んでいます。そうした製品やサービスは、Kubernetesそのものとは異なりクラスタの構築・運用の作業を簡素化することを特徴としています。今回と次回では、Kubernetesを取り込んだ代表的な製品やサービスを見ていきます。今回は大手クラウドベンダーのKubernetes関連サービスを紹介しましょう。
クラウドベンダーのKubernetesサービス
大手クラウドベンダー各社は、サービスとしてKubernetesを提供しています。2015年にGoogleが「Google Kubernetes Engine」(GKE)を提供開始しました。これに続いて2017年にMicrosoftがコンテナ管理サービス「Azure Container Service」(ACS)でKubernetesを利用できるようにし(注1)、2018年にこれを「Azure Kubernetes Service」(AKS)としてサービス化しました。2018年にはAmazon Web Services(AWS)も「Amazon Elastic Kubernetes Service」(Amazon EKS)を提供開始しました。
※注1:ACSは2020年1月31日にサポート終了。
クラウドベンダー各社のこうしたサービスは、Kubernetesのコンテナクラスタ(Kubernetesクラスタ)を容易に利用開始でき、手作業では煩雑になるクラスタの構成やバージョンアップなどの管理作業を大きく簡素化することもできます。そのため運用管理者や開発者にとっては、Kubernetesによるアプリケーションの運用や開発に専念できるメリットがあります。
いずれもKubernetesの開発を推進する業界団体CNCF(Cloud Native Computing Foundation)の認定基準「Kubernetes Software Conformance」を満たしています。Kubernetes Software Conformanceは、Kubernetesのコントロールプレーン(Kubernetesクラスタを制御するコンポーネント)に接続する「Kubernetes API」が、OSS(オープンソースソフトウェア)のKubernetes同様に実装されていることを条件にしています。そのため認定済みのKubernetes製品は互換性が保証されています。
クラウドベンダーのKubernetesサービスは、コントロールプレーンとなる「マスター」をサービスとして提供し、コンテナを実行する「ノード」にユーザーが利用するインスタンス(仮想マシン)を割り当てます。例えばAmazon EKSは、同一リージョン(サービスを独立して提供する地域区分)内の複数のアベイラビリティゾーン(リージョンを小分けにした区分)にまたがるKubernetesのマスターをサービスとして提供します(図)。「Pod」(1つ以上のコンテナの集合体)が起動するノードは、このマスターによって制御されるインスンタンス(注2)として構築されます。ノードとして利用するインスタンスは、Amazon EKSの機能でバージョン管理することも可能です。
※注2:仮想マシンサービス「Amazon Elastic Compute Cloud」(EC2)のインスタンス。
Amazon EKSでは複数のアベイラビリティゾーンにマスターとノードを分散配置することで、可用性を高めることができます。特定のアベイラビリティゾーンで障害が発生した場合も、他のアベイラビリティゾーンのリソースによって機能し続けることが可能なため、障害に強い仕組みになっています。
次回はオンプレミスインフラ向け製品の主要ベンダーのKubernetesに関する取り組みと、主な関連製品を紹介します。
執筆者紹介
奈良昌紀(なら・まさのり) ネットワンシステムズ ビジネス開発本部 第1応用技術部
通信事業者のデータセンターにおいてネットワークやサーバの運用を経験後、ネットワンシステムズに入社。帯域制御やWAN高速化製品、仮想化関連製品を担当後、主にクラウドや仮想インフラの管理、自動化、ネットワーク仮想化の分野に注力している。
細谷典弘(ほそや・のりひろ) ネットワンシステムズ ビジネス開発本部第3応用技術部
データセンターネットワークの他、マルチクラウド向けのハードウェアやソフトウェアの最先端技術に関する調査・検証、技術支援などを担当。注目分野は「Kubernetes」。放送システムのIP化に向けた技術調査・検証も担当している。
千葉 豪(ちば・ごう) ネットワンシステムズ ビジネス開発本部 第1応用技術部
IaaS(Infrastructure as a Service)をはじめとしたクラウド基盤技術および管理製品を担当。コンテナ技術を中心とした開発・解析基盤の構築から運用、コンテナに関連した自動化技術や監視製品の技術検証などに注力している。
Copyright © ITmedia, Inc. All Rights Reserved.
コンテナネットワークの基礎知識
この記事の著者
関連記事
新着ホワイトペーパー PR
-
事例
[日本オラクル株式会社] ピンチをチャンスに変えたEPR製品は? 先行企業の導入事例3選 -
技術文書・技術解説
[日本オラクル株式会社] 無自覚なリスク 秘伝Excelファイルが監査の壁、不正・ミスの温床となる理由 -
製品資料
[日本オラクル株式会社] 戦略的経理の第一歩 失敗のない「脱Excel」を実現する秘訣とは? -
技術文書・技術解説
[日本オラクル株式会社] いまさら聞けないオンプレERPとクラウドERPの違い 最適な製品をどう見極める? -
事例
[株式会社ビザスク] 連結売上高が約2倍に成長、富士フイルムが実践した新規事業創出の戦略とは?
こんなメディアも見られています
TechTargetジャパンに関連する情報をお探しであれば、こちらのメディアもお役に立てるかもしれません。
ベンダーコンテンツ PR
From Informa TechTarget
SpecialPR
アクセスランキング
-
1
なぜ「全社配布Copilot」は使われないのか? 失敗に学ぶAI定着
-
2
損保ジャパンはなぜ「COBOL」を捨てなかったのか? 脱メインフレームの真相
-
3
「企業内サーバ環境の利用実態」に関するアンケート
-
4
「ノートPC派」は損をしている? Dellと考える“自作PC”のメリット
-
5
LINEヤフーはなぜ「社内の管理者」すら信用しないインフラを作ったのか
-
6
慶應義塾が「Notion」を選んだ理由 AI導入の盲点になる“情報のサイロ化”
-
7
生データを隠してデータ連携 KDDIが4000万人の顧客情報を安全に分析できた理由
-
8
IT製品の導入に関するアンケート「PC&デバイス」編
-
9
「データストレージの活用方法」に関するアンケート
-
10
新旧「Outlook」混在の恐怖を三星ダイヤモンド工業はどう乗り越えたか
ホワイトペーパーランキング PR
-
1
DX/AI投資の壁を突破、現代の最高財務責任者が直面する課題と克服のヒント
-
2
不審メールの経路や見せ方に変化? 2026年夏の3事例から見えた動向と対処方法
-
3
「オンプレミス回帰」せざるを得ない“合理的な理由”
-
4
バックアップは“取っているから大丈夫”なのか? ランサムウェア時代の備え方
-
5
システムの保守がモダン化を阻む? 「変えない判断」から脱却する方法とは
-
6
生成AIを開発に導入しても効果が見えない? 実証実験で分かった成果と課題
-
7
経産省DX指針から読み解く、受発注業務デジタル化ロードマップ
-
8
5分で分かる Microsoft 365のデータ損失に備えるためのバックアップの仕組み
-
9
ネットワーク遅延の原因、「パケットロス」の基礎知識と効果的な解決策
-
10
Microsoft 365を安全に運用 うっかりミスやサイバー攻撃に備えるデータ保護術
TechTargetジャパン SNS
インフォメーション
注目情報をチェック
TechTargetジャパンをフォロー