こんにちは、Yos235です。
Tanzuの前にK8s、の前にDockerを勉強しないとということで、
古い情報の方がイイなと思ってこちらを、積読。
2015年当時のDocker話が連載されてます。
このころはまだLinux（UbuntuやCent）しか対応してないとありましたが、
Docker本家のURLをみると、
Windowsでも動きますし、いま（2021年）もガッツリ更新され続けている。
2015年からは６年経ってるので、世界は変わってるだろうなと
歴史を勉強すれば、何がうれしいのかを理解できるかなと思ってます。
こちらは現在も便利ツールとして紹介されてる＝今がわかるということで
比較してみると面白いかなと。
次は、SwarmとK8sの比較をしてみたいかな…ってことで、これか。
チラ見してみた感じだと、docker-compose終わってる、みたいな記載が
あるのですが、2020年9月から数カ月ぶりに1.28.0 (2021-01-20)が出た後
着々と更新され続けているようなので、何かあったのかな、、と。
今日は、この辺で。
こんにちは、Yos235です。
物理マシン性能があがったこと、仮想化による集約ができたことにより
サイジングというものをあまり気にしなくてもよくなったような気がするのですが、
本来持っている性能を充分に生かすことをきちんとやれている人は少ないのかな、
と思っている。
基盤売ってる側からするとたくさん買ってくれれば売り上げも上がる訳で
攻めたサイジングをすることはリスクを負ってるだけになってしまうけど、
やっぱり技術者としては「必要なものを必要なだけ用意する」ことをしないと
クラウド時代はクラウド事業者が儲かるだけで、何も良いことは無いと思う。
そういった見方をするならば、クラウド事業者とは一線を画したベンダーが
提供するサービスのほうが説得力はありそうだな、と思うところもあり、
仮想マシンのサイジングってちゃんとわかっていたほうがいいなと思うところ。
そう言っている私もサイジングが出来るわけじゃないのですが、
以下のBlogを見て少し勉強しないとな、と思った次第。
VMwareドキュメント、そういう設定があるのね、くらいの認識しかないのですが
Tanzuは、開発者にK8s管理を渡してしまえ（セルフサービス化K8s）という
発想であるがゆえに、開発者がリスクを恐れて無駄に多めのリソースを
要求することを抑制するという、インフラ側の意図を組込むためにこれがあると。
＞One of the reasons could be the avoidance of monster-VM deployment.
「モンスター仮想マシンのデプロイを回避する」という事。
なんでモンスターVMがダメなのかというと、UMAやNUMAの話になってくるので
そいつもちょっと再勉強してみると、以下のサイトが超わかりやすいサイトでしたので
ついでにご紹介。
英語よりも日本語が得意な人（笑）は、こちらをどうぞ。
こちらは本家？VMwareのサイト。
結局のところ、CPUとメモリ（データ）は近くにある時は性能がいいが
離れてしまう（バスやInterconnect経由でリモートアクセス）と遅くなるので
同じところに配置できるようなサイズにとどめておきましょう、という話。
このあたりは、イマイチつながってこないのですが、
もしかするとvSphere with Tanzuの場合は、ESXiのNUMAスケジューラに
対応できるので性能重視ならこっちだよ、の話なのかもしれない。
うーむ先は長いな…
今日はこの辺で。
こんにちは、Yos235です。
最近Horizon技術者から違うものに移行しつつあるのですが
（ていうかWVD案件がひと段落したような雰囲気？）
たんす回りを調べることが増えております。
アプリ開発者じゃないので、Tanzuは正直避けて回ってましたが
どうやらこれ、Network技術者の出番って感じです。
K8sの運用が大変って言っている人ってもしかしてこれなんですかね？
アプリ開発者には、開発に専念してもらいたいですよね、役割的に。
とりあえずTanzuとvSphereは一緒になったという事がわかったのですが、
NSX-TのLBか、HAProxyが必要という話であったのですが、
TKG1.3（25MAR2021）でいよいよAviに対応とのこと。
Inclusion of NSX Advanced Load Balancer Essentials, which provides Tanzu Kubernetes Grid users on vSphere with a Layer 4 load balancing solution for Kubernetes workloads.
対応、というか、NSX ALBのEssentialsが付属したという事みたい。
ダウンロードはこちらから。
今日はこの辺で。
こんにちは、Yos235です。
UpdateX に a とか c とかが付くようになった場合、
意外とヤバい問題があった、という事がわかります。
定期的なリリースを待たずに「こっちに差し替えてね！」という意味ですし、
今回だと2021-03-09にリリースしたUpdate2を2021-04-29に差し替えという
50日後のリリースということなので、超突貫での修正という事でしょう。
そんな時にはリリースノートを確認。。。といってもすでに置き換えられてるので
取りうる対策としては、「最新版が出てもすぐに当てない」という消極的な
自己防衛しかないんですよね。。。残念ながら。
怖いもの見たさで一応リリースノートを確認してみますと、
PR 2727885: UEFI booting of ESXi hosts might stop with an error during an update to ESXi 7.0 Update 2 from an earlier version of ESXi 7.0
→UEFIブートのマシンをアップデート変えると止まる。
PR 2745889: When you upgrade ESXi hosts by using the esxcli software vib update command, new VIBs might not be installed
→ESXCLIでアップデートするとVIBがインストールされない。
PR 2740544: Some NSX-T features might not be available after an NSX-T upgrade on ESXi 7.0 Update 2 hosts in an environment with VMware NSX-T Data Center
→NSX-Tのポートミラーなど一部機能がアップグレード後使えなくなる
PR 2747220: After an ESXi host upgrade to ESXi 7.0 Update 2, VMFS volumes fail to mount on Serial Attached SCSI (SAS) storage
→SASストレージ見えなくなる（VAAI連携しているものをアップグレードすると）
PR 2738401: Persistent volume claims (PVC) might fail because of first class disk (FCD) metadata overwrites
→（これはよくわからん…）
PR 2740977: If ESXi fails to detect the end of the TPM2 ACPI table, then ESXi hosts fail with a purple diagnostic screen
→ TPM有効な時、暗号化ACPIテーブルの最後を検出できないと、PSOD
うーむ、なかなかに致命的な問題があったんですねぇ。
何はともあれ、自己防衛（ステージングとか、誰かがチャレンジするのを横目で確認とか）が大事ですね。
今日は、この辺で。
こんにちは、Yos235です。
つづき。
＞Tanzu Kubernetes は、Kubernetes の固定型インストールです。
＞Tanzu Kubernetes クラスタは、基盤となる vSphere インフラストラクチャと統合されており、Kubernetes を実行するために最適化されています。
＞Tanzu Kubernetes クラスタは、本番ワークロードの実行に合わせて調整されます。
だから、
＞Tanzu Kubernetes クラスタは、VMware によってサポートされています。
ということかな。この辺がvSphereでK8s環境を構築するメリットですかね。
「Kubernetesクラスタをカスタイマイズしないなら、vSphereポッドを使う」
開発者がカスタマイズしたいならTanzu Kubernetes クラスタを選ぶようですが
その”カスタマイズ内容”とは、以下のところに記載があります。
図で言うとこんな感じ。ビジュアル系って大事ですよね。
今日は、この辺で。
こんにちは、Yos235です。
Tanzuは日進月歩で進化を続けておるようでして、vSphereとしての新機能も
無いわけではないものの、多くはこれにリソースを費やされているのかなと
思ったりするわけで、情報を追っかけ続けないといかんな、というところ。
前回はWebで先駆者たちが書いてくれる記事でざっくりと概要を眺めたので
次は公式ドキュメントを読もうかなということで。
ここから？って感じですが、スタート地点を間違えると迷子になっちゃうので
こういうところが大事なんですよ（凡人の言い訳）
ということで行ってみよー
これが、vSphere with Tanzuになることで
＞vSphere with Tanzu は、Kubernetes 制御プレーンをハイパーバイザー レイヤーに直接作成します。
とありますので、クラスタ管理者がやる範囲をvSphere（インフラ技術者）が兼務する、みたいな考え方なのかな。準備は「ワークロード管理」を有効にするだけ、それを「スーパーバイザークラスタ」と呼びます。
vSphere管理者は、CPU/MEM/Diskをネームスペースとして切り出して開発者に渡す、
とあるところは、仮想マシンを作って渡す、と同じように見えますね。
この開発者に渡している「仮想マシン」は、「vSphereポッド」と呼ばれる特殊な
仮想マシンであるのだとか。（ある意味わかりやすい）
（vSphereポッドって、VDIのリンククローン／インスタントクローンみたいだな）
＞vSphere ポッド は、ネットワーク スタックとして NSX-T Data Center を使用する スーパーバイザー クラスタ でのみサポートされます。
ってことはvDSだけでいいよ、って言ってたアップデートは何だったんだ。
（要調査ですな、この辺）
Tanzu Kubernetes Grid サービスは、vSphere上で動くサービスなのですが、
それで作ったKubernetesクラスタは、「Tanzu Kubernetesクラスタ」と呼びます。
なのですが、長くなったので次回に。
今日は、この辺で。
こんにちは、Yos235です。
vSphere7が2020年4月に発表されてから早１年が経過しました。
vSphereは基盤ソフトウェアなので、Enterprise Infrastructureという
Lifecycle Policyが適用されます。
General Supportで５年、Technical Guidanceで２年となるので
https://lifecycle.vmware.com/#/ によればGAが2020-04-02なので、
Supportは2025-04-02、Guideは2027-04-02。あっという間でしょうね…
ということで皆様恒例の見たくないけど見ないといけないアップデート手順はこちら。
vRSLCM＞vRLI、vROPs＞ vRNI＞vRA＞vADP-based Backup solution
＞VR、SRM＞NSX-T＞vCenter Server＞ESXi＞VMware Tools
＞Virtual Hardware＞VSAN/VMFS という順番です。
考えたくないですね、ハイ。そんなことをみんなが思うので、
クラウドサービスへの移行を考えたくなったり塩漬けしたりして
おきたくなるんですよね、わかります。
今日は、この辺で。