Vimeoで200万円請求話はミスリードなので騙されない方が良い

こういうツイートが話題になっていた。千葉県佐倉市のSound Stream sakuraというライブハウスのようだ。

田舎のライブハウスがコロナ禍で配信ライブにめちゃめちゃ力を入れたら全世界上位1%に入って200万円請求された話。 pic.twitter.com/m159xVtzuU

— Sound Stream sakura/サンスト@Go To 21st Anniversary‼︎ (@sound_sakura) December 6, 2021

要約すると、Vimeoから突然200万円請求され支払わざるを得なくなったということだ。

この文面だけ見ると、『なんていう酷いサービスなんだ、許せない！』と感じてしまうだろう。 しかしこれはフェアではない。自分の視点から見ると、Vimeo側に非は殆ど無く、むしろこのツイート主が宣伝目的で炎上させているように感じる。

何故そう言い切れるかというと、自分も全く同じ通知を受け取っているからだ。

TL;DR

• 使いすぎてもVimeoから突然200万円追加請求されることはない。段階を踏んだ警告が行われる
• 件のツイートは嘘を言っているわけではないが、恣意的な編集が行われている
• ビジネスモデルが異なるYouTube Liveと比べるのは無意味
• Vimeoの価格は決して高い部類ではなく、むしろ安い

Vimeoから使いすぎメールが来る

自分がCo-Chairとして関わっている技術カンファレンスでも、つい先日まで配信プラットフォームとしてVimeoを利用していた。しかし直近のイベントではAWS IVSに切り替えた。何故そうしたかというと、以下のようなメールがVimeoから届いたからだ。

To Whom It May Concern,

I'm reaching out as your account was flagged for heavy bandwidth usage in which consumption was within the Top 1% of bandwidth-consuming accounts and is subject to Vimeo's Fair Use Policy. I have included the term below.

Unlimited Bandwidth Fair Use Policy: Generally, we do not limit or impose additional fees for bandwidth consumption on Self-Serve accounts (i.e. the data used in order to deliver your videos to viewers). However, this policy is subject to fair use: If your aggregate bandwidth usage (across all accounts you control) is higher than 99% of Self-Serve users on our platform in any calendar month, we may, in our discretion, charge fees for excessive usage, require you to upgrade to a more suitable plan, or terminate your account(s) upon advance written notice. For more information on bandwidth and our fair use policy, please see our Bandwidth on Vimeo article.

If you would like to continue streaming at your current levels you would be required to upgrade to an Enterprise or Custom plan which is priced based on the amount of bandwidth needed.

your account was flagged for heavy bandwidth usage in which consumption was within the Top 1% of bandwidth-consuming accounts ということで、上位1%に入りましたよと。件のツイートと一緒。ただ、 おめでとうございます！ なんて表記は一言もない。この時点で脚色されている･･･

めんどくさいので以下DeepL翻訳そのままぶっ込み

一般的に、当社はセルフサービスアカウントの帯域幅消費（お客様のビデオを視聴者に配信するために使用されるデータ）を制限したり、追加料金を課したりしません。ただし、このポリシーはフェアユースの対象となります。お客様が管理するすべてのアカウントの帯域幅使用量の合計が、いずれかの暦月において、当社プラットフォーム上のセルフサービスユーザーの99％を超えた場合、当社は、当社の裁量により、事前に書面で通知した上で、過剰使用に対する料金を請求し、より適切なプランへのアップグレードを要求し、またはお客様のアカウントを解約することができます。 帯域幅とフェアユースポリシーの詳細については、「Bandwidth on Vimeo」の記事をご覧ください。

現在のレベルでストリーミングを継続する場合は、必要な帯域幅に応じて料金が設定されているエンタープライズプランまたはカスタムプランにアップグレードする必要があります。

はい。 追加料金を課したりはしない が、過剰に利用が行われた場合は 事前に書面で通知した上で 、 過剰使用に対する料金を請求し、より適切なプランへのアップグレードを要求し、またはお客様のアカウントを解約することができる。

とある。随分受ける印象が違うんじゃなかろうか。 確かに 上位1%に入ったので過剰利用分を請求する という捉え方が出来ないとは言わないが、かなり恣意的と言えるんじゃないか。 警告を無視して使い続けるユーザーに対する牽制の意味合いが強いと思われる。 いずれにせよ、いきなり請求されることはない。

ちなみにどのくらい使うとこれが来るかというと、FAQに具体的な記載があり、 月あたり2TBから3TBの転送量で上位1%になる。

警告を無視して使い続けると何が起こるの？

数回の警告後、アカウントが凍結される。

自分も初回の警告受けてからすぐに返答が出来なかったが、1週間にわたり細かく返事の催促が来るので返答した結果、凍結はされなかった。

数回の催促メールには、"何月何日までに返事しないと、申し訳ないがアカウントを凍結する" と期日まで書かれていたので、Twitterのように突然凍結されるような理不尽さは全く無く、丁寧にフォローアップしてるんだなと感じたほどだ。

実際に凍結されてしまった例をみるとこうある。

Vimeoアカウントが停止されて焦った話 -この動画は存在しません- – オレンジの国

この例だと、1ヶ月ほど警告が続き、その後アカウント凍結に至ったよう。しかし

ちょうど1か月前にこのようなメールが届いていましたが、普段英語のメールは全てスパムなので読まずに削除していました。

うーん。これはVimeoに非はなく、利用者側の問題だよね･･･。

Vimeo Enterpriseの見積額も年間200万とのことで、件のツイートと同じ。 つまり、同レベルの利用量でもアカウント停止には至ったが、それまでの利用料を遡って請求されたということはない。

同様の事例を十数件聞いているが、やはりいきなり請求されたり、過去の分まで遡及された例は一例もなかった。

で、お前の場合はどうなったの？

自分たちの場合は、年に数回のテクノロジーカンファレンスの利用だったので、そのときだけ転送量がスパイクする。しかし今後しばらくはイベントやらないから大きな負荷はかけないよと返したところ、以下のような返事があり事なきを得た。

First off, a pleasure to meet you via email and I appreciate your feedback! With that being said, I just re-ran your daily bandwidth report and can confirm that your traffic has ceased.

このあとLookerによるサマリーが送られてくるようになり、毎日の正確な転送量が分かるようになった。出来ればこれがサイトから見られれば良かったなとは思うが。

この間、特に不快になるような対応はなく、極めて真っ当なやり取りが行われたと思っている。

じゃあ何故AWS IVSに乗り換えたかというと、金額ではなくAPIの充実度合いや低遅延配信の品質を理由に決めた。見直したきっかけはこの通知だったが、決め手は金額ではない。AWS IVSはこれ単体では解決出来ず、MediaLiveやMediaPackage、S3、CloudFrontを組み合わせてようやくVimeoに近い機能が実現出来るので、それらのコストや開発コストを加味するとむしろ高くなった。

