KubeVirtでVMをデプロイするためのVirtualMachineオブジェクトの定義例
KubeVirtを使用すればKubenetes上でコンテナと並列にVMを動作させることできますが、今回は実際にVMをデプロイする際の定義例を紹介します。
KubeVirtの概要に関しては以下の記事を参照ください。
KubeVirtをインストールすると、Kubernetes APIに仮想マシンを管理する「VirtualMachine API」が追加され、他のAPIリソースと同様に、kubectlを使用して管理することができます。
以下が、KubeVirtをインストールしたKubenetes上へのVM(VirtualMachineオブジェクト)の定義例(YAML)になります。
Podを定義する場合と同様に、apiVersionフィールドやspecフィールドがあります。
また、kindにはVirtualMachineを指定します。
apiVersion: kubevirt.io/v1alpha1
kind: VirtualMachine
metadata:
name: testvm
spec:
terminationGracePeriodSeconds: 0
domain:
resources:
requests:
memory: 64M
devices:
disks:
- name: mydisk
volumeName: myvolume
disk:
dev: vda
volumes:
- name: myvolume
iscsi:
iqn: iqn.2017-01.io.kubevirt:sn.42
lun: 2
targetPortal: iscsi-demo-target.kube-system.svc.cluster.local
＜参考記事＞
http://www.kubevirt.io/user-guide/#/workloads/virtual-machines/creation?id=virtualmachine-api
クラウド関連の仕事で最も要求度が高い10のスキル
求人情報専門の検索サイトのIndeedによると、アメリカのクラウドエンジニアの平均給与は$111,796（約1200万円）でかなり高給なようで、その求人情報自体も2015年から27%増加しているとのこと。
日本でも当然クラウド化の流れは進んでいくため、アメリカ同様、今後はクラウド関連のスキルがますます重要になってくる。
記事では、「クラウド関連の仕事で最も要求度が高い10のスキル」として以下が紹介されている。
- Amazon Web Services
- Python
- Java
- Azure
- Agile
- Puppet
- Chef
- Ansible
- Docker
- VMware
皆さんは上記に関しどれくらいスキルをお持ちだろうか。
本ブログでも今後、上記のスキルのうちいくつかに関しては、実践を踏まえた紹介をしていければと考えている。
Kubernetesクラスタのノード内でコンテナと並列にPod内でVMが実行できるKubevirt
Kubernetesは複数のコンテナを管理するためのオーケストレーションツールだが、Kubevirtで拡張することで、コンテナと並列にVMを実行することができる。
例えば、コンテナ化されていないアプリケーションなどを、KubernetesのPod内のVM上で実行させることができる。KubernetesのPod内の動作するため、他のPod内のコンテナと同様に、KubectlなどのKubernetesのツールを使用して管理することができる。
Kubevirtのコンポーネント（Getting to Know Kubevirt - Kubernetes）
以下は、Kubevirtの紹介記事および記事内の説明の抜粋とGoogle翻訳での日本語訳。
"Maybe you need to run an application that isn’t architected for containers, or that requires a different version of the Linux kernel – or an all together different operating system – than what’s available on your container host."
"おそらく、コンテナ用に設計されていないアプリケーションや、Linuxカーネルの異なるバージョン、またはすべてが異なるオペレーティングシステムを必要とするアプリケーションをコンテナホスト上で実行する必要があるかもしれない。"
"These sorts of workloads are often well-suited to running in virtual machines (VMs), and KubeVirt, a virtual machine management add-on for Kubernetes, is aimed at allowing users to run VMs right alongside containers in the their Kubernetes or OpenShift clusters."
"これらの種類のワークロードは、仮想マシン（VM）での実行に適していることが多く、Kubernetesの仮想マシン管理アドオンであるKubeVirtは、ユーザーがKubernetesまたはOpenShiftクラスタのコンテナに沿ってVMを実行できるようにすることを目的としている。"
"KubeVirt extends Kubernetes by adding resource types for VMs and sets of VMs through Kubernetes’ Custom Resource Definitions API (CRD). KubeVirt VMs run within regular Kubernetes pods, where they have access to standard pod networking and storage, and can be managed using standard Kubernetes tools such as kubectl."
"KubeVirtは、Kubernetesのカスタムリソース定義API（CRD）を使用して、VMおよびVMのリソースタイプを追加することで、Kubernetesを拡張する。 KubeVirt VMは標準的なKubernetesポッド内で実行され、標準ポッドネットワークとストレージにアクセスし、kubectlなどの標準Kubernetesツールを使用して管理できる。"
初心者からのKubernetes入門と基本機能の動作例
1.コンテナとオーケストレーションツール
- コンテナはそれ単体では単なるプロセスであり、実際にコンテナとしてアプリケーションを動かすには複数のコンテナを協調させて動かす必要がある（WebサーバーコンテナやDBサーバーコンテナなど）。
- 特に大規模や企業の商用サーバー用途では以下の考慮点が必要。
– 分散環境での複数のコンテナのデプロイ・管理
– 資源配置の最適化（各サーバーのCPUやメモリ等のリソース状況を考慮してどのサーバーにコンテナをデプロイするかなど）
– 負荷分散、冗⻑化、負荷増加時のスケール
– コンテナの監視
– アップデート（コンテナのバージョンアップなど） - それらを引き受け、コンテナ化されたアプリケーションのデプロイや管理を自動化するのがオーケストレーションツール。
2.Kubernetesとは
- オーケストレーションツールのデファクトスタンダード。
- 元はGoogleが独自に開発して車内で運用していたコンテナ管理システム。Googleは毎週20億個のコンテナを生成(https://goo.gl/w7oBxe)
- 2014年にOSSとして公開、2015年にCNCFに寄贈。
- CNCFとは
-CNCF:Cloud Native Computing Foundation(https://www.cncf.io/)
–Linux Foundationを組織の母体とする非営利組織。2015年7月21日設立。
–各クラウド事業者もCNCFに加入（Amazon Web Services, Microsoft, IBM etc)。
–最先端のクラウドネイティブなアプリケーションやサービスの開発を促進することを目的とする団体。
–クラウドネイティブとは、OSSのスタックを使い、コンテナ化を実現し、マクロサービスのアプリケーションを動かせるようにすること。
–KubernetesはCNCF傘下のプロジェクトであり、CNCFにおいて、Kubernetesの仕様の今後の開発について議論され、CNCFメンバー36社が、統一した規格と仕様を決めることに合意している。(https://goo.gl/e24imz)
-大手企業での採用も進んでいる：New York Time, Goldman Sachs, Person, PHILIPS, Yahoo! Japan, CONCUR, BOX, Pokemon GO
-上記のメンバー間での合意や大手企業での採用状況がKubernetesがデファクトスタンダードと言われる所以の一つとなっている。
3.Kubernetesのアーキテクチャ
3-1.Kubernetesクラスタ
- 多数のマシンで構成されるスケールアウト型のアーキテクチャを前提としており、各ノード（物理サーバーやVMの上で動く仮想サーバーなど）の集合を「クラスタ」という単位でグループ化する。
- ノードは以下の種別に分類される。
-Master node: クラスタ全体の管理を担う
-Worker node: Masterから指示を受けてアプリケーションのコンテナを実行
Kubernetesのアーキテクチャ
3-2.Master nodeとWorker nodeの構成要素
- 以下がMaster nodeとWorker node上の主要な構成要素。
- Worker node上のPodに関しては以降で別途説明。
Master nodeとWorker nodeの構成要素
Master nodeとWorker nodeの構成要素（コンポーネント）一覧
3-3.Pod
- Kubernetesでは、1個以上のコンテナを包含する「Pod」という単位でデプロイを行います。
- Podには以下の特徴があります。
–１つ以上のコンテナを包含する
–Pod内の全コンテナが同一のNodeにデプロイされることが保証される
–仮想IPを共有する
–localhostでコンテナ間が通信できる
–ボリュームを共有できる
–スケールアウトはPod単位で行われる（個々のコンテナ単位ではない）
- どういう場合に複数コンテナを1つのPodに集約するのか
–コンテナ同士が密接に連携する
–同時にスケールさせたい
-例）
・Webサーバーコンテナとそれを監視するコンテナなど。
・スケールのさせ方が違うWebサーバー（スケールウト）とDBサーバー（スケールアップ）を集約させるのはアンチパターン。
4.クラスタへのデプロイの流れ
- Kubernetesクラスタへのアプリケーションデプロイ手順は以下のようになります。
- Masterに対してデプロイすべきコンテナのイメージや個数などの情報を指示する（YAML, JSON）
- Masterは指示された構成情報をetcdに永続化する
- Masterは情報に基づいて、コンテナをデプロイすべきNodeを決定する
- MasterはNodeに対してコンテナの実行を指示する
- Nodeは必要に応じて指定されたコンテナイメージをpullしたうえで実行する
- デプロイ指示（YAML）例
kubectl apply -f healthcheck.yml
5.Kubernetsの主要機能
5-1-1.ReplicaSet
- 冗長性や負荷分散を考慮し同じPodを複数デプロイしたい場合、1つ1つPodをデプロイすることも可能だが、ReplicaSetを使用することで複数のPodをまとめてデプロイすることが可能。
- ReplicaSetは指定されたイメージ・個数のPodを自動で作成してくれる仕組み。
- ReplicaSetは条件に従ってPodを検索し、稼働しているPodの数がreplicasと一致しているかどうかをチェック。
- repilcasよりも少ない場合は新規にPod追加し、多いときは余剰分のPodを停止する。
- ReplicaSetを指定
- 作成したPod数を指定
- 作成するコンテナイメージを指定
5-1-2.ReplicaSetによるオートヒーリング時の動作例
- YAMLからReplicaSetを作成（spec.replicas:2で作成）
- ReplicaSetのステータス
- ReplicaSet内のPodのステータス
- Podを1つ削除
- Podが1つ削除され、新たに別のPodが起動
※オートヒーリングによって起動されるPodは、障害などによって停止したPodの状態を引き継ぐわけではない。
※オートヒーリングによる回復はあくまで「指定されたコンテナイメージを利用してPodを再度起動する」機能。
5-2.Liveness ProbeによるPodのヘルスチェック
- オートヒーリングではPodが稼働しているかどうかは、単純にPod内のコンテナのプロセスが稼働しているかどうかで判断。
- Liveness ProbeではPodの定義に対して次のヘルスチェックを追加ですることで、サービスレベルのPodの監視が可能となる。
–HTTP GET : 指定されたURLにHTTP GETを発行し、レスポンスが正常であることを確認
–TCP Socket : 指定されたポートに接続し、TCP接続が確立できることを確認
–Exec : 指定されたコマンドをコンテナ内で実行し、ステータスコードが0であることを確認
5-3-1.Service
- Podは実際にデプロイされるまでIPアドレスはわからないし、オートヒーリング等で作り直された際はIPアドレスも変化するため、固定のアクセス先を決めることができない。
- Serviceは複数のPodで構成されるサービスを代表し、外部からのアクセスを可能とする。
- Serviceを作成することで、IPアドレスを意識することなく各Podにアクセス可能となる。
- Serviceの要素は次の通り。
–ClusterIP: スタティックなIPアドレス（クラスタ内IP）
–port : Pod側ポート番号
–targetPort : 外部公開ポート
–selector : サービスを構成するPodを特定するラベル
5-3-2.Serviceによる外部からのアクセス例
- worker nodeのIP
- Podと外部公開ポート
5-4.Readiness ProbeによるPodのヘルスチェック
- Readiness Probeは、Podの定義に対して以下のヘルスチェックを追加することで、Podの初期化処理が完了しサービスに応答できる状態になるまではService経由でのPodの公開を抑制できる。
–HTTP GET : 指定されたURLにHTTP GETを発行し、レスポンスが正常であることを確認
–TCP Socket : 指定されたポートに接続し、TCP接続が確立できることを確認
–Exec : 指定されたコマンドをコンテナ内で実行し、ステータスコードが0であることを確認
5-5-1.Deployment
- Deploymentはアプリケーションの新しいバージョンのリリースを管理する仕組みで、アプリケーションのアップデートやロールバックを宣言的に行うことを可能とする。
- Deploymentはその配下にReplicaSetをもち、ReplicaSet単位のバージョンを管理する。
- アップデートやロールバックのさせ方（strategy）は以下の2種類を設定可能。
＜RollingUpdate(デフォルト)＞
- Podを順次停止しアップデートしていく。
- Recreateよりも動作は遅いが、ユーザートラフィックを受けながらサービスのバージョンアップが可能。
- maxSurge:
- アップデート実行中に指定されたscaleよりも余分に起動して良いPod数を絶対値もしくは%で指定。
- maxUnavailable :
- アップデート実行中に指定されたscaleを割り込んでも良いPod数を絶対値もしくは%で指定。
＜Recreate＞
- アップデート前に旧バージョンのPodを全て停止してから新バージョンのPodを起動する。
- バージョン混在は回避できるが、ユーザーからみるとサービス停止が発生する。
- Deploymentを指定（ReplicaSetは指定不要。自動で作成される）
- Deploymentの種類を指定（ROllingUpdateがデフォルト）
- コンテナのテンプレートが変更になるとアップデートされる
5-5-2.Deploymentによるローリングアップデート時の動作例
- YAMLからDeploymentを作成
- Deploymentのステータス
- ReplicaSetのステータス確認
- Deployment定義の対象コンテナイメージを変更
- ロールアウトのステータス確認
- Deploymentのステータス確認
- ReplicaSetのステータス確認
