海外動向から読み解く2019年のコンテナトレンド

「コンテナ技術入門」、「エンタープライズ向けKubernetesのご紹介」では、コンテナがどのように独立した実行環境を実現しているのか、またコンテナのオーケストレーションツールである Kubernetes とその商用製品をご紹介しました。
本記事ではそれらを踏まえてコンテナ技術が今後どのような発展をしていくのか近年のトレンドから読み解きたいと思います。

クラウドネイティブ技術の祭典 KubeCon, CloudNativeCon

Kubecon, CloudNativeCon とはCloud Native Computing Foundation(CNCF) によって毎年ヨーロッパ、中国、米国で3回にわたって開催される Kubernetes を中心としたオープンソースやクラウドネイティブ技術に関するカンファレンスです。
そのため、自然とコンテナに関する技術情報が集まりやすく近年では日本からも約100名弱の方々が参加し最新技術情報をキャッチアップしています。それでは近年の KubeCon, CloudNativeCon での発表内容から注目すべきトピックを取り上げてみたいと思います。

Kubevirt

Kubernetes によってコンテナのオーケストレーションは実現されましたが、インフラの管理という観点ではコンテナ化が難しく従来の手法で作成された仮想マシンも管理する必要が出てきます。しかし、それでは仮想マシンとコンテナの2つのリソースを個別に管理する必要が出てきてしまい運用者からするとより煩雑になってしまいます。
Kubevirt は、そのような課題を解決するために開発され、Kubernetes で管理される Pod/Deployment/Service などのリソースと同様にマニフェストによる定義やクライアント CLI である kubectl による仮想マシンの作成、起動、停止といった操作を可能としています。

2019年9月現在の最新バージョンは v0.20.0 となっておりプロジェクトとしてはまだまだ始まったばかりといったところですが、実運用において発生しうる課題を捉えており今後の発展に期待したいところです。

apiVersion: kubevirt.io/v1alpha3
kind: VirtualMachine
metadata:
  name: testvm
spec:
  running: false
  template:
    metadata:
      labels:
        kubevirt.io/size: small
        kubevirt.io/domain: testvm
    spec:
      domain:
        devices:
          disks:
          - name: containerdisk
            disk:
              bus: virtio
          - name: cloudinitdisk
            disk:
              bus: virtio
          interfaces:
          - name: default
            bridge: {}
        resources:
          requests:
            memory: 64M
      networks:
      - name: default
        pod: {}
      volumes:
      - name: containerdisk
        containerDisk:
          image: kubevirt/cirros-registry-disk-demo
      - name: cloudinitdisk
        cloudInitNoCloud:
          userDataBase64: SGkuXG4=

マニフェストファイルの例

CloudNative Network Function(CNF)

これまでテレコムキャリアを中心に議論されてきた NFV(Network Functions Virtualization) ですが、従来仮想マシンで実現していた VNFs(Virtual Network Functions) をコンテナで実現する CNF といった手法が提案されています。

図:CNF の構想(CNF Testbed より抜粋)

従来の NFV のアプローチでは OpenStack, VMware といった IaaS 基盤上で仮想マシンを動作させることで VNFs を提供してきましたが徐々に基盤を Kubernetes に置き換え最終的には全ての基盤を Kubernetes を軸に提供しようという考え方です。面白いのが先に述べた Kubevirt などの技術を応用することで従来の VNFs に関しても Kubernetes 上で動作させる点でしょう。

Virtual Kubelet

Virtual Kubelet は Kubernetes ノード上で動作する kubelet をコンテナとして動作、模倣しあたかもノードが存在するかのようにみせかけます。
これはKubernetes上でコンテナを制御する際に外部の API を利用することを目的としており、Virtual Kubelet を利用することで実在するノードではなくAzure Container Instance(ACI)、AWS Fargate などの外部サービス上でコンテナを動作させます。

主な利用用途として、ACI や AWS Fargate を利用することで既存 Kubernetes クラスター上で急激に負荷が増大した際、新規にノードを追加するのではなく外部サービスを利用して即座にクラスターのリソースを増やすといった活用方法があります。

図:Virtual Kubelet のアーキテクチャ

Cluster API

Cluster API とは Kubernetes 上の管理リソースとして Kubernetes クラスターを管理し、Kubernetes クラスターの作成・削除・更新といった作業を実現しようというプロジェクトです。
現在はクラウドサービス毎に Kubernetes クラスターの構築方法が異なるため、複数クラスターを管理するとなると各々のバージョン、ノード数など運用において考慮しなければいけない点が多々あります。そのため、本プロジェクトでは共通のインターフェースを提供し、Pod/Deployment といった Kubernetes リソースと同等にクラスターやその構成ノードを管理することができます。

Operator Pattern

Kubernetes によりコンテナのためのインフラストラクチャは抽象化され、自動化により管理コストは削減できるでしょう。しかし、実際の運用においてコンテナ管理の自動化だけで十分と言えるでしょうか? 例えば、データベースをコンテナとして動かしていた場合はサービス継続性を高めるために定期的なバックアップやレプリケーションが必要となります。また、コンテナの監視やKubernetes 自体のリソース監視なども必要となりますが、どのような項目を監視するべきでしょうか? Operator Pattern とは従来運用者が考慮するべきこのような課題を解決するためのベストプラクティスを Kubernetes 上で管理する仕組みです。

図:Operatorの概念図

Operator は独自のリソース定義を行う Custom Resource Definition(CRD) とリソースの制御を行う Controller から構成されます。CRD では Kubernetes の API を拡張し Pod/Deployment/Service といった標準リソースと同様に独自のリソースを定義します。それに対し Controller ではそれらのリソースの制御をし、利用者によって定義されたマニフェストファイルの内容にしたがい構成変更を実施します。
なお、先に述べた Kubevirt, Cluster API などはこの Operator Pattern を利用することで本来リソースとして定義されていない “仮想マシン”, “クラスター” などのリソースを Kubernetes 上で管理可能としています。

まとめ

これまで、コンテナ技術は開発基盤や Web サービス基盤として利用されることが多かったのですが、現在はトピックにも挙げたように、既存の仮想マシンを管理する、クラスター自体を管理する、サーバーレス基盤や IoT 基盤と組み合わせる、といった具合にさまざまな利用用途に活用できないかという挑戦が盛んです。
特に最後に述べた Operator Pattern の登場により簡単に Kubernetes の API を拡張できるようになり、コンテナのオーケストレーションツールである Kubernetes がコンテナに限らずさまざまなリソースを管理できるプラットフォームとして成長しつつあります。

※本記事の内容は執筆者個人の見解であり、所属する組織の見解を代表するものではありません。