このブログを検索

この記事の内容は、個人の見解、検証の範囲のものであり、誤りがある可能性があります。
個人の責任において情報活用をお願いします。


2021年12月31日金曜日

俺とkubernetesと時々vSphere -動的PVCの利用について その1-

このブログは、コンテナのオーケストレーターであるkubernetesについて

自分の知識をまとめることを目的として記事を書いています。

もともとなが~くvSphereのあれやこれやに携わってきたのでvSphereとの類似点や

相違点についてもちょっと混ぜていけたりしたらいいかなぁとかも思っています。


今回はPodのストレージ周りのお話となります。

Podは停止=削除となりますので、Podが停止するとPodがなくなります。

当然Podの中に蓄えられていたデータも消えてなくなります。


データベース等のPodを停止するたびに情報がなくなってしまっては困ります。

そこで、永続ボリュームというPod外部にPod用のデータ保存領域を作成してデータを

保存しようという仕組みがあります。

Strageclass(SC)、PersistentVolume(PV)、PersistentVolumeClaim(PVC)ですね。


SCは一度定義してしまえばそうそう作り直し等の作業はないと思いますが、

PVとPVCは利用するPod毎に用意する必要があり、毎度毎度必要なサイズのPVを作って

それを要求するPVCを作ってとやっていると手間ですし、PVの数が増えると管理も大変です。


そこで、PVCで要求する内容のPVを自動で作成するというのが動的PVCと呼ばれるものです。

動的PVCが使えるかどうかは、SCでその機能が使えるかどうかとなります。

SCの機能を決めているのは、プロビジョナーと呼ばれるプラグインです。


■プロビジョナー一覧はこちら

 https://kubernetes.io/docs/concepts/storage/storage-classes/


プロビジョナーの一覧を見ると、基本的にはマネージドKubernetes毎に提供されている

プロビジョナーを使ってくださいねとなっています。

そのため、手動で構築したKubernetesでは機能として動的PVCは備えてはいません。


と、いうことでどうやったらこの機能を手動で構築したお手製Kubernetesに組み込んでいくのか

というお話です。


じつはKubernetesノードに接続したNFSサーバーを使用して動的PVCが利用可能なSCを作成可能

にしてくれる「nfs-cient」というものがあります。

こちらの導入は意外と簡単に行えますので、次回の記事でやっていきたいと思います。


2021年11月26日金曜日

俺とkubernetesと時々vSphere -ServiceのLoadBalancerタイプその2-

 このブログは、コンテナのオーケストレーターであるkubernetesについて

自分の知識をまとめることを目的として記事を書いています。

もともとなが~くvSphereのあれやこれやに携わってきたのでvSphereとの類似点や

相違点についてもちょっと混ぜていけたりしたらいいかなぁとかも思っています。


前回、ServiceのタイプLoadBalancerは手動で作っただけのkubernetesでは使えないこと、

このServiceと連携してくれるLoadBalancerが必要となってしまうことをお話ししました。


今回ですが、kubernetesの外にあるLoadBalancerと連携するのではなく、kubernetes上に

LoadBalancerを用意して、ServiceのタイプLoadBalancerを動かしてしまえるMetalLBを

導入してみたいと思います。


MetalLBの公式はこちら

https://metallb.universe.tf/


公式に案内されていることをやれば動いてくれます。

早速作ってみましょう。


まず、MetalLBで払い出してもらうIPアドレスのレンジを決めます。

今回は192.168.0.200-192.168.0.210としました。

以下が設定となるConfigMapのyaml内容です。

configmap.yml

----

apiVersion: v1

kind: ConfigMap

metadata:

  namespace: metallb-system

  name: config

data:

  config: |

    address-pools:

    - name: default

      protocol: layer2

      addresses:

      - 192.168.0.200-192.168.0.210

----


インストールをしていきます。

MetalLB用のnamespaceを作成するyamlがあるので使用して作成します。

kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/v0.9.3/manifests/namespace.yaml


名前空間ができているはずなので、kubectl get nsで名前空間を確認してみます。

NAME              STATUS   AGE

----

default           Active   37d

kube-node-lease   Active   37d

kube-public       Active   37d

kube-system       Active   37d

metallb-system    Active   53s ※新しく作成された名前空間

----


MetalLBを作成します。

kubectl apply -f  https://raw.githubusercontent.com/metallb/metallb/v0.9.3/manifests/metallb.yaml

kubectl apply -f configmap.yml

kubectl create secret generic -n metallb-system memberlist --from-literal=secretkey="$(openssl rand -base64 128)"


これでMetalLBが作成されています。

先ほど作成した名前空間「metallb-system」を指定してPodを見てみると


kubectl get pod,svc -n metallb-system

NAME                            READY   STATUS    RESTARTS   AGE

pod/controller-fb659dc8-nf5xp   1/1     Running   0          9m34s

pod/speaker-5km2t               1/1     Running   0          9m34s

pod/speaker-7gkzv               1/1     Running   0          9m34s

pod/speaker-gbx4d               1/1     Running   0          9m34s


このようにMetalLB用のPodが作成されているのがわかります。

それでは、ServiceのタイプLoadBarancerを作成して、外部アクセス用のIPアドレスが割り当てられるか見てみましよう。

前回使用したServiceを作成するのですが、確認用のPodも作成しようと思います。

今までの流れだと2個のyamlを使用していましたが、実はyamlは「---」を使用して一つにまとめることができます。

具体的には以下のような形となります。


pod.yaml

---

kind: Pod

apiVersion: v1

metadata:

  name: test-pod

  labels:

    site: test

spec:

  containers:

  - image: nginx

    name: nginx-container

---

kind: Service

apiVersion: v1

metadata:

  name: test-svc-1

  labels:

    app: test

    site: test

spec:

  type: LoadBalancer

  ports:

  - port: 80

    protocol: TCP

    targetPort: 80

  selector:

    site: test

---


ではこちらのファイルを元に作成を行ってみましょう。


kubectl apply -f pod.yaml

pod/test-pod created

service/test-svc-1 created


このように、PodとServiceが作成されていることがわかります。

MetalLBのyamlを使用して導入した際にも同じように複数のリソースを作成した出力結果

が出てきたと思いますが、あちらで使用したyamlファイルにも同様に複数のリソースを

1つのyamlにまとめていたからということです。


では、PodとServiceの状態を見てみましょう

kubectl get pod,svc

NAME           READY   STATUS    RESTARTS   AGE

