Canonical、CNCF準拠の新たなk8sディストリビューション「Canonical Kubernetes」のβ版を公開:「Charmed Kubernetes」「MicroK8s」の経験に基づく
Canonicalは新たなKubernetesディストリビューションである「Canonical Kubernetes」のβ版を公開した。「Charmed Kubernetes」「MicroK8s」の経験に基づき、開発者が求める迅速な環境構築とエンタープライズ向けの自動化機能やセキュリティ機能の両方を提供するものだという。
Canonicalは、2024年3月14日(米国時間)、Kubernetes 1.30に基づく新たなKubernetesディストリビューション「Canonical Kubernetes」のβ版を発表した。
Canonicalはこれまでエンタープライズ向けKubernetesディストリビューションである「Charmed Kubernetes」と小規模環境やエッジ向けディストリビューションの「MicroK8s」を提供してきた。
Canonical Kubernetesは、これら2つのディストリビューションの経験を生かし、両者の特性を取り入れたCNCF(Cloud Native Computing Foundation)準拠の新たなディストリビューションだ。Canonical Kubernetesは今後、Charmed KubernetesおよびMicroK8sリリースの基盤になるという。
Canonical Kubernetesの特徴 シングルノードクラスタの構築方法
Canonical Kubernetesは、MicroK8sのように簡単にインストール可能であり、Charmed Kubernetesのような自動パッチアップグレードなどの高度なセキュリティ機能を提供する。クラスタに新しいノードを追加する手間も、最小限に抑えられている。また高可用性を迅速に設定することもできるという。
Canonical Kubernetesでシングルノードクラスタを構築するには、インストール用とクラスタブートストラップ用の2つのコマンドを実行する必要がある。
sudo snap install k8s --channel=1.30-classic/beta --classic sudo k8s bootstrap
これらのコマンドを実行すると、network、dnsおよびmetrics-serverが実行される。またlocal-storage、ingress、gatewayおよびroad-balancerも提供され、簡単に有効化できる。
内部的には「Cilium」「CoreDNS」「OpenEBS」「Metrics Server」によって強化されており、これらをビルトイン機能としてバンドルすることで、緊密な統合とシームレスなエクスペリエンスが確保されている。ビルトイン機能は、ニーズに合わせて簡単に変更できると、Canonicalは述べている。
開発者ワークステーション、エッジ、クラウド、データセンターで同じKubernetesを使用可能
一般的なアプリケーション開発フローは、開発者ワークステーションから始まり、CI/CD(継続的インテグレーション/継続的デリバリー)パイプラインを経て、本番環境に到達する。さまざまな環境にまたがるこれらのソフトウェアデリバリーステップは、緊密に連携させる必要がある。正しく実行できれば、アプリケーションはより迅速にデプロイできる。また、インフラストラクチャソフトウェアスタック全体で同じベンダーが提供する同じKubernetesバイナリを誰もが使用できるため、セキュリティ保証も強化される。
だが、開発者ワークステーションから本番環境にスケールアップすると、必然的に大規模なインフラストラクチャならではの別種の問題にさらされる。例えば、クラスタノードの管理とアップグレードは、ノードとアプリケーションの数が増えるにつれて複雑化し、時間がかかるようになる。そこで、Canonicalはソフトウェア運用者向けオープンソースオーケストレーションエンジン「Juju」を通じてKubernetesのライフサイクル管理機能を提供する。
マシンにJujuがインストールされている場合は、Canonical Kubernetesクラスタを次のコマンドで構築することもできる。
juju deploy k8s --channel edge
Jujuにライフサイクル管理を自動化させることで「Canonical Observability Stack」を含む豊富な統合エコシステムの恩恵を受けられると、Canonicalは述べている。
セキュリティ体制の強化
Canonical Kubernetes 1.30は、同社のSnapパッケージ配信システムの「Confinement level(制限レベル)」においてclassicレベル(最小制限レベル)で提供される。これにより、自動パッチアップグレードが有効化され、既知の脆弱(ぜいじゃく)性からインフラを保護する。Canonicalによると、将来的にはstrictレベル(厳格な制限レベル)で提供される予定だという。
Canonical Kubernetesに組み込まれた重要な機能は、同社によってメンテナンスされたセキュアなコンテナイメージとして提供される。これらのイメージは、UbuntuをベースOSとして構築されている。
Kubernetesのコアプロセスを制御する必要がある一方で、ユーザーが提供するワークロードが安全で十分に制御された環境で実行されることを確保する必要がある。将来のCanonical Kubernetesのバージョンでは、ユーザーが提供するコンテナ用にAppArmorプロファイルが提供される予定だと、Canonicalは述べている。
Copyright © ITmedia, Inc. All Rights Reserved.
関連記事
- レッドハットがOpenShiftの仮想マシン管理機能を説明、「問い合わせ増えた」
レッドハットが、コンテナ基盤の「Red Hat OpenShift」で仮想マシンを管理できるOpenShift Virtualizationについて説明した。VMwareを取り巻く状況の変化を受けて、問い合わせが増えているという。 - 「Kubernetesコスト最適化」はできている? 4000のKubernetesクラスタを分析 CAST AI
CAST AIは、4000のKubernetesクラスタを分析した「Kubernetes Cost Benchmark Report」を発表した。50以上のCPUを割り当てているKubernetesクラスタにおいて、企業が実際に利用しているのは割り当てられたCPUの平均で13%、メモリでは20%のみだった。 - オープンソースのKubernetesネットワーク可観測性プラットフォーム「Retina」をリリース Microsoft
Microsoftは、特定のクラウドに依存しないオープンソースのKubernetesネットワークオブザーバビリティプラットフォーム「Retina」をリリースした。