一方、オンプレミスでのKubernetesサーバを構築する場合、マスターノードとワーカーノードの両方を管理、運用しなければなりません。そのため、Kubernetesの管理に関する知識がある程度必要になります。
オンプレミスで困ることとして「マスターノードの構築と運用管理」「ストレージの管理」「ネットワークのロードバランサーの管理」の3つが挙げられます。
Kubernetesが出始めたころ、オンプレミスで、ツールを使わずにマスターノードを構築するのは、「苦行」といわれるほど大変な作業でした。しかし現在では、CNCF提供のKubernetesインストールツールをはじめ、kubeadm、kubespray、kops、rkeなど、作業を楽にしてくれるツールがたくさん出てきています。それらを使うことにより気軽にマスターノードを構築できるようになりました。
さらにLinuxディストリビューションを出している会社や独立系の開発会社がプラットフォームとして構築できるKubernetesディストリビューションを有償サポート付きで提供しています。
これらのさまざまなツールやディストリビューションがありますが、どれもKubernetesのソースコードを利用しています。これは各種LinuxディストリビューションがLinuxカーネルのソースコードを利用しているのと同じです。
「Kubernetesディストリビューションは、kubeadmで構築されたKubernetes環境とどう違うのか?」と聞かれることもあります。これは「各LinuxディストリビューションがLinuxカーネルとどう違うのか?」という質問と似ています。この質問に対する回答は、「Linuxディストリビューションは、Linuxカーネルとは違うところもあるが、Linuxの挙動という意味ではどちらも同じ機能を有している」です。
Kubernetesはさまざまなニーズと環境に合わせることのできる拡張性を持ったプロダクトです。この柔軟性により、さまざまなバリエーションのディストリビューションが生まれています。基本的な挙動については、CNCFから認証を受けていれば同じといえるでしょう。拡張機能により追加された部分や機能については、ディストリビューションにより異なるところがあるでしょう。
運用管理という意味では、Kubernetesを自前で使う場合、サポートリリースサイクルに注意する必要があります。正式なサポートはマイナーリリース3つ分までメンテナンスされます。マイナーリリースは3カ月ごとなので、正式なサポートは9カ月ということになります。Linuxディストリビューションから出ているKubernetesについては、サポートなどのサブスクリプション契約によりサポート期間が異なります。
サポート期間の長い短いはありますが同じバージョンをずっと使い続けるのは避けましょう。新しいバージョンでは機能がどんどん追加され使いやすくなっていくことを思えば、「Kubernetes自体のアップグレード戦略をどうするか?」についても考えておいた方がいいでしょう。各社のディストリビューションではアップグレードするツールを提供しています。
コンテナ内のデータはコンテナの停止とともに消滅してしまいます。そのままだと保存しなければいけないデータについても消えてしまいます。それを避けるために、Kubernetesは「Persistent Volume」という仕組みを備えています。これはPod内にコンテナ用のデータ保存領域を提供してデータの消滅を防ぐものです。Kubernetesには、このPersistent Volumeに必要な領域を動的に切り出すための「ダイナミックプロビジョニング」という機能があります。
一般的にはストレージといっても、さまざまなものがあります。サーバにつながっているHDDから、ネットワーク経由のiSCSIや分散ファイルシステム、仮想マシンの仮想ディスクなど、種類やスピード、接続方法まで多種多様です。
Kubernetesは、それらを一元的に扱おうとします。しかし、多種多様なストレージの、接続方法までは管理できないため、「プロビジョナー(Provisioner)」という仕組みでそれらの違いを吸収します。プロビジョナーはそれらのストレージを動かすためのデバイスドライバのような働きをします。
デバイスドライバで違いを吸収してもらいたい一方で、さまざまなオプションは個別に指定したいこともあるでしょう。それらのオプションを指定するのが「ストレージクラス(Storage Class)」です。名前を任意に指定できるので、別々の環境(例えば、GCPのGKEとAWSのEKS)で、名前だけ同じにしたストレージクラスを用意してマニフェストファイルで一意に利用することも可能です。通常はデフォルトのストレージクラスが用意され、指定がなければそれが使用されます。
プロビジョナーはさまざまなストレージに対応していますが、それらにマッチしたストレージを保有していなければなりません。マネージドサービスのKubernetesであればクラウド事業者が用意しているブロックデバイスサービス(AWSのEBSなど)を利用すればよいのですが、オンプレミス環境ではそういったブロックデバイスを切り出せるストレージを用意しなければなりません。
ストレージ各社もこぞって対応を始めていますが、現状で一番お手軽に利用できるのはNFSです。NFS利用時に注意しなければならない点としては、デバイスへの書き込み遅延に厳しいアプリケーションや、データを激しく書き換えるアプリケーションでは、パフォーマンスの面から問題が生じる可能性が高いということです。こういったアプリケーションでは利用しないようにしましょう。なおNetAppのストレージを既存リソースとして利用できる場合は、ONTAPのバージョン8.3以降であれば「Trident」というプロビジョナーを使うのもいいと思います。
オンプレミスで問題となるのが、Kubernetesの外のネットワークからKubernetes内に接続する方法です。マネージドサービスでは、Serviceリソースのtype:Loadbalancerにより、クラウド上のロードバランサーサービスを利用して外部ネットワークとの接続が自動的に設定されるようになっています。しかし、オンプレミスではそうなっていないので、「MetalLB」などのツールを使うことになるでしょう。
Kubernetesは、基本的にマニフェストファイルであったりコマンドであったり、CI/CDなどのパイプライン自動化ツールと一緒に使いやすくなっています。しかし、利用する人の全てがそれらのツールに慣れていたり、知識を十分に持っていたりするわけではありません。ブラウザからグラフィカルに閲覧し、設定を変更したい場合もあるでしょう。
Kubernetesのダッシュボードは必要な基本情報を見るためには十分な機能を持っています。さらに利便性を向上させブラウザでのUIを提供してくれるソフトウェアとしてRancher Labsの「Rancher」やWeaveworksが提供するソフトウェアがあります。
本連載では、「Kubernetesを使うと、何が変わるのか?」「Kubernetesを使うには、何が必要なのか?」といったことをインフラ技術者の視点から見てきました。
インフラ技術者として考えなければならないことは、Kubernetes自体の挙動と管理方法の理解、Kubernetesを有効に動かすための周辺アプリケーションの設定です。便利に使えるようになるためには、苦労しなければいけないことが非常にたくさんあるように見えるでしょう。
最終回で紹介したこと以外にも、対応しなければならない課題があります。認証情報サーバとの接続方法やログを取得して保存する方法、監視方法、バックアップ方法、「サーバの負荷監視をどうするか」「コンテナイメージレジストリをどうするか」「DNSのレコードを動的に書き換えるにはどうすればよいか」などです。これにCI/CD環境も考慮すると検討課題はさらに増えていきます。
こういったさまざまな課題を軽減できるので、Kubernetesを使うには、マネージドサービスでの利用を検討してはいかがでしょうか。
一方で、オンプレミスでKubernetesを利用しなければならない場合もあるでしょう。ここまで紹介した全ての課題を一度に解決しようとせず、一つずつ解決していくことをお勧めします。本稿で紹介した各ディストリビューションや有償サポートをうまく利用することも有効でしょう。課題に対応したツールやソフトウェア、コンサルティングを利用するなど、Kubernetesとうまく付き合っていけるようになることを願っております。
矢野 哲朗
株式会社スタイルズ SIビジネスグループ シニアエキスパート
ネットワークからDBとストレージ、パフォーマンスチューニングに従事。「ownCloud」と「Nextcloud」からオープンソースへの貢献を深め、現在はコンテナに関する企画、SIに従事している。
Copyright © ITmedia, Inc. All Rights Reserved.