pod/test-pod   1/1     Running   0          61s


NAME                 TYPE           CLUSTER-IP      EXTERNAL-IP     PORT(S)        AGE

service/kubernetes   ClusterIP      10.96.0.1       <none>          443/TCP        37d

service/test-svc-1   LoadBalancer   10.100.102.86   192.168.0.200   80:32383/TCP   61s


どうでしょう、作成したService「test-svc-1」にEXTERNAL-IPが割り当てられていると思います。

ここでは、tcp:80番で192.168.0.200にアクセスした場合にPodに転送されるようになっているはずです。

実際に通信可能な作業PCなどからブラウザでhttpでの通信をしてみてください。

nginxのデフォルトページが表示されると思います。


無事、ServiceタイプLoadBalancerが利用可能になりました。

これにより、IngressによるL7通信制御などもnginxのコントローラーを導入するとことで利用が

可能となり、やれることの範囲が広がっていきます。


ここで、タイトルにある時々vSphereのvSphere部分を無理やり書いてみると、vSphereのTanzuでは

この部分はNSX、HAproxy、Aviのどれかを選んで構築することになる部分となります。

VCとESXiだけではロードバランサーの役割はさすがに果たせないので仕方ない部分だと思いますが、

その分構築が複雑なのとライセンスでお金かかっちゃうのがネックですね・・・


今回は以上となります。

次回は永続ボリュームに関する『そのままだとできないこと』について書きたいと思います。

2021年10月29日金曜日

俺とkubernetesと時々vSphere -ServiceのLoadBalancerタイプ-

このブログは、コンテナのオーケストレーターであるkubernetesについて

自分の知識をまとめることを目的として記事を書いています。

もともとなが~くvSphereのあれやこれやに携わってきたのでvSphereとの類似点や

相違点についてもちょっと混ぜていけたりしたらいいかなぁとかも思っています。


前回までで、Kubernetesの構築、Pod、Service、永続ボリュームの利用を説明しました。

vSphereでいうところの、ESXiをインストールしてVCを構築して統合管理を行い、ストレージ

の設定してデータストアを作成し、仮想マシンを作って起動したというところですね。


基本的なことはできるようになっていますが、自分で作ったkubernetesの場合は便利な機能が

使えない状態になっています。


例えば、ServiceにはLoadBalancerというタイプのものがあります。

これを作成してみましょう。

以下のyamlを用意し、kubectl apply -f を実行します。

---

kind: Service

apiVersion: v1

metadata:

  name: test-svc-1

  labels:

    app: test

    site: test

spec:

  type: LoadBalancer

  ports:

  - port: 80

    protocol: TCP

    targetPort: 80

  selector:

    site: test

---


無事作成できたように見えますが、状態を見てみると以下の様にいつまでもEXTERNAL-IPが<pending>のままです。


kubectl get svc

NAME         TYPE           CLUSTER-IP       EXTERNAL-IP   PORT(S)        AGE

kubernetes   ClusterIP      10.96.0.1        <none>        443/TCP        27h

test-svc-1   LoadBalancer   10.107.138.238   <pending>     80:31352/TCP   7s


当然外部からアクセスするIPアドレスがないので通信ができません。

このように、手動作成のKubernetesには一部機能が備わっていなくてそのままだと使えないものがあるという状態です。


今回例として挙げた、ServiceのLoadBalancerタイプですが、以下の様な動作でユーザーからのアクセスをさばいてくれます。

                                    

<ユーザー>

  →<Service:LoadBalancer>

   →<Kubernetesクラスタノードのどれか>

    →<Serviceと紐ついているPodのどれか>


つまり、ユーザーとKubernetesクラスタの間にLoadBalancerが入って、ユーザーからのアクセスをNodePortdで待ち構えるKubernetesクラスタのノードどれかに渡します。

ユーザーはLoadBalancerのIPにアクセスすればいいわけですから、KubernetesクラスタのノードのIPアドレスが変わっても特に意識することがなくなります。


勘のいい方は、えっそれって・・・と思われたかもしれません。

そうです。Kubernetesクラスタの外部にLB立ってます。

なので、手動で構築したままのKubernetesクラスタでServiceのLoadBalancerを作成しても、連携してくれるLoadBalancerがいないので、EXTERNAL-IPが<pending>のままになってしまうのです。

しかし、それをどうにかやってくれるありがたい存在があります。

その名をMetalLB、来月はこのMetalLBをどのように導入してどのように使うのかについて解説したいと思います。


ちなみに、マネージドkubernetes(GCPやAWS等で提供されているKubernetes)は、ServiceのLoadBalancerが作成されると連携してLoadBalancerが展開されます。

この辺の管理も含めて便利になっているのがサービスとして提供されているKuberneteのいいところですね。

2021年9月30日木曜日

俺とkubernetesと時々vSphere -PodとServiceの作り方-

このブログは、コンテナのオーケストレーターであるkubernetesについて自分の知識をまとめることを目的として記事を書いています。

もともとなが~くvSphereのあれやこれやに携わってきたのでvSphereとの類似点や相違点についてもちょっと混ぜていけたりしたらいいかなぁとかも思っています。


今回は前回からの続きで、Podにストレージを追加するための作業をやっていきたいと思います。

今回はちょっと登場人物が多かったり、作業を行うための準備が必要だったりで少し難しいと思います。

文章だけだと難しいと思いますので、読み飛ばして実際にyamlから物を作成してもらったほうが早いかもしれません。


Podのストレージを永続ストレージと呼び、具体的にKubernetesではそれのことをPersistentVolumeと呼びます。

仮想マシンに置き換えると、仮想ディスクに当たる部分になります。

Pod同様PersistentVolumeもyamlで作るのですが、PersistentVolume(PV)を作っていい領域がどこかそれが定義されていないと作れません。

何のことかちょっとよくわからないかもしれませんが、vSphere的に言うと仮想ディスクを作成するためのデータストアを用意しないといけないという感じです。

では、そのデータストアをどう作るかというと、StorageClass(SC)というリソースを作成してKubernetesに「この領域が使えますよ」と定義するわけです。

これで、SCで定義された領域にPVを作ることができました。

しかし、この状態は、仮想ディスクはできたけど仮想ディスクを使うのは誰かという部分が設定されていません。

その設定を行えるようにするのがPersistentVolumeClaim(PVC)です。

PVCはPVを要求するためのリソースで、どんなサイズのPVが欲しいかという内容が定義されています。