上位1%になるってことはスゴいんじゃないの？

件のメールでは、上位1%に入ったことをむしろ誇るかのような展開になっているが、実はこの上位1%には簡単に達してしまう。

3TBの転送量で上位1%になると書いたが、例えば動画を平均4Mbpsで、月に延べ32時間配信したとすると、平均同時接続数50人 程度で達してしまう。これが誇れる数字かというと･･･？ 物は言いよう ってことだね。

たぶん、自分がこれから毎日1時間、技術トークをするソロライブ配信を行ったとしてもそのくらいは行っちゃいそうだ。

Vimeo Entepriseは転送量や人数などを加味した料金体系になっているようで、年間200万程度の見積もりが来るということは、それよりは多い人数だと思われるが、平均同時接続数で500は下回る規模かなと思われる。

まあ、ピンチをチャンスに変えようという強かさは見習うべきところがあるかもしれないが、他人を下げて自分を上げるやり方はアンフェアではないか。

たったそれだけで200万!? やはりVimeoは悪、YouTube Live最高!

と思うかもしれないが、まあ落ち着け。

まず、動画配信はとてもお金がかかる という認識を持つべきだ。たとえば先ほど3TBの転送量はたった50人で達してしまうと書いたが、たとえばAWSを使って、動画配信関係なく単にインターネットへデータを転送するだけで、 $0.114/GBかかる。3TBだと4万円弱かかる。これに配信システムを動かす金額やCDN(Content Delivery Network)の金額がかかるわけで、動画配信の仕組みを自分で作ったとしても結構お金がかかるのだ。

一方でYouTube Liveは無料で配信が出来る。超人気の配信者だと同時接続数万人になるわけで、この差はなんなの？と思うかもしれない。

しかしこれはVimeoが暴利を貪っているのではなく、YouTubeが慈善事業をやっているのでもなく、単にビジネスモデルの違いだ。

YouTubeは配信者には課金をしていないが、企業からの広告やYouTube Premiumの有料課金、メンバーシップ、スーパーチャットの手数料など、主に視聴者からお金を稼ぐモデルになっている。 スーパーチャットで2億円稼ぐVTuberなどが記事になっているが、そのうち6000万円はYouTubeの取り分になっている。ちなみにスマホでスパチャした場合、さらに3割がAppleやGoogleの取り分で持って行かれる。そりゃぁ、配信者には課金しなくてもいけるよね。 Twitchも同じようなビジネスモデルだ。

3割どころか半分以上持って行くメガプラットフォームのやり方のほうがよっぽどエグいなと感じるが、プラットフォームビジネスとはこういうもの。世の中そういうふうに出来ているので不当だとは思わない。

ともかく、もしも無料でライブ配信をやりたい場合、配信者目線ではYouTube LiveやTwitchを活用するのが最善手だろう。メガプラットフォームのおこぼれに預かれる。

しかし件のツイートに対するリプライを見ると、『YouTube Liveにしましょう、無料ですよ！』なんて意見が沢山付いているが、それは無理だろう。なぜなら、YouTube Liveで有料配信を行うことは規約で禁止されており、BAN対象となるからだ。件のライブハウスはライブを有料配信しており、そういう場合は、Vimeoのような有料の動画配信サービスを使わざるを得ない。 まあ、無料のプラットフォームを使い倒して稼ぐなんていう虫の良い話があるはずもないので、当然だろう。

有料だとしても200万は高い！ Vimeoは暴利を貪っている！

と言いたくなるかもしれないが、その場合はこの言葉を口に出して読んでみよう。高いと思ったら使わなければいい。 他にも有料配信可能なプラットフォームは沢山あるので、探して引っ越せば良いだろう。

では、Vimeoの200万という数字は高いのだろうか。

例えば、ニコニコの有料生放送は、売上代金の14%が手数料としてかかる。 SPWNの場合は8%+220円のようだ(代理店によって異なるかもしれない)

仮に 3000円のライブを、300人に対して、 年間100回開催したと仮定する。すると、年間の売上高は9,000万円だ。 この売上高から、以下の金額をプラットフォームに支払うことになる。Vimeoには課金機能がないため、Tiget Liveというチケット販売サービスを組み合わせて計算してみる。また、Vimeo Enterpriseは利用量に応じて課金額が変わるようなので、今回は仮に200万円としよう。

プラットフォーム	手数料	PFへの支払い
Vimeo + Tiget Live	200万円 + 5%	650万円
ニコニコ生放送	14%	1,260万円
SPWN	8% + 220円	1,380万円

･･･これでもVimeoが高いと言えるだろうか。むしろ圧倒的に安い。自分がこの中で選べと言われたら、Vimeoが第一選択肢になるだろうというほどの価格差だ。件のライブハウスが他に乗り換えずVimeo Enterpriseへの移行をしたということは、このあたりの価格感が分かっていたからではないかと推察されるが、にもかかわらず後ろ足で砂をかける行為は全く感心できない。

なぜこの記事を書こうと思ったか

自分はもうVimeoから乗り換えてしまったので、これを書くことによって得られるメリットというのは特にない。

にも関わらず何故これを纏めたか。それは、コロナ禍により通常のイベントが行えずオンラインによる試行錯誤を余儀なくされた身として、動画配信の業界が健全に育っていくことを強く願っている。

しかし今回のように、自身の宣伝を目的として非のないプラットフォームが不当に貶められる、しかもそれが誤解を含んだまま拡散している様子は、業界の発展に間違いなく悪影響を及ぼしてしまうと考える。

自分のこの記事によって、拡散した誤った情報が訂正されること、そして動画配信サービスに対する公平な認識が広がることを願っている。

あと。

自分を宣伝するんだったら、フェアにやろうや。

おまけ

他の動画配信プラットフォームとの比較

Vimeo (Premium)

Pricing plans | Vimeo Pro, Plus, Business, Premium, Enterprise & OTT

• ￥7,500/月 (年払いの場合。月ごと払いの場合￥13,500/月)
• 無制限のライブイベント、ウェビナー。ただしFair use policyのため3TB/月程度で警告が来る
• これ以上使う場合はEnterprise版。価格はお問い合わせ (今回の場合、それが200万という話だった)

IBM Video Streaming (Platinum)

IBM Video Streaming - 料金体系 - 日本 | IBM

• かつてのUSTREAM
• ￥138,500/月
• HD(720p)まで
• 20チャンネルまで
• 総視聴時間合計5,000時間 (同時接続数300, 1回当たり2h, 月8回の配信でこのくらい)
• これ以上はカスタムプラン。価格はお問い合わせ

た、たか・・・