このPVCをPodのyamlに書いてあげると、PVCに要求されたサイズのPVがPodと紐づくことができます。

これは文章で読んでもあんまり理解できないと思いますので、気にせず実際に作ってみましょう。


まずはStorageClassから。

ここでは、NFSやiSCSIなどの外部ストレージ装置ではなく、ローカル領域を指定します。

以下の内容をKubernetesクラスターにvi等で作成してください。


  local-sc.yaml

  ----

  kind: StorageClass

  apiVersion: storage.k8s.io/v1

  metadata:

    name: local-sc

  provisioner: kubernetes.io/no-provisioner

  ----


続いて、作成したStorageClassであるlocal-scを指定してPersistentVolumeを作成。

以下の内容をKubernetesクラスターにvi等で作成してください。


  local-pv.yaml

  ----

  apiVersion: v1

  kind: PersistentVolume

  metadata:

    name: local-pv

  spec:

    capacity:

      storage: 3Gi

    volumeMode: Filesystem

    accessModes:

      - ReadWriteOnce

    persistentVolumeReclaimPolicy: Delete

    storageClassName: local-sc

    hostPath:

      path: /local-pv/

  ----


さらに、用意したPersistentVolumeを要求するPersistentVolumeClaimを作成します。

以下の内容をKubernetesクラスターにvi等で作成してください。


  local-pvc.yaml

  ----

  apiVersion: v1

  kind: PersistentVolumeClaim

  metadata:

    name: local-pvc

  spec:

    accessModes:

    - ReadWriteOnce

    volumeMode: Filesystem

    resources:

      requests:

        storage: 3Gi

    storageClassName: local-sc

  ----


それでは順番に、作成を行いましょう


  kubectl apply -f local-sc.yaml

  kubectl apply -f local-pv.yaml

  kubectl apply -f local-pvc.yaml


確認は以下のコマンドで


  kubectl get sc,pv,pvc


出力結果はこんな感じ


  NAME                                                   PROVISIONER                                     RECLAIMPOLICY   VOLUMEBINDINGMODE   ALLOWVOLUMEEXPANSION   AGE

  storageclass.storage.k8s.io/local-storage              kubernetes.io/no-provisioner                    Delete          Immediate           false                  82s 

  

  NAME                                                        CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                    STORAGECLASS   REASON   AGE

  persistentvolume/local-pv                                   3Gi        RWO            Delete           Bound    default/local-pvc        local-sc                18s

  

  NAME                                   STATUS    VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS               AGE

  persistentvolumeclaim/local-pvc        Bound     local-pv                                   3Gi        RWO            local-sc                   3s


と、ここまでで仮想マシンで言うと仮想ディスクができたわけです。

しかしこのままでは、この仮想ディスクを使う仮想マシンが誰かという設定がされていません。

そこでもう一つyamlが必要となります。


どんなyamlが必要となるかというと、Podのyamlです。

Podのymalにこのpvcを組み込むことで、PodがようやくPVCを使えるようになります。

前回作ったnginxのPodにくっ付けて新しいPodのyamlファイルを作ってみましょう


  nginx-pv.yaml

  ----

  kind: Pod

  apiVersion: v1

  metadata:

    name: nginx-pod-2

    labels:

      app: wcp-demo

  spec:

    containers:

    - image: nginx

      name: nginx-container

      volumeMounts:

      - name: nginx-pv

        mountPath: /pv

    volumes:

    - name: nginx-pv

      persistentVolumeClaim: 

        claimName: local-pvc

  ----


これを作成するとPodが付いています。


  kubectl apply -f nginx-pv.yaml


しかし、実際にPVはどこにできているかというと、Podが動いているnodeの/local-pv/になります。

確認するには"kubectl get pod -o wide"を実行するとわかります。


Podにくっ付けられたPVは本当にくっついているか確認します。

Podの内部に入って/pvディレクトリがあるか確認しましょう。


  kubectl exec -i -t pod/nginx-pod-2 /bin/bash


  cd /pv


ディレクトリ/pvに移動することができました。

ダミーファイルを作成してみましょう。


  dd if=/dev/zero of=2G.dummy bs=1M count=2048


ファイルができたら、exitでPodから抜けます。

Podが動作しているノードへログインして、/local-pv/にファイルがあることを確認してください。


では、以下のコマンドでPodを削除してみましょう。


  kubectl delete -f nginx-pv.yaml


PVをくっ付けていないPodの場合、先ほど作成したダミーファイルも一緒に消えます。

もう一度同じyamlでPodを作成しなおしてみましょう。


  kubectl apply -f nginx-pv.yaml


Podにログインしてlsで/pvを確認するとダミーファイルが残っていることが確認できるはずです。


今回はここまでとなります。

2021年8月31日火曜日

俺とkubernetesと時々vSphere -作ってみよう、PodとService-

このブログは、コンテナのオーケストレーターであるkubernetesについて

自分の知識をまとめることを目的として記事を書いています。

もともとなが~くvSphereのあれやこれやに携わってきたのでvSphereとの類似点や相違点についてもちょっと混ぜていけたりしたらいいかなぁとかも思っています。


今回は前回説明した、Pod、Service、Podへ外部ストレージ領域の追加を実際にどうやったらいいのかという説明をしたいと思います。

まずはPodとServiceについて解説します。


Kubernetesクラスタ内部で何かを作成するとき、コマンドラインでの作成も一応できるのですが基本はymalファイルというものを使います。

yamlファイルとはなにかというと、これから作りたいものの設計図です。


yamlには大きく分けて4つのセクションがあり、それぞれ以下のような役割を持ちます。


  apiVersion:リソース作成時に使用するAPIのバージョンの設定

  kind:どの種類のリソース(Pod、Service等)を作成するかの設定

  metadata:リソースを一意にするための設定(名前、namespace、UID等が該当)

  spec:リソースの状態を設定(Podなら開放するportやCPU、メモリのサイズ等)


実際のPod、Serviceのyamlの例を見てみましょう。

Pod用ymalファイルの例

==========

---

kind: Pod

apiVersion: v1

metadata:

  name: nginx-pod

  labels:

    app: wcp-demo

spec:

  containers:

  - image: nginx

    name: nginx-container

==========

Kind → Podを作成するのでPodを記載

apiVersion → Podが所属しているAPIがv1であるため、v1を記載

metadata → nameには一意となる名前を設定、labelsにはPodに付与するラベル(app: wcp-demo)を設定

spec → containersはコンテナに関する設定を行うフィールド

        imageで作成するコンテナのイメージを指定、nameにはコンテナの名前を設定


Service用ymalファイルの例

==========

---

kind: Service

apiVersion: v1

metadata:

  name: nginx-svc

spec:

  type: NodePort

  ports:

  - port: 80

    protocol: TCP

    targetPort: 80

  selector:

    app: wcp-demo


Kind → Serviceを作成するのでServiceを記載

apiVersion → Serviceが所属しているAPIがv1であるため、v1を記載

metadata → nameには一意となる名前を設定

spec → typeで作成するServiceのタイプを設定

           ※ここでは、クラスタのノード全てでアクセスを受け取れるNodePortを指定

        portsはポートに関する設定を行うフィールド

        portはportからtargetPortへのマッピングを行います。利便性のため基本的にはtargetPortと同じ値を入れます。

        protocolは使用する通信のプロトコルを指定

        targetPortはコンテナに転送するportを指定

        selectorは一致するラベルを持ったPodを探し転送先として認識します。

==========


このようなyamlを用意するわけですが、どのようにこのファイルからPodやServiceを作成するのかというと

以下のコマンドを使用します。


  kubectl apply -f <yamlファイルまでのパス>


ここではAdministratorのデスクトップに配置したyamlを使用して実行した例を紹介します。


■Podの作成

  PS C:\Users\Administrator> kubectl apply -f "C:\Users\Administrator\Desktop\nginx-pod.yml"

  pod/nginx-pod created


■Serviceの作成

  PS C:\Users\Administrator> kubectl apply -f "C:\Users\Administrator\Desktop\nginx-pod-svc.yml"

  service/nginx-svc created


作成したPodとServiceはkubectl get <確認したいリソース> で確認可能です。

複数のリソースを確認したい場合は、「,」で区切ります。


■Podの確認

  kubectl get pod

  NAME        READY   STATUS    RESTARTS   AGE

  nginx-pod   1/1     Running   0          14m


■Serviceの確認

  kubectl get service

  NAME        TYPE           CLUSTER-IP    EXTERNAL-IP     PORT(S)        AGE

  service/nginx-svc    NodePort    10.108.236.173   <none>        80:32074/TCP   4s


■PodとService両方確認

  kubectl get pod,svc

  NAME            READY   STATUS    RESTARTS   AGE

  nginx-pod       1/1     Running   0          14m


  NAME                 TYPE        CLUSTER-IP       EXTERNAL-IP     PORT(S)        AGE

  service/nginx-svc    NodePort    10.108.236.173   <none>          80:32074/TCP   4s


ここで、Serviceの PORT(S) に表示されている80:32074が<Podへ転送するport>:<ユーザーがアクセスするport>

となります。

<ユーザーがアクセスするport>は自動で付与されるため環境によって異なります。


ServiceのタイプがNodePortというKubernetesクラスタを構成しているノードの、どのIPアドレスどれでも

アクセス可能なServiceとなっているため、どれか一台のIPアドレスに<ユーザーがアクセスするport>を

くっつけてブラウザからhttpでアクセスしてみましょう。


  例

   http://192.168.0.100:32074


nginxのページが確認できたと思います。


今回はここまでとなります。

次回は、このpodを削除してもデータが残せるよう永続ボリュームをくっつくけるための内容を説明したいと思います。


2021年7月30日金曜日

俺とkubernetesと時々vSphere ーKubernetesで扱うことになるPod、Service、StrageClassやPersistentVolume、PersistentVolumeClaimってなんでしょう?ー

このブログは、コンテナのオーケストレーターであるkubernetesについて

自分の知識をまとめることを目的として記事を書いています。

もともとなが~くvSphereのあれやこれやに携わってきたのでvSphereとの類似点や相違点についてもちょっと混ぜていけたりしたらいいかなぁとかも思っています。

今回は前回構築したkubernetesクラスターに構築するPod(コンテナ)、Service(Podのネットワーク)、

Podのストレージ(Strageclass、PersistentVolume、PersistentVolumeClaim)についての説明をしたいと思います。


1.Pod

 Podは実際にアプリケーションが動作する場所(vSphereで言うと仮想マシン)となりますが、Kubernetes上で動くコンテナといったところです。

 Pod中には複数のコンテナを展開することもできますが、基本系は1Pod1コンテナですので、最初はPod=コンテナと思っても大丈夫だと思います。

  Pod単体でアプリケーションを起動することはできますが、外部との通信はできません。

 また、Pod内部にデータが保存されている場合Podを停止(Kubernetesの世界ではPodの停止=Podの削除)すると保存していたデータも一緒に消えてしまいます。

 その問題点を解消するのが以下の2つになります。


2.Service

 ServiceはPodとPodを接続したり、Podと外部の接続を行うPod用のネットワークです。

 Kubernetes内部でのみ使用する場合(外部とのやり取りが発生しない)や外部と通信する場合等の用途に合わせてタイプを指定することができますが、外部と通信を行う場合はどのように外部との中継を行うか種類が選べます。


   内部通信用のService

    ClusterIP


  外部通信用のService

   ExternalIP →任意のマスターorワーカーを指定して外部からPodへ通信を行う

   NodePort →Kubernetesクラスタ内のノードどれにアクセスしても外部からPodへ通信が可能

   Loadbarancer →外部ロードバランサが利用できるクラウドプロバイダ用ですが、ロードバランサーを自動で作成して連携してくれます。※そのため自分で作成したKubernetesクラスタだとそのままでは使えません。


3.Podのストレージ

 Pod内の動作によって出力されたデータなどを保存しておきたい場合、Pod外部にデータを保存する必要があり、具体的には以下の作業が必要です。


     Podで使えるストレージを定義(vSphereで言うとデータストアに近い)

   →定義されたストレージにPod用の領域を作成(vSphereで言うと仮想ディスクに近い)

    →Pod用のの領域をPodに紐付ける(しいて言えば、仮想マシンの設定と編集でディスクを手動追加するイメージ)


 この作業はKubernetes的な言い方をすると以下の様になります。


   StrageClass(SC)を作成する。

    →PersistentVolume(PV)を作成する。

    →PersistentVolumeClaim(PVC)を作成する。


これらをくっ付けて、Pod内のアプリケーションへ外部からアクセスしたり行わせた処理を保存したりできるようになるのですが、PodもServiceも作成しただけでは、お互いに紐ついてくれません。