dacast (Scale)

https://www.dacast.com/live-streaming-pricing-plans/

• $188/月(年払いの場合。月ごと払いの場合$250/月)
• 無制限のチャンネル
• 転送量 年間24TBまで（月あたり2TB）
• それ以上はカスタムプラン、価格はお問い合わせ

同種のサービスで比較すると、やっぱりVimeoのお得さが際立つ。でも、VimeoがPremiumプランのことをUnlimited live streamingと書いているのは分かりづらいし、実際のところの制限は存在するわけで、FAQだけでなく価格表にも明記して欲しいな。。

しかしかつてのUSTREAMさん、高いな･･･。これには驚いた。

追記

ツイートによると、50TBで50万円程度のプランが提案されることもある様子。3TBで10万円⇒50TBで50万円 と提案されるのであれば、極めて真っ当なんじゃないかな。それが200万円という提案になったということは、それだけ帯域を使っているということだと思うので、それはちゃんと払おうよ

Vimeo は50,000GBで4,000$/年というプランがあります。 https://t.co/z8R2TMSigY

— 宗方 涼 (@munakata_ryo) December 8, 2021

コレ、自分もおんなじ連絡を受けた（５０万でしたが）のですが、自分の場合「払わないと今後使わせないよ」という話で、これまでの分に請求が来る、というわけではなかった気がします。ので選択肢はあるかなと思うのですがどうでしょうか。

— naoyanickf.sol (@naoyanickf) December 6, 2021

追記の追記

ツイート主から返信があったので一連のやりとりをまとめてみた。結局真相は謎のまま…

togetter.com

追記の追記の追記

Vimeoからの公式回答が得られました。

jaco.udcp.info

2022/3/27 さらに追記

分かりづらかった「上位1％」という基準を「2TB以上消費時」に変更することや、使用帯域についてのアラートが実装されるなどの改善が発表された様子

vimeo.com

gigazine.net

Miroの操作が直感的じゃないと感じた時はNavigation設定を見直そう

Miro Advent Calendar 2021の5日目。このブログだとMiroネタ2回目。

前回: jaco.udcp.info

「Miro、触ってみたけどなんかクセがあるというか、直感的に操作できない」 という意見を聞くことがある。そんなときは、一度設定を見直してみようという話。

Miroは直感的に操作できない？

最初同僚から「Miroの操作が直感的じゃない」と聞いたときは戸惑った。個人的には群を抜いて直感的に操作できる便利なツールだと感じていたので、「え、どこが？」 と。

が、ある時所有している他のPCから使ってみたところ、どうもいつものように操作ができない。マウスホイールを使うと拡大縮小じゃなくて上下に動くし、マウスのドラッグでボードの移動を行うこともできない。なんだなんだ、突然仕様変更されたのか？　と慌てたが、結論としてはNavigation modeに問題があった。

Navigation modeを見直そう

画面左上のタイトル横にある設定マーク(新UIの場合。旧UIだと右側) をクリックし、Preferences -> Navigation modeをクリックする。 あるいは何もないところで右クリックしたときに出てくるメニューにもNavigation mode設定がある。

これを選択すると、このようにNavigation modeをどうするかという設定が出てくる。

もしマウスを使っているのであればMouse、トラックパッドを使っているのであればTrackpadを選択したほうが良い。

前述した操作の違和感は、マウスを使っているのにも関わらずTrackpadにモードが設定されていたのが原因だった。 ここの初期値がどのように決定されるのかはまだよく分からない…。

ちなみにマウス派？トラックパッド派？

ところで他の人はどちらを使っているのだろう。 個人的にはどのWindows機もトラックパッドの出来が悪いので、Windowsであればマウス一択かなと思っている。 Macであればトラックパッドが秀逸のため普段はマウスを使わないことも多いが、Miroを使うときはマウス欲しいなと感じることが多い。 特にオブジェクト間でラインをつなぐなどの細かな操作をやるときはマウスのほうが快適に出来る気がする。

追記

最近このナビゲーション設定が機能変更され、Auto switchというものが導入された。また、マウス操作時のボタンが変更になっている。

以下のエントリーも参考に

jaco.udcp.info

人類はWeb会議に向いていないので、もっとMiroを活用すべき

Miro大好きjacopenです。エンタープライズなIT界隈ではおそらく日本でトップクラスにMiroを愛している自信がある。

さて今日はMiro Advent Calendar 2021の3日目。

今日は、人類がいかにWeb会議に不向きかという話と、そのギャップをMiroで埋めようという話。あとは自分が関わっているカンファレンスでMiroを使いまくっている話をする。

Web会議の8割はXX

コロナ禍でだいぶ定着したWeb会議。でも、個人的には世の中のWeb会議の8割は上手くいっていないと思っている。数字に根拠はないけど。 何を持って上手くいっていないとするかだが、「対面の会議と比較して伝えられる度合いが低下している」とすると、8割くらいはそれに該当すると言っても過言ではないだろう。

何故そうなるかというと、基本的に人は言葉だけで物事を正確に伝えることはできないからだ。

人間の会話において、話し手は頭の中に構造化された情報があり、「今何について話しているか」という位置情報をもった状態で話す。まあ中には位置情報を持たず思い浮かんだことを喋っちゃう人や、脳内の位置情報がどんどんズレていく人もいるがそれはまた別の話。

一方聞き手は必ずしも同じ構造化された情報を持っているとは限らない。そのため、聞き取った内容から情報を組み立てて行く必要がある。また、話し手が持っている位置情報は共有されないため、話の流れから位置情報を推測し、継続的に更新していかなくてはいけない。

しかし、声というのは単位時間当たりに伝えられる情報が少ない手段だ。日本語だと1秒当たり十数文字分しか伝えられない。データ通信に置き換えるとわずか数十byte/sec。声のトーンなど付加情報を加味しても、とてもとても少ないわけだ。必然的に、伝える情報は断片的なものになってしまう。

これらは対面でも同じことが言えるのだが、人間というものは五感を働かせることによってある程度のエラー訂正が可能だ。声による情報の他にボディランゲージや表情によって情報の補完が可能なほか、聞き手の表情などから正しく伝わっていないことを読み取れれば、追加の情報を付加したり、分からないところはどこか聞き出すことも可能だ。対面の会議が好まれる理由はこのあたりにある。

これがWeb会議になってしまうと、声以外の情報がばっさり切り落とされてしまう。人間が備えているエラー訂正機能が働かなくなってしまうのだ。 そのため、聞き手の脳内で情報の構造化ができないまま話が進み、位置情報もズレてしまう。