これらをくっ付けるために必要なラベルとラベルセレクターという存在があります。

また、ストレージもそのままでPodと紐ついてくれません。

こちらも、yamlというPodやServiceを作る際に使用する設計書の様なものを利用する必要があります。


というわけで、次回はこれらの作り方やお互いが利用しあえるための設定、yamlの書き方について説明したいと思います。


2021年6月25日金曜日

俺とkubernetesと時々vSphere ー構築完了時点でのkubernetesクラスターの状態についてー

このブログは、コンテナのオーケストレーターであるkubernetesについて

自分の知識をまとめることを目的として記事を書いています。


もともとなが~くvSphereのあれやこれやに携わってきたのでvSphereとの類似点や相違点についても

ちょっと混ぜていけたりしたらいいかなぁとかも思っています。


今回は、前回構築したkubernetesクラスターはどのような状態になっていて、何ができるのかについて

解説していこうと思います。


まず、前回マスターノードとワーカーノードを作成しました。

マスターノードとワーカーノードには、kubernetesクラスターを構成するためのコンポーネントが配置

されています。


どのようなものが配置されているかというと以下となります。


[マスターノード側]

 ・kube-apiserver

 ・etcd

 ・kube-Controller-manager

 ・kube-scheduler

 ・kube-proxy


[ワーカーノード側]

 ・kubelet

 ・kube-proxy


kube-apiserver

 kubernetesクラスターには当然ユーザーからの処理(API)を受け付けて指示を出してくれる存在です。

 すべてのコンポーネントの中心となっていて、その他のコンポーネントへ指示を出したりします。

 vSphereでいうとvCenterのvpxdみたいなやつですね。

 

etcd

 kubernetesクラスターのデータベース担当です


kube-scheduler

 Podをどこのワーカーノードで起動するか割り当ててくれます


kube-Controller-manager

 レプリケーションコントローラー等、kubernetesクラスターに存在する複数のコントローラーの

 プロセスを実行します。


kube-proxy

 各ノード上で動作するネットワークプロキシ


kubelet

 kube-apiserverから指示を受けてワーカーノード上で処理を実施するエージェント。

 vSphereでいうところのhostdみたいなやつですねこれも


上記のコンポーネント達がやり取りをしてkubernetesクラスターを成り立たせているわけですが、

これは基本中の基本操作ができるための機能しかありません。


Pod(コンテナ)やService(ネットワーク)等を作成することはできますが、Pod用のストレージとなる

PersistentVolumeを要求に従って自動で割り当てたり、外部と通信する際にロードバランサータイプの

Serviceが利用できなかったりします。


有料のサービスとして利用可能なマネージドkubernetesであれば上記の内容も利用できますが、

できれば、無料で使ってどんなものか自分で確認してみたいですよね・・・

それぞれ以下を導入すれば利用が可能となります。

 ・MetalLB

 ・Kubernetes NFS-Client Provisioner


なお、kubernetesにPodやServiceを作る際GUI操作という物はなく、基本コマンドになります。

実際にコマンドラインだけで作成することも可能ですが、ymalファイルというテキストベースの

設計書を事前に作成して、そのファイルを指定してコマンドを実行するという感じですね。


というわけで、次回はyamlの書き方や実際にPodやServiceを作成してそれをどう確認するのか

について解説したいと思います。


2021年5月31日月曜日

俺とkubernetesと時々vSphere ーkubernetesクラスターってどう組むのよ?ー

 このブログは、コンテナのオーケストレーターであるkubernetesについて

自分の知識をまとめることを目的として記事を書いています。

もともとなが~くvSphereのあれやこれやに携わってきたのでvSphereとの類似点や相違点についてもちょっと混ぜていけたりしたらいいかなぁとかも思っています。


今回はkubernetesクラスターの構築についてやっていこうと思います。


まず準備ですが、ESXiやWindowsのようにkubernetesのインストールイメージというものがあるわけではありません。

LinuxOSを用意して、そこにあれやこれやと設定を行いkubernetes用のノードとしていくことになります。


kubernetesクラスターはざっくり言ってしまうと、システムの管理を担当する役割(マスターノード)、ユーザーが作成したPod(コンテナ)を動かす役割(ワーカーノード)の2種類があります。

マスターノードがコントロールプレーン、ワーカーノードがデータプレーンというとイメージが付きやすいでしょうか。


どちらも同じものを入れて構築していくのですが、最後にマスターノードとして構築するコマンドを実行するかマスターノードにワーカーノードとして追加するコマンドを実行するかだけが違います。


では、どういう手順になるかを説明していきましょう。


1.まずLinuxOS


    ここは、好きなLinux系のOSを用意してください。

    私はCentOSの7を3台(マスターノード1台、ワーカーノード2台)使用して作っています。


2.Dockerの構築をする


    kubernetesではコンテナをPodという形で利用しますが、ではそのコンテナを動かすための技術はどうしているのかというと、Dockerを使います。

    というわけで、Dockerの構築+kubernetes用の追加構築という流れになります。

    

    2-1 SElinuxの無効化

    

      # setenforce 0

      # sed -i "s/SELINUX=enforcing/SELINUX=disabled/" /etc/selinux/config


    2-2 firewallの無効化


      # systemctl stop firewalld



    2-3 Dockerに必要なパッケージ喉乳


      # yum install -y yum-utils device-mapper-persistent-data lvm2


    2-4 Dockerのyumリポジトリ追加

    

      # yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo


    

    2-5 Dockerの導入

    

      # yum install -y docker-ce-19.03.5-3.el7.x86_64


    2-6 Docker起動

  

      # systemctl start docker

      # systemctl enable docker


3.kubernetesクラスターの構築


    マスターノードとワーカーノードを作成する。

    途中まで一緒。


    3-1 スワップを停止


     # swapoff -a

     # sed -i '/swap/s/^/#/' /etc/fstab


    3-2 kubernetesを構築するツールkubeadmのyumリポジトリを追加。


     # vi /etc/yum.repos.d/kubernetes.repo


     以下の内容を記述する


     [kubernetes]

     name=Kubernetes

     baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64

     enabled=1

     gpgcheck=1

     repo_gpgcheck=1

     gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg


    3-3 kubeadmを導入する


     # yum install -y kubeadm


    ここからマスターノードとワーカーノードで作業が変わる。

    まずはマスターノードから


    3-4 マスターノードとしての構築

   

     # kubeadm init --apiserver-advertise-address=マスターノードのIP --pod-network-cidr=10.244.0.0/16


       ※--pod-network-cidrはkubernetesで使用する、Pod用の内部ネットワークに

         使うものによって変わってくる。

         ここでは基本となるflannel用のレンジを指定している。


     コマンドの処理が終わると、ワーカーノードを追加するためのコマンド「kubeadm join ~」が

     表示されるのでメモ帳などにコピーしておく。

     あとから出力させるコマンドもあるが、面倒なのでここでちゃんとメモっておくのがおすすめ。


    3-5 kubernetes用コマンドkubectlを使うための処理


     # mkdir -p $HOME/.kube

     # sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config

     # sudo chown $(id -u):$(id -g) $HOME/.kube/config


    これでマスターノードにはなった。

    それでは、マスターノードにワーカーノードを追加する

    マスターノード構築時に出力されたコマンドを使用する。

    

     # kubeadm join <マスターノードのIPアドレス>:6443 --token <トークン> --discovery-token-ca-cert-hash <証明書ハッシュ>    

    これでマスターノードとその管理下にワーカーノードが追加された。

    各ノードのステータスを見てみよう


     # kubectl get node


    状態がRedyとなっていないとおもう。

    これは、ノードとしては出来上がったけど、内部で使用するPod用のネットワークができていないため。

    先ほどの、--pod-network-cidr=10.244.0.0/16はあくまで「Pod用のネットワークとしてこのレンジを使います」

    という設定で、実際にそこを使ってPod用のネットワークを実装するところまではやらない。

    

    なので、以下のコマンドを使い、Pod用のネットワークを使えるようにします。


     # kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml

    

    再度、以下のコマンドで状態を確認するとRedyとなっている。

    

     # kubectl get node


これでkubernetesクラスターの構築は一応完了です。

次回は、構築した状態のkubernetesはどういう状態になっているのかについて解説します。

2021年4月30日金曜日

俺とkubernetesと時々vSphere ーまずはコンテナについてからー

 このブログは、コンテナのオーケストレーターであるkubernetesについて

自分の知識をまとめることを目的として記事を書いています。

もともとはなが~くvSphereのあれやこれやに携わってきたのでvSphereとの類似点や相違点についてもちょっと混ぜていけたりしたらいいかなぁとかも思っています。


まずは基本的な解説から行っていこうと思いますが最終的には、ネットワークポリシー等にも触れていきたいと思います。


今回は、kubernetesに入る前にコンテナとは何かについて軽く解説します。

kubernetesはコンテナの技術を利用しているので、軽くでも知っておくと理解がしやすいかと思います。


◆コンテナについて


  まずコンテナですが、難しく言うとLinux OSのカーネルを使用して複数のアプリケーションを独立して利用する。

  こんな感じになると思います。


  『Linux OSのカーネルを使用して』ここは問題ないと思います。

  『複数のアプリケーションを』ここも問題ないと思います。

  『独立して利用する』ここです、『独立って』どういうこと? となると思います。私はそうなりました。


  実際に使ってみて理解した内容を簡単な言葉で表現すると以下になります。


  『LinuxOSのカーネルを分身させて、分身をアプリケーションに使わせる』


  どういうことかといいますと、ふつうのLinuxOSであればnginxを入れてSQLを入れると1つのLinuxOS上で2つの

  アプリケーションが動くことになります。

  当然、2つのアプリケーションは同じIPアドレスを共有する形となります。


  コンテナ技術を使うと、2つのアプリケーションは1つのLinuxOS上にで動いてはいるものの、お互いに一緒のLinuxOS

  ではなく別々のLinuxOS上で動いているとだまされるわけです。

  どうやってだましているのかというと、LinuxOSのカーネルを分身させてその分身をアプリケーションに使わせているとなります。


  なので、コンテナでnginx、SQLを使うとそれぞれIPアドレスを持つ独立したLinuxOS上で動作していると言えるわけです。


◆コンテナはどうやってLinuxOS上に展開されるのか


  コンテナはイメージという、LinuxOSとアプリケーションがセットになった状態を利用して展開します。

  普通のOSだとまずハードにインストールしてアプリケーションをインストールすることになると思いますが、

  そのOSインストールとアプリケーションインストールが終わった状態からはじめられるということです。

  

  LinuxOSとアプリケーションのセットというとそこそこ容量が大きいんじゃないの?

  と思うかもしれませんが、じつはLinuxOS部分はコンテナを動かすホストOSの物を利用して使うので

  イメージには含まれずとても軽量です。

  

  で、そのイメージってどこにあるのかというと、DockerHubというところにアプリの公式が用意してたり、

  個人がアップロードして公開しているものがあるのでそれを使うのが基本となります。

  もちろん、イメージを1から作って使うこともできます。

  

  なのでどこかしらからダウンロードしてくることになるのですが、1度ダウンロードしてローカルにあるものは

  ローカルから使うのでダウンロードも各イメージ毎に最初の一回のみとなります。

  


◆コンテナのネットワーク


  コンテナにもIPアドレスが付くと書きましたが、そのIPで通信できるのはあくまで内部。

  コンテナ同士でのみ有効となります。

  外部にある作業用の端末などからはそのIPアドレスではアクセスできません。

  

  ではどうするかというと、コンテナを起動するときにホストOSのポートとコンテナのポートをくっ付けて

  『ホストOSのポート8080に届いた通信はコンテナAのポート80に転送する』というルールを作成します。

  これはiptablesでNATをしようしています。

  なのでiptablesが動いてないとちゃんと動いてくれません。

  気を付けましょう(n敗


◆コンテナのストレージ


  コンテナを起動させてファイルを内部に作成したりすることは可能です、コンテナを削除すると当然その

  データも削除されます。

  そりゃぁそうでしょうということなのですが、コンテナって基本的には作って壊してを繰り返すものなので

  そのたびにデータがなくなってしまうと困ります。

  

  そこで、コンテナのデータを外部で保存しましょうという仕組みがあります。

  簡単に説明するとホストOSのローカル領域やストレージ装置のディレクトリをコンテナにくっ付けるイメージです。

  

以上でものすごく簡単にコンテナってどんな感じのものなのかの説明を終わります。

次回からは、コンテナオーケストレーターkubernetesって何なの? コンテナのオーケストレーションってどういうこと?

といった内容を書きたいと思います。

2021年3月31日水曜日

ネットワークの情報収集に利用するニュースサイト

2020年から始まってすでに1年以上続くCOVID-19。こうなる前は、当分在宅勤務なんてそれほど普及しないだろうと思っていましたが、今では、リモートワークが推奨される世の中になりました。リモートワークで注目度が高くなっているのがネットワークとセキュリティかなと思います。日々の情報収集で利用しているサイトをまとめてみました。


<日本語記事サイト>

@IT

 Master of IP Network 

 https://www.atmarkit.co.jp/ait/subtop/network/

 Security & Trust 

 https://www.atmarkit.co.jp/ait/subtop/security/ 

business network.jp

 https://businessnetwork.jp/

 

特に最近よく見ている気がするのは、business network.jpです。サイトテーマが”「通信」の力でビジネスを進化させる”とある通り、ネットワーク関連記事が充実しているのでネットワークに興味がある人にはおすすめのサイトです。


<英語記事サイト>

NETWORK WORLD

 https://www.networkworld.com/

sdxcentral

 https://www.sdxcentral.com/

FIERCE TELECOM

 https://www.fiercetelecom.com/

 

英語サイトだと最近はsdxcentralが面白いような気がします。


ちょっと前まではSD-WANをよくみた気がしますが、在宅勤務が始まった昨年夏くらいから徐々にSASEをよく見かけるようになった気がします。どちらも一度ちゃんと調べてみようかと思います。それでは。

久々にVyOSを調べてみた

先日、ネットワークの検証をしていた時の話。。

検証時にVyOSを利用していたら、利用したい機能が

OSバージョン1.1.8では搭載されていないことが判明。

久々にVyOSのサイトをのぞきに行ったら、なんとびっくり。

サイトがだいぶ変わっとる。。。

サイトはこちら。

VyOS  

https://vyos.io/

VyOS、だいぶ変わりましたね。

今回、久々にサイトを見て知った新たな発見。。 


その1:LTS版ソフトウェア提供が有償に、、

 個人利用でも年間$660、、。私には高いわ。。

 無償は、ローリング版のみ。

 このブログ投稿時の最新は、安定版が1.2.6、ローリング版は1.4。

 検証で簡単に試すくらいならローリング版でも十分かなと思います。

   ちなみにバージョン1.1.8もまだダウンロードできるみたい。

 ローリング版が嫌な場合は、こっちのほうが良いかも。

   https://support.vyos.io/en/downloads/files/vyos-1-1-8-iso

その2:有償サポートも登場、、

 OS+サポートがセットになった年間サブスクリプションもできたのですね。

 https://vyos.io/subscriptions/support/


その3:ドキュメントが充実した気がする。。

 勘違いかもしれませんが、数年前よりも情報がかなり多くて説明が増えた気がします。

 VyOSのドキュメント

 https://docs.vyos.io/en/latest/index.html

 OS変更履歴

 https://docs.vyos.io/en/latest/changelog/index.html

 バージョン1.2以降では、ルーティングエンジンにFRRoutingを使用しているそうです。

 知らなかった。。

 VyOS KB

 https://support.vyos.io/en/kb

 設定のサンプル(ブループリント)
 https://docs.vyos.io/en/latest/configexamples/index.html


その4:当たり前ですが)バージョンアップで機能増えてる。。

 新しいバージョンだと機能も増えますよね。。

 VyOS、PPPoEサーバーやIPoEサーバーになれるのですね。知りませんでした。

 そのうち、試してみたいと思います。

 https://support.vyos.io/en/kb/articles/pppoe-server

 ロードマップも公開されてます。計画にはSD-WANも、、。

 今後も新たな機能が追加されそうですね。

 https://vyos.io/roadmap/

 

その5:フォーラムが活発。。

 わからないことを聞く、トラブル時のヒントを探るときに良さそう。。


その6:認定ができてた

 年間利用料を払ってたら試験費無料、払ってないなら$200

 どんな問題がでるのか興味はあります、、。

 https://vyos.io/certification/


まとめ

 VyOS、まだまだ人気あるのかなと思いました。

 嬉しいことにドキュメントはかなり充実した気がします。

 今回ふらっとサイトを見てみたら、

 PPPoEサーバーなど知らなかった機能を発見できてよかったです。

 開発による機能追加は続いているようなので、今後もチェックしたいと思います。


余談

 検証時やちょっとしたときにあると便利なソフトウェアルーター。

 今までとりあえずVyOSで、、と思い利用していましたが、

 VyOS以外にもソフトウェアルーターっていくつかありますよね。

 今後はVyOSだけでなく、FRRouting、SEILなど他のソフトウェアルーターも

 試してみたいと思います。

 FRRouting

https://frrouting.org/

 IIJ SEIL(有償ですけど。Amazonで売ってます。)

https://www.seil.jp/product/x86ayame.html

それでは。

vSphere 7について調べてみよう その6(HAProxyを利用したvSphere Tanzuについて)

 今回は、vSphere 7 Update1で可能となったHAProxyを使用したvSphere Tanzu

についてのお話となります。


いままでは、vSphere Tanzuを利用するにはNSX-Tが必要となっておりその分の

リソースとライセンス費用を別途用意しなくてはなりませんでした。

しかし、HAProxyを使用する場合はvCenterとESXiのみで構築が可能となります。


詳細はマニュアルをどうぞ

 https://docs.vmware.com/jp/VMware-vSphere/7.0/vmware-vsphere-with-tanzu/GUID-152BE7D2-E227-4DAA-B527-557B564D9718.html

  →vSphere with Tanzu のネットワーク

   →vSphere ネットワークと HAProxy ロード バランシングを使用して スーパーバイザー クラスタ を設定するためのシステム要件およびトポロジ


   ※なぜか、マニュアルの中のリンクをたどると表示してくれないので、pdfをダウンロードした方が良いと思います。


マニュアルの内容を簡単にですが説明すると以下のような流れになります。