他にも問題がある。対面のミーティングと違い、Web会議では聞き手の環境をコントロールしづらい。聞いている間に宅急便がくるかもしれないし、猫が来ることもあるし、横で開いているTwitterに面白画像が流れてきて注意が逸れることもある。対面の会議でTwitterを開いている人は比較的少数だろうが、Web会議では相手がどういう状況か知ることは難しいわけだ。たとえその注意が逸れている時間が十数秒であっても、先ほどから書いている会話の位置情報をズラすには十分な時間だ。

この話し手と聞き手の位置情報がある一定以上ズレてしまうと、聞き手はその段階で一切の情報を受け取れなくなってしまう。

例えば、車に乗って見ず知らずの場所に出かけても、移動した経路を覚えていればおおよその位置は分かる。しかし、しばらく目隠しをされていたらどうなるか。どこに居るか全く分からなくなってしまうだろう。この状態でいくらその土地の説明をされたところで、要領の得ないものとなってしまうだろう。

「開催したはいいが効果が得られないWeb会議」はこうやって生まれていく。

コンテキストを揃えるべし

コミュニケーションにおける、この位置情報のことをコンテキストと言う。 正確には、コンテキストの一部と言った方が良いか。元々持ち合わせている知識や文化的な背景、会話の文脈などを総じてコンテキストと表すことが多い。

コミュニケーションで最も大事なことは、このコンテキストを共有し、各人の立ち位置を揃えることにある。

コンテキストの共有には様々な手段があるが、コストが低く効率よく行えるのは 図解をすることだ。

あらかじめ図で構造化した情報をダンプし、共有することで聞き手は声から情報を構造化する手間が省け、より重要なことに脳のリソースを割くことができる。

また、声で説明しながら同時に図に起こしていくのも良い。これにより、話し手と聞き手の位置情報を細かく同期させることが可能となる。

そして、少なくとも自分が知っている限り、最もこの取り組みを効率よく、気持ちよく行えるのがMiroだ。

Miroだとこんなに良い

情報をダンプして共有するだけであれば、別にMiroでなくても可能だ。既に多くの人が、Google Docsで議事録を書いたり、PowerPointやGoogle Slidesでスライドを共有しながらWeb会議をしているだろう。

しかしこれらが最適な手段かというとそうではない。

• WordやGoogle Docsの欠点
  • 文字が主体。文字を読んで理解していくのは脳の負担が大きく、時間がかかる。
  • 構造化した表現が難しい
• PowerPointやGoogle Slidesの欠点
  • スライド1枚あたりの情報量が限られてしまう。
  • 1枚当たりの情報量を増やすと読みづらい。
  • 情報量を減らすと、スライドを見逃してしまったときのリカバリーが難しい。
  • リアルタイムな追加がやりづらい

Miroだとこれらの欠点を良い感じにカバーできる。

まず会議前に、あらかじめ共有しておくべき情報を書き込んでおく。文字で書いてもいいし、図にしてもいい。 情報量も、冗長でない限りは多少多くなっても構わない。見る人が拡大縮小して合わせられるからだ。

会話しながらリアルタイムに図解していくのも可能だ。以下の例は実際に会話しながら起こしたアーキテクチャ図だ。

画像を貼るのも容易だし、アイコンのライブラリが充実しているので検索するとだいたい欲しいアイコンが出てくる。

また、話し手だけでなくて聞き手側にも積極的に書き込んでもらうと良い。付箋紙を初めとした使いやすいツールが充実しているので、ブレインストーミングや振り返りにも最適だ。

聞き手側にも参加して貰うことで、少なくともYouTubeやTwitterを見ていて会議に集中していないという状況を減らしやすい。声ではなかなか質問しづらかった事項も、「気になったことがあれば付箋紙に書き出してください」と言っておけば、聞き手側も心理的な障壁が下がる。心理的障壁を下げることはコンテキストのズレを無くしていくにはとても重要だ。

組織におけるMiroの活用事例

Miroめっちゃ便利という話をしたところで、自分のMiroの活用について紹介。

自分がCo-Chairとして関わっているCloudNative Daysというクラウドネイティブ技術のカンファレンスがある。先日ちょうどCloudNative Days Tokyo 2021(CNDT2021) を開催したところだ。

event.cloudnativedays.jp

このカンファレンスの実行委員会では、昨年からMiroを積極的に活用している。上記Miroの解説にも、実際にCNDTで使ったMiroボードのスクショを使っている。

使い始めたきっかけ

もともとMiroは自分が前職(Pivotal / VMware)の時から仕事で使い倒していた。

VMwareには VMware Tanzu Labsというサービスがあり、Leanプロダクト開発とXPを組み合わせたLean XPという手法でアプリケーション開発やモダナイゼーション、プラットフォームの支援を行っている。前身のPivotal Labsの体験談をみてもらうと分かるが、ホワイトボードや付箋紙をガッツリ活用してコミュニケーションを取るスタイルを取っている。

コロナ禍以降このサービスもオンライン化を余儀なくされたが、ホワイトボードと付箋紙無しにには仕事ができない。そこでMiroを活用することで、従来と同じようなスタイルで継続することができた。

同じくオンライン化を余儀なくされたのが前述したCloudNative Days。イベント自体もそうだし、実行委員会も直接集まるのが難しくなった。Google DocsとZoomを使ってオンラインミーティングに切り替えたものの、直接会うのと比べるとどうしても意思疎通が難しい。些細な認識違いを発端とするすれ違いも多く発生した。

じゃあどうするか。ここは本業で使っているのと同じく、Miroを活用するのが最善策だろうと。そう思って導入を決めた。

CloudNative DaysにおけるMiroの活用

CloudNative Daysの実行委員会では、MiroのTeamプランを利用。

コミュニティ主体のイベントであり予算が潤沢にあるわけではないので、アカウントを所持しているのはアクティブ率の高いメンバーに限っているが、持っていないメンバーに対してもボードのリンク共有を活用して参加してもらっている。

チームに分かれタスクを分担しているが、主に以下のような用途で使われている

イベント企画

どんなテーマにするか、どんなコンテンツをやるかといったイベント企画やアイディア出しに利用するパターン。マインドマップや付箋紙を使ってどんどん書き出していく。

前述したWeb会議を効率化する目的もあるが、もう一つ大きな目的としては非同期のコミュニケーションがある。

実行委員はそれぞれ本業を抱えた上でボランティアで参加しているため、ミーティングの時間を潤沢に取るのは難しい。スケジュールを合わせるのもなかなか困難だ。そこで、MiroとSlackを活用して出来る限り非同期でコミュニケーションを行うことで、負担を軽減するよう努めている。

技術的なディスカッション

CloudNative Daysでは、オンラインイベントのプラットフォームを内製している。 また、配信についても技術を持った実行委員会メンバーが主体となって行っている。

インフラからコンテナを初めとしたミドルウェア、そしてアプリや配信技術まで、上から下まで幅広いレイヤーのディスカッションを行う必要があり、図を使ったディスカッションは必要不可欠だ。

振り返り

より良いカンファレンスにしていくためには、カンファレンス開催後の振り返りは絶対に必要な取り組みだ。実行委員会全体、そして各チームごとに振り返り(KPTを利用) を行い、次への改善へとつなげている。

振り返りでは付箋とタイマー機能を利用している。

コンテンツとしてのMiro

CloudNative Daysでは、実行委員だけでなく一般参加者も参加できるコンテンツとして、Discussion BoardやJob BoardをMiroの埋め込みをを活用して行っている。

テーマごとに参加者が質問を付箋で書き込み、それに対して知見を持っている人が付箋で返信していく。同期ないしは非同期のオンラインコミュニケーションを参加者も一体となって行うための取り組みだ。

オフライン開催していたCloudNative Days Tokyo 2019で開催し盛り上がった、ホワイトボードを使って自由にディスカッションをするCloud Native Deep Diveという取り組みが元となっている。

デブサミでの活用例

別イベントだが、Developers Summit 2021でやったパネルディスカッションでもMiroを活用して大変盛り上がった。

アーカイブは見られないようだが、Togetterのまとめを見ると盛り上がりの様子が分かる。

togetter.com

#devsumiA のセッション、リアルタイムで付箋を貼れるMiroっていうツールを使ってプレゼンしている。

参加者も自由にコメントを書き込める。
わちゃわちゃ感が面白い😄https://t.co/fxJQwZ9MLa#devsumi pic.twitter.com/M1PwJUW4tR

— 湊川あい📚IT漫画家 わかばちゃんと学ぶ シリーズ発売中 (@llminatoll) February 19, 2021

まとめ

Miroほんと最高なので是非活用して欲しい

HashiCorpに入社しました

本日Senior Solutions Engineerとして、HashiCorpに入社しました。

元々前職、前々職からHashiCorpのOSSプロダクトを利用していたことや、The Tao of HashiCorpという明確なプロダクトのビジョンを持っている点に魅力を感じて決めました。

HashiCorpもソフトウェアベンダーではあるのですが、競合するというよりは、どのベンダーのプロダクトとも上手く組み合わせてワークフローを作っていけるというプロダクト作りをしている点(Simple, Modular, Composable) も、CloudNative Daysをはじめとしたコミュニティ活動を行っている身としてはとても合っているなと感じています。

手始めに自宅のvSphere環境をTerraform管理に移行していくところから始めています。VaultもConsul使う形に作り替えていこうかな。

まずはHashiCorpプロダクトについて深く学んでいくオンボーディングの期間に入りますが、これまで以上に発信していければなと思っていますので、今後ともみなさまよろしくお願いします！

Tanzu Kubernetes Grid 1.4を新規構築した

先日Tanzu Kubernetes Grid 1.4が登場

tanzu.vmware.com

TKG1.3.1からのアップグレード方法はmaking先生が書いているのでそちらを見てもらうとして、自分は環境作り直しをしたかったので新規構築してみた。

CLIのセットアップ

まずは tanzu CLI等必要なものをセットアップ。基本的には以下のドキュメントを参照。

Install the Tanzu CLI and Other Tools

Customer connectからVMware Tanzu CLI 1.4.0 CLIをダウンロード(環境に応じてダウンロードするものは変わる)

https://customerconnect.vmware.com/en/downloads/info/slug/infrastructure_operations_management/vmware_tanzu_kubernetes_grid/1_x

そして tanzu のインストールとtanzu pluginのセットアップ、ytt などのCarvel toolを入れる流れ。

OVAテンプレートのダウンロードとアップロード

次にCustomer connectからOVAテンプレートを持ってくる。UbuntuもしくはPhoton、あるいはその両方をダウンロードしておく。

ダウンロードし終わったら、 vCenterからOVFテンプレートのデプロイ でデプロイ。その後テンプレートに変換 を行う。

このダウンロード＆アップロード＆変換は govc コマンドを使ってCLIで行うことも可能。そのあたりはmaking先生の記事を参照

Management Clusterのデプロイ

まずはManagement Clusterをデプロイする。CLIを使う方法とUIを使う方法の2つあるが、今回は初回インストールということもありUIを利用する。以下のコマンドを実行すると、 localhost:8080でUIが立ち上がるのでブラウザでアクセスする。もしも踏み台サーバ等で実行している場合は、sshのポートフォワード 例: ssh <踏み台サーバーIP> -L 8008:localhost:8080 を活用するなどしてブラウザから繋ぐと良い。

tanzu management-cluster create --ui -v 9

このような画面になるので、今回はvSphereを選択。ちなみにAWSとAzureを選ぶこともできる。

設定画面に入るので、必要項目を入れていく。まずはvCenterの設定。SSH PUBLIC KEYには、今後メンテナンス等でVMに繋ぐためのSSH公開鍵を入れる。

次にManagement Clusterの設定。インスタンスタイプはmedium以上が推奨。

どうやらTKG1.4から、Control planeのLBにNSX ALBが利用可能になった様子？ (これまではkube-vipのみだった)

1. VMware NSX Advanced Load Balancer のところは、NSX ALB利用者向けの設定なので今回は空欄

2. MetadataもOptionalなので空欄で行ける。

RsourcesのところではvCenter上のリソースを指定。VMフォルダ、リソースプールは予めTKG向けに作っておくのがおすすめ。

次にネットワークの設定。作られたManagement ClusterのVMがぶら下がるvCenter上のネットワークを指定する。Cluster service CIDRやCluster pod CIDRは特に理由がなければそのままで良い

7 Identity Managementは、認証を外部のプロバイダーにしたい場合に設定する。この過去記事等を参照。

Auth0でTKGのクラスタを認証できるようにする - Cloud Penguins

OS Imageは先ほどアップロードしたOVAを指定。ubuntuもしくはphotonが選択出来る。

Register TMCはTanzu Mission Controlが利用可能な方は設定。

一通り設定が終わったら次に進める。すると設定の確認画面が出るので、下の方にある CLI Command Equivalent の内容をメモっておく。これは後々、CLIでのインストールを行う際に有用になる。

DEPLOY MANAGEMENT CLUSTERをクリックしてセットアップを開始。デプロイが終わったら以下のようにVMが作られていることが分かる。

Tanzu Kubernetes Cluster(Workload cluster)のセットアップ

次に、実際のワークロードを載せていくKubernetesクラスタを作る。参考にするドキュメントは以下。

docs.vmware.com

クラスタを作成するには、コンフィグファイルを作成してtanzuコマンドでデプロイする形になる。コンフィグテンプレートはドキュメントに記載されているのでコピーし、ファイルとして作成しておく。 今回自分は以下のような設定にした。環境に応じて適宜変更すること。

# CLUSTER_NAME:
CLUSTER_PLAN: dev
NAMESPACE: default
CNI: antrea
IDENTITY_MANAGEMENT_TYPE: none

#! Node configuration
#! ---------------------------------------------------------------------

VSPHERE_NUM_CPUS: 2
VSPHERE_DISK_GIB: 40
VSPHERE_MEM_MIB: 8000
CONTROL_PLANE_MACHINE_COUNT: 1
WORKER_MACHINE_COUNT: 2

#! ---------------------------------------------------------------------
#! vSphere configuration
#! ---------------------------------------------------------------------

VSPHERE_NETWORK: TKG
VSPHERE_SSH_AUTHORIZED_KEY: ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQClNV5DBMYmOo5pYMpYE0PzXAFlLbYT46s6a7sGZdr9FIecJakrTtPVm6Po3uFL6qURi6uRQ8VsgeZGzZWWft8yJs1JdTcem8+KIiCenisTT7m9dRaX3EMdvhHyDtFGPSdGSq+blvgKo+HaHUem+Sx8R1lZAESzlZHjCwDxpZc5F/BkB4Jn+WiRgTeMwavOp0FJedNraLwZIHJ9h4kKV5uxIt3VgD5pHMotzjGJXDd2+jrcX6I/gQ/Cq1mXtvIMRoy72vpwF0r2knt1DrOOGi/Z029ZiPbQJl8HjbQSx/7kYPlw+ZI5W5afMSlwcs8qb3SR5ofF06gUftb3Uq/ziD2j                                                               VSPHERE_USERNAME: administrator@vsphere.local
VSPHERE_PASSWORD: <PASSWORD>
VSPHERE_SERVER: vcenter.udcp.run
VSPHERE_DATACENTER: Datacenter
VSPHERE_RESOURCE_POOL: tkg
VSPHERE_DATASTORE: vsanDatastore
VSPHERE_FOLDER: tkg
VSPHERE_INSECURE: true
VSPHERE_CONTROL_PLANE_ENDPOINT: 10.9.11.101

#! ---------------------------------------------------------------------
#! Machine Health Check configuration
#! ---------------------------------------------------------------------

ENABLE_MHC: true
MHC_UNKNOWN_STATUS_TIMEOUT: 5m
MHC_FALSE_STATUS_TIMEOUT: 12m

#! ---------------------------------------------------------------------
#! Common configuration
#! ---------------------------------------------------------------------

ENABLE_AUDIT_LOGGING: false
ENABLE_DEFAULT_STORAGE_CLASS: true
CLUSTER_CIDR: 100.96.0.0/11
SERVICE_CIDR: 100.64.0.0/13

# OS_NAME: ""
# OS_VERSION: ""
# OS_ARCH: ""

#! ---------------------------------------------------------------------
#! Autoscaler configuration
#! ---------------------------------------------------------------------

ENABLE_AUTOSCALER: false

コンフィグファイルの編集が終わったら以下のコマンドでデプロイを開始

tanzu cluster create workload -f workload.yaml

Management clusterに加え、workload clusterも構築されたことが分かる。

動作確認

終わったら以下のコマンドでkubeconfigを取得し、k8sに接続を確認。

tanzu cluster kubeconfig get workload --admin
kubectl config use-context workload-admin@workload

 kubectl get pods -A
NAMESPACE                           NAME                                                             READY   STATUS      RESTARTS   AGE
avi-system                          ako-0                                                            1/1     Running     0          67m
capi-kubeadm-bootstrap-system       capi-kubeadm-bootstrap-controller-manager-6494884869-8r5v7       2/2     Running     0          72m
capi-kubeadm-control-plane-system   capi-kubeadm-control-plane-controller-manager-857d687b9d-fxx75   2/2     Running     0          72m
capi-system                         capi-controller-manager-778bd4dfb9-tskmh                         2/2     Running     0          72m
capi-webhook-system                 capi-controller-manager-9995bdc94-7sj5n                          2/2     Running     0          72m
capi-webhook-system                 capi-kubeadm-bootstrap-controller-manager-68845b65f8-d7zs5       2/2     Running     0          72m
capi-webhook-system                 capi-kubeadm-control-plane-controller-manager-9847c6747-8fzkp    2/2     Running     0          72m
capi-webhook-system                 capv-controller-manager-55bf67fbd5-5shl8                         2/2     Running     0          72m
以下略

無事にKubernetesとして機能していることが確認できた。

その他1.4に関すること

基本的にデプロイの流れはTKG 1.3と変わるところはない。

TKG1.3にはadd-onという概念があったが、1.4からはpackageという仕組みに変更が行われた。そのため1.3からのアップデートの場合はadd-onをpackageに更新する作業が必要となる。extensionsを利用している場合も同様。

アップデート方法は例によってこちらの記事と、あとは公式ドキュメントを参考にするとよい。

VMUG Advantageに登録した

退職にともない、これまで自宅で検証用に使っていたライセンスたちが使えなくなってしまう。

jaco.udcp.info

しかし次の仕事もVMware製品と完全に無縁というわけではなく、やっぱり検証用途に環境は残しておきたい。

ということで、VMUG (VMware Users Group) に参加して、有料のAdvantageに登録することにした。

www.vmug.com

Advantageに登録すると、トレーニングのディスカウントやVMworld参加へのディスカウントがついてくるほか、365日の検証用ライセンスが利用可能になる。

検証可能なライセンスはこんな感じ。

Advantageへの登録方法はこのあたりの記事を参考にした

zokibayashi.hatenablog.com

1年、2年、3年と選べるのだけど、思い切って3年のプランにしてみた。

(ﾉ´∀｀)ﾉ

EKS AnywhereをProductionでデプロイした話

先に謝っておくと、タイトルは半分釣り。嘘はついていないのだけど。

ということでEKSをオンプレ環境で動かせるEKS Anywhere (以下EKS-A)がGAに。 aws.amazon.com

現時点で対応している構築環境は、ローカルのDocker上で動かすか、あるいはvSphere環境の2択。"ちゃんとした"環境で動かすとなると、vSphereが第一の選択肢と言うことになりそう。

EKS-Aのドキュメントを見ると、Create production clusterの項目でvSphereに構築する方法が解説されている。今回のタイトルはつまりそういうことで、EKS-AをvSphereにデプロイしてみましたよ、というお話。

EKS-Aの準備をする

EKS-Aでは、環境の構築にCluster APIが使われている。VMwareのTanzu Kubernetes GridもCluster APIなので、vSphere環境でk8sを構築するのであればCluster API、というのが一般的になりそう。

Cluster APIはこのマスコットキャラクターがめちゃくちゃ上手く仕組みを表現していて、Kubernetes Clusterの中にインストールされたCluster APIが、さらにクラウドプロバイダーにアクセスして別のKubernetesを立ち上げるという、親亀子亀のような仕組みになっている。

なので、まずは作業環境にDockerを立ち上げ、その中に eksctl anywhere コマンドでbootstrapのクラスタを立ち上げられるようにする。

EKS-Aのドキュメントでは、この作業環境のことを Administrative machine と呼んでおり、現時点ではMac OSか、Ubuntuを公式ではサポートしている。他のディストリビューションでもいけるのではと思うが、試していないので分からないし、無駄なトラブルを避けるためにもまずは推奨環境で行うのが良いだろう。今回はWindowsのWSL2でセットアップしてあるUbuntu 20.04 + Docker Desktopという構成でやってみた。WSL2+Docker Desktopの時点で公式サポートの環境じゃなくなっている気もするが、少なくとも自分の環境では動いた。

Dockerのインストール方法は割愛。

以下のコマンドで最新の eksctl をインストール。バージョン0.66.0が入るはずだ。

curl "https://github.com/weaveworks/eksctl/releases/latest/download/eksctl_$(uname -s)_amd64.tar.gz" \
    --silent --location \
    | tar xz -C /tmp
sudo mv /tmp/eksctl /usr/local/bin/

次に eksctl-anywhere pluginをセットアップ。

export EKSA_RELEASE="0.5.0" OS="$(uname -s | tr A-Z a-z)"
curl "https://anywhere-assets.eks.amazonaws.com/releases/eks-a/1/artifacts/eks-a/v${EKSA_RELEASE}/${OS}/eksctl-anywhere-v${EKSA_RELEASE}-${OS}-amd64.tar.gz" \
    --silent --location \
    | tar xz ./eksctl-anywhere
sudo mv ./eksctl-anywhere /usr/local/bin/

AWSのトリさんが教えてくれたところによると、このプラグイン機構はeksctl 0.66.0から導入されたということなので、もし上手く動かない場合はeksctlのバージョンを確認してみると良い。

vSphere側の準備をする

次にvSphere側の準備をする。 Productionというだけあって、リソースはガッツリ必要になる。 デフォルトだと7VM立ち上がるのだが、それぞれに2 vCPU, 8GB RAM, 20GB Diskが必要だ。つまり14 vCPU, 56GB RAM。 オーバーコミットをしたとしても、まぁそれなりに覚悟は必要なリソース量にはなるだろう。 自分はたまたまガッツリ試せる環境を自宅に組んでいたので問題なかったのだが。

また、vSphereのバージョンはvSphere7.0以上が必須。自分は最新の7.0U1cを利用した。

利用するネットワークにはDHCPが必須。この制約はTKGと一緒なのだが、割と引っかかりやすいポイントなので要注意。

まず、vCenterからResource poolを作成。今回はEKSAという名前にしてみた。

次にフォルダを作成。新規仮想マシンおよびテンプレートフォルダを選択し、 EKSAという名前で作成。

また、これはドキュメントに無くてハマりポイントだが、Templates という名前のフォルダも併せて作っておく。これを作らないとエラーでコケてしまった。

Cluster configを作る

以下のコマンドでコンフィグファイルを生成

CLUSTER_NAME=prod
eksctl anywhere generate clusterconfig $CLUSTER_NAME \
   --provider vsphere > eksa-cluster.yaml

生成したコンフィグファイルを開いてみると、KubernetesのYAMLになっており、Cluster APIによるリソースが定義されていることが分かる。

次にこのファイルの必要事項を修正する。

まずClusterリソースのendpointを修正。これが作成されるKubrenetesのAPIエンドポイントになる。

  controlPlaneConfiguration:
    count: 2
    endpoint:
      host: "10.9.8.190" #これ
    machineGroupRef:

同じリソースで externalEtcdConfiguration workerNodeGroupConfigurations controlPlaneConfiguration が設定可能になっていて、count の値を変更することでVMの台数を変えることが出来る。必要に応じて変更しよう。

次に、VSphereDatacenterConfigを修正。

apiVersion: anywhere.eks.amazonaws.com/v1alpha1
kind: VSphereDatacenterConfig
metadata:
  name: prod
spec:
  datacenter: "Datacenter" #必須
  insecure: true #任意
  network: "VM Network" #必須
  server: "vcenter.udcp.run" #必須
  thumbprint: "" #任意

datacenter にはvSphere上のDatacenter、 networkにはVMをぶら下げたいネットワーク、 serverにはvCenterのアドレスを入れておく。vCenterが自己署名証明書の場合は insecureを true にするか、 thumbprintを設定する。

次に、 3つあるVSphereMachineConfigを修正。 prod-cpがk8sのcontrol plane、prod-etcdがetcd、prodがworker nodeのリソースになっている。それぞれ別の値を設定可能だが、今回は全て同じ設定を施すことにする。

以下のコメントが付いている部分を、環境に合わせて変更する

spec:
  datastore: "vsanDatastore" # 利用したいデータストア
  diskGiB: 25
  folder: "EKSA" # さっき作成した仮想マシンのフォルダ
  memoryMiB: 8192
  numCPUs: 2
  osFamily: bottlerocket # 利用したいOSを指定。今回はbottlerocket 
  resourcePool: "EKSA" #さっき作成したリソースプール
  users:
  - name: ec2-user #bottlerocket の場合はec2-userを指定
    sshAuthorizedKeys:
    - "ssh-rsa AAAAB3NzaC1yc...j" #作成されたVMにログインできるようにするための公開鍵を入れておく

デプロイする！

vCenterにアクセスするための認証情報を環境変数に入れておく。

export EKSA_VSPHERE_USERNAME='administrator@vsphere.local'
export EKSA_VSPHERE_PASSWORD='t0p$ecret'

そして以下のコマンドで構築開始。

eksctl anywhere create cluster -f eksa-cluster.yaml -v 9

ドキュメントには無かったが、 -v オプションでログレベルを変更できるとトリさんが教えてくれた。ありがたや。初期構築の場合何かとコンフィグの設定ミスを起こしやすいのだが、デフォルトのログレベルだと進捗がほとんど表示されないのでエラーが起きていても気づきにくい。 -vで高めの数字をしておくことで、トラブル時にも状況を把握しやすくなる。

最終的に以下のような表示がされれば構築完了。

作られたものを見ていく。

リソースグループを見てみると、7台のVMが構築されていることが分かる。ちなみに画像の下のリソースグループはVMware Tanzu Kubernetes Gridで構築した環境だ。同じCluster APIを利用しているため、VMの命名ルールが似ていることが分かるだろう。

コンテンツライブラリを見てみると、eks-a-templates という名前のライブラリが作成されており、その中にOVAテンプレートが追加されている。現バージョンではbottlerocketとubuntuが選択可能なのだが、ubuntuイメージは8.64GBと巨大のため、VMの起動が非常に遅かった･･･。Tanzu Kubernetes Gridの場合はubuntuでも1.5GB程度なので、何故こんなにサイズが大きいのかは謎。

作成されたk8sにアクセスするには、kubeconfigファイルが生成されているのでそれを指定

export KUBECONFIG=${PWD}/${CLUSTER_NAME}/${CLUSTER_NAME}-eks-a-cluster.kubeconfig

叩いてみると色々動いていることがわかる。

kubeconfigを毎回指定するのが面倒なので、必要であれば ~/.kube/config に内容をマージしたほうがいいかもしれない。

CNIにはCiliumが利用されている。CSIは標準でvSphere CSIが設定されているため、そのままPVが作成可能だ。

kubectl get sc
NAME                 PROVISIONER              RECLAIMPOLICY   VOLUMEBINDINGMODE   ALLOWVOLUMEEXPANSION   AGE
standard (default)   csi.vsphere.vmware.com   Delete          Immediate           false                  76m

LoadBalancerは、ドキュメントだとKube-vipの利用がRecommendedになっている。(個人的にあまりいい印象がないのだけど･･･)

ちなみに既にControl planeにはkube-vipがデプロイされており、Kubernetes APIの公開に利用されている。

その他FluxによるGitOpsがサポートされているなどいくつか特徴があるので、皆さんお試しあれ(これはDockerで構築しても使えるはず)

ハマったこと

オンプレならではというか、環境の差異によるハマりポイントがあったので以下メモ

public.ecr.awsからaccess denied食らって死んだ

パブリックの方のECRを以前使っていたんだけど、そのログイン情報が切れていたのかいきなりこれを食らった。get-login-passwordをやり直して解消。

eksctl anywhere create cluster -f eksa-cluster.yaml
Error: failed to create cluster: unable to initialize executables: failed to setup eks-a dependencies: Error response from daemon: pull access denied for public.ecr.aws/eks-anywhere/cli-tools, repository does not exist or may require 'docker login': denied: Your authorization token has expired. Reauthenticate and try again.

コンテンツライブラリで死んだ

若干分かりづらいエラーだったが、コンテンツライブラリへの転送でエラーと出た。原因としては、vCenterのDNS設定が間違っており名前が引けない状態だったため、OVAファイルをインターネットから持ってこれずこのエラーになった様子。この状態になってしまうと、DNS設定を直してもコンテンツライブラリにゴミが残っており、そのゴミを手動で消してあげる必要があった。

Creating template. This might take a while.
❌ Validation failed    {"validation": "vsphere Provider setup is valid", "error": "failed importing template into library: error importing template: govc: The import of library item d7869312-b889-4400-b489-af20cf1e177f has failed. Reason: Error transferring file bottlerocket-v1.21.2-eks-d-1-21-4-eks-a-1-amd64.ova to ds:///vmfs/volumes/vsan:5208a8224f1b7452-258c9915a44aa6a5//contentlib-b06b09de-5b24-4be6-86a9-b344590a9681/d7869312-b889-4400-b489-af20cf1e177f/bottlerocket-v1.21.2-eks-d-1-21-4-eks-a-1-amd64_c4187670-2a9b-4a5b-86dd-a1e8a0bd0d18.ova?serverId=86f3a054-9ba4-4b8f-81b6-b7070451c5cc. Reason: Error during transfer of ds:///vmfs/volumes/vsan:5208a8224f1b7452-258c9915a44aa6a5//contentlib-b06b09de-5b24-4be6-86a9-b344590a9681/d7869312-b889-4400-b489-af20cf1e177f/bottlerocket-v1.21.2-eks-d-1-21-4-eks-a-1-amd64_c4187670-2a9b-4a5b-86dd-a1e8a0bd0d18.ova?serverId=86f3a054-9ba4-4b8f-81b6-b7070451c5cc: IO error during transfer of ds:/vmfs/volumes/vsan:5208a8224f1b7452-258c9915a44aa6a5/contentlib-b06b09de-5b24-4be6-86a9-b344590a9681/d7869312-b889-4400-b489-af20cf1e177f/bottlerocket-vmware-k8s-1.21-x86_64-1.2.0-ccf1b754_c4187670-2a9b-4a5b-86dd-a1e8a0bd0d18.vmdk: Pipe closed.\n", "remediation": ""}
Error: failed to create cluster: validations failed

Templateの作成で死んだ

これは本文中にも書いた通り。ドキュメントの記載漏れなんじゃないかなー？ Template用のフォルダを作っておく必要がある。

❌ Validation failed    {"validation": "vsphere Provider setup is valid", "error": "failed deploying template: error deploying template: govc: folder '/Datacenter/vm/Templates' not found\n", "remediation": ""}
Error: failed to create cluster: validations failed

タグが適切に設定されなくて死んだ

これ、諸々試行錯誤してたら突然出なくなって解消して、結局原因は謎。 テンプレートに必要なタグが設定されておらず死ぬパターン。 この問題を引いてしまった場合は、手動でTemplateファイルのタグにosFamilyの設定を入れてあげる必要があった。

❌ Validation failed    {"validation": "vsphere Provider setup is valid", "error": "failed tagging template: govc returned error when attaching tag to /Datacenter/vm/Templates/bottlerocket-v1.21.2-kubernetes-1-21-eks-4-amd64-a440064: govc: 400 Bad Request: {\"type\":\"com.vmware.vapi.std.errors.invalid_argument\",\"value\":{\"error_type\":\"INVALID_ARGUMENT\",\"messages\":[{\"args\":[\"urn:vmomi:InventoryServiceTag:28bd7acf-262b-4c48-a53a-775ed91b34e1:GLOBAL\",\"DynamicID (com.vmware.vapi.std.dynamic_ID) => {\\n    type = VirtualMachine,\\n    id = vm-1554590:86f3a054-9ba4-4b8f-81b6-b7070451c5cc\\n}\"],\"default_message\":\"Tagging associable types violation\",\"id\":\"\"}]}}\n", "remediation": ""}
Error: failed to create cluster: validations failed

etcd以外のノードが上がらずに死んだ

これ、結局原因が分からず、何もしてないのに直った･･･(マジ)

bottlerocketでこの問題を引き、その後ubuntuにしたら普通に立ち上がった。 で、その後bottlerocketに戻したら何故かちゃんと立ち上がった･･･。

etcd VMは上がってきたけどその次がこないなぁ pic.twitter.com/HD25dFe8Fy

— Kazuto Kusama(jacopen)🐧☄🐏 (@jacopen) September 9, 2021