1 分散仮想スイッチを作成し以下のポートグループを用意する

   ・管理用ポートグループ

   ・1つ目のワークロード用ポートグループ(スーパーバイザークラスター(SCP)で使うネットワーク)

   ・2つ目のワークロード用ポートグループ(Tanzu kubernetes Cluster(TKC)のノードで使うネットワーク)


   検証等するのであれば、管理用とワークロード用のネットワークを/24で2つ用意し、ワークロード用のネットワークは分割して使うのがいいと思います。

   ポートグループとして用意するわけではありませんが、SCPやTKCのVIPなどとなるロードバランサー用IPレンジも必要となります。

   VC1台、ESXi4台の例としては以下の様な割り振りです。

   

   管理用(192.168.1.0/24)

    VC 192.168.1.10

    ESXi1~ESXi4 192.168.1.11~192.168.1.14

    HAProxy 192.168.1.20


   ワークロード用(192.168.10.0/24)

    ロードバランサー用IPレンジ  192.168.10.144/28

    1つ目のワークロード用ポートグループ 192.168.10.160/28

    2つ目のワークロード用ポートグループ 192.168.10.192/28


    ※/28としていますが、あくまで範囲を指定するだけの用途となりサブネットが/28で設定する必要があるわけであありません。


2 コンテンツライブラリの作成を行い、TKCのノードとして使用するOVAのダウンロードをしておく


3 OVAでHAProxyをデプロイする


4 ワークロードの有効化をする


5 名前空間を作成する

   →作成時に名前空間で使用するネットワークはnetwork-2(2つ目のワークロード用ポートグループ)を指定する。


6 yamlからTKCの展開を行う


これで成功すれば構築完了です。

ですが、そのままだとPodの作成はできるものの、deploymentで展開をしようとするとエラーとなります。

実は、構築した状態ではPod Security Policy(PSP)によって作成できないようになっています(権限がない状態)。

そのため、権限の変更を行ってあげる必要がありますが、この辺の操作もすべてkubernetesの知識を元に行うことになります。


また、NSX利用時と異なる点もあります。

ワークロードの有効化をして名前空間を作成することはできますが、名前空間にyamlからPodの作成はできません。

ユーザーが利用するPodが展開できるようになるには、TKCの名前空間を利用する必要があります。


作るのも設定するのも現状はvSphere+kubernetesの知識と経験が十二分に必要な状態です。

あと、HAProxyに何か問題があったときどこの誰が対応してくれるのかについてはわからない(VMがサポートしてくれるのか不明)

という部分もあり、なかなか難しいなと思いました。

2021年2月26日金曜日

vSphere 7に関して調べてみよう その5 vSphere Lifecycle Manager(vLCM)

 今回は、vCenter Update Manager(VUM)の後継に当たる機能「vSphere Lifecycle Manager(vLCM)」について調べてみました。

VUM自体はESXiのパッチを管理する機能として登場し、機能拡張でゲストOSのパッチも管理する機能が追加された

ことがあったと思いますが、一瞬でその機能がなくなったのは不評だったんでしょうねぇ。


個人的には、使う人は使うけど使わない人は使わない(esxcliとかコマンドを使う)という印象。

勝手にパッチをダウンロードしてきたり、勝手に当てられたりしたら困るという印象が強いんじゃないかと思います。

設定次第なんですけどね。


では、いつもどおりVMwareのブログを読んでいきたいと思います。

https://blogs.vmware.com/vsphere/2020/04/vsphere-7-patching-lifecycle-management.html


VUMと機能違いとしては以下のようです。

 ・ホストベンダーのアドオン(OEMで追加されているパッケージ)にも対応した


 ・対応しているベンダーのファームウェアやドライバにも対応した


 ・適用単位がクラスター単位となった。


機能が追加され、クラスタ単位で統一性を保ちましょうという考え方になったようです。

今のところNSXの管理には対応していないようですね。


以前あったゲストOSのパッチ管理は、既に他の製品(WSUS等)で行うことが浸透していたこともありましたが、

ハードウェア方面は構築時のままということもあるでしょうし、この機能で確認や管理、修正が簡単に

行えるようになれば良いなとは思います。


ただ、出たての機能(安定して使えるかどうか不明)であることと、ダウンロードする場合インターネットに

つながっていないといけないのがセキュリティ的に容認されない場合が多いんじゃないかというのがネック

になってくるんじゃないでしょうか。


今月は以上になります。

2021年1月29日金曜日

vSphere 7に関して調べてみよう その4Assignable Hardware

 今回は「Assignable Hardware」について調べてみました。

ハードウェアとあるので、ハードウェアの機能を何かしら補助したり使用したり

す機能なのでしょう。


ということで、以下のVMwareブログを読んでみます。


      Assignable Hardware

       https://blogs.vmware.com/vsphere/2020/03/vsphere-7-assignable-hardware.html


chromeの翻訳機能を使うと冒頭から以下のような、具体的に何のことかよくわからないよくある感じの文章・・・

----

多種多様な最新のワークロードは、ハードウェアアクセラレータを使用して特定の機能をオフロードし、CPUサイクルを節約し、一般に多くのパフォーマンスを得ることができます。たとえば、通信業界について考えてみましょう。NICとFPGAを利用したネットワーク機能仮想化(NFV)プラットフォーム。または、仮想デスクトップインフラストラクチャ(VDI)の展開でグラフィックアクセラレーションにGPUを使用しているお客様。AI / ML空間は、アプリケーションが使用するようにイネーブルされるワークロードの他の例であるオフロードの計算にGPUをします。vSphereでハードウェアアクセラレータ(通常はPCIeデバイス)を利用するには、デバイスを仮想マシン内で実行されているゲストOSに公開する必要があります。

----


くじけそうになりますが、この下にある文章も読んでみるとこの機能が何をもたらそうとしているのかがなんとなくわかります。

何が書いてあるかというと、『今までもハードに紐ついた機能を仮想マシン等に提供することはできました。

しかし、そのようなハードに歩もついた機能を仮想マシンに利用させた場合、vMotion等が行えません。

これは、DRSでのロードバランスや、仮想マシンが動作しているESXiに何かがあって停止してしまった場合の

HAなどが使えず、同様のことを行おうと思ったときに、人の手によって作業をしなければなりません。』という感じの内容です。


今回の「Assignable Hardware」はそこにメスを入れるための機能であるようです。

今までvmxに直接書き込まれていたPCIeデバイスのハードウェアアドレスが書き込まれなくなり、代わりに仮想マシンがどのような機能を利用しているかが公開され、必要なハードウェア機能を持っているESXi同士であれば仮想マシンの移行が可能となるようです。



また、この機能を使用してNVIDIA vGPUを仮想マシンに提供できるようです。

使うためにはホストのグラフィック設定を有効にしたり、VIBの導入をしたり、NVIDIAのドライバーを設定したりと現状ではなかなか骨が折れそうな作業のようですね。


今回は以上になります。