[過去ログ] Docker Part3 (1002レス)
上下前次1-新
このスレッドは過去ログ倉庫に格納されています。
次スレ検索 歴削→次スレ 栞削→次スレ 過去ログメニュー
534: 2020/01/29(水)23:50 ID:OCMkZsaj(3/3) AAS
>>533
k8sはECSより高機能で汎用的だが学習コスト高めという印象。ECSはベンダー製なので、クラスタに関してはその通りだろうが、ベンダーロックインの問題がある。
ベンダーロックインの問題を気にせず、ECSで案件が済むならECSだろう。
535(1): 2020/01/30(木)00:20 ID:KTDe4H4D(1) AAS
たかがコンテナ立ち上げるだけのことにベンダーロックインねえ
事業視点で言えば、k8sに習熟した少数のエンジニアにインフラをロックインされることの方がよほどリスクが大きいと思うけどね
536: 2020/01/30(木)00:26 ID:OBlH/P8v(1) AAS
>>528
単に使い所を間違ってるだけとしか思えんが
そもそも別にk8s使わなくてもdockerはある程度規模に応じたオーケストレーションを標準に
近い形で用意しているはずで、それでは管理できないほど巨大な規模のサービスを運用するから
k8sですよ、って事で、当然メモリが食いすぎとか文句言う人が使う物じゃない気はする。
そういう人にはもっと小規模な物あるでしょ?
昔Googleの論文元にHadoop作って訳も分からずに食いついて先進的だカッコいいぜ俺スゲーとか
いって後からやっぱ遅ーえわこれwとかいってた連中思い出すね。
自分たちが間違った場所に適用してるとは最後まで考えないw
537(1): 2020/01/30(木)01:26 ID:pAQXSf/G(1/2) AAS
>>535
Amazonがk8sのサービス始めたのはこの理由らしいから、そういう意見も多いということなのだろう。
個人的にはk8sよりマルチビルドのdocker file の方が難解だな
538(1): 2020/01/30(木)02:46 ID:N78kTYg5(1/6) AAS
>>533
> k8sは決まったサイズのクラスタを効率的に使うにはいいけど、クラスタそのもののスケーリングにはあまり適してないよ
そうだよね?
広大なCPU空間を確保しておいて、自由に使いましょうというのならいいけど
コストの観点から空間自体を減らしたり増やしたりってのは適してないと思う
スケーリングならすでにGCEとかのクラウドの仕組みで実現できたじゃんって思う
そこにGKEを持ってきて使いづらくしたと思ったら、
どうせコンテナベースで課金とかするでしょ?
なんでクラウドの中にさらにクラウド作ってるんだろうって思う
539(1): 2020/01/30(木)02:49 ID:N78kTYg5(2/6) AAS
>>537
> 個人的にはk8sよりマルチビルドのdocker file の方が難解だな
マルチステージビルドの事? どんだけ複雑なんだよw
あんなの、中間ファイルは不要だから
前のイメージでビルドしてできた生成物のみ
コピーして使いましょうってだけじゃんか
540: 2020/01/30(木)03:04 ID:N78kTYg5(3/6) AAS
k8sの嫌なところは短いタイミングで強制アップデートな所だな
これがあるからストレージとしては使えない
データベースは別のサービスを使えってことなんだろうけど、
これがあるからHAの代わりにはならないんだよね
541: 2020/01/30(木)08:22 ID:x2o8za8v(1/2) AAS
自前k8sなら誰も面倒見てくれないので
アップデートもされない
証明書の期限短くすると
期限切れした時にAPIサーバーと通信できなくなるけど
542: 2020/01/30(木)08:57 ID:JRKnodoF(1/3) AAS
APIサーバーの証明書は自動更新機能があった気がする
>>538
ワーカーノードは今まで通り課金される
k8sでのサーバーレス関数の実行は
EKSやGKEで最近できるようになったが
一部機能制限がある上に
確保するリソースが多いと通常通り
ワーカーノードを用意した方が安くなる事がある
サーバーレスはコールドスタートによる遅延の問題なども多分まだある
543(1): 2020/01/30(木)09:18 ID:JRKnodoF(2/3) AAS
サーバーレスが利用出来ない場合の次善の策は
Cluster Autoscaler
ポッドの数に応じてノード数を増減出来る
負荷ベースでポッド数を増減する
水平ポッドオートスケーラーと組み合わせる事で、ノード数を負荷に応じて自動で増減出来る
とは言ってもノードの起動は時間がかかるので
すぐには無理だが
544: 2020/01/30(木)09:18 ID:JRKnodoF(3/3) AAS
サーバーレスが利用出来ない場合の次善の策は
Cluster Autoscaler
ポッドの数に応じてノード数を増減出来る
負荷ベースでポッド数を増減する
水平ポッドオートスケーラーと組み合わせる事で、ノード数を負荷に応じて自動で増減出来る
とは言ってもノードの起動は時間がかかるので
すぐには無理だが
545: 2020/01/30(木)11:27 ID:pAQXSf/G(2/2) AAS
>>539
他人が書いたのを検証するのが難しいってことね。他人に依存するかどうかという視点の話。
546(1): 2020/01/30(木)11:44 ID:N78kTYg5(4/6) AAS
>>543
ノードの増減はk8sなくてもできたじゃん?
・負荷の応じてノードが増減できる
だったのが
・負荷に応じてでポットが増減できて、ポットの増減に応じてノードが増減できる
に変わってるじゃん?
二段階になってややこしくなってるし
ノード(課金対象)が増減しない範囲でのポットの増減が存在するわけで、
こんなんで正確な見積もりなんかできるの?
k8sはプロジェクト単位で使うものじゃななくて、
省3
547: 2020/01/30(木)11:52 ID:N78kTYg5(5/6) AAS
k8sはノード=1つないし少数のそれぞれ違うポットを配置するという使い方じゃないんだよね
1つのノードが複数のポットを動かすスペックを持っていて、
多数の小さなポッドをその中で動かすという使い方をする。
1つのノードで同じ種類のポットがたくさん生まれて
消えるような場合じゃないとうまく使えない
自動管理されたHA環境ではないんだよね
548(1): 2020/01/30(木)17:42 ID:IVBe8aPz(1) AAS
ECSは当初タスク数がEC2インスタンス数と連動しない残念仕様だった
こちらもタスク数に応じてインスタンスが生成される
外部リンク:dev.classmethod.jp
5タスクを同時に動かそうとすると、
5台のEC2インスタンスが生成される
超シンプル
549: 2020/01/30(木)17:44 ID:krDeGaUI(1) AAS
ECSサービス開始当初はEC2の数とタスクの数を連動させる機能が
無かったが、去年追加された
550(2): 2020/01/30(木)18:28 ID:N78kTYg5(6/6) AAS
>>548
それは一般的な使い方としてはわかりやすいし、できるべきだよね。
ただk8sのそもそもの使い方としては、ずれてるんだと思う
その使い方であれば、インスタンスのオートスケールと変わらないわけだし
コンテナが動かせるというメリットはあるけどね
まあ各クラウドの間で共通のインターフェースができて
どこでも動かせるようになるのはいいと思うけど
そのためにもっと大掛かりなシステムのためのk8sを流用してる感が大きい
もっと間を減らしてシンプルに出来なかったのかねぇ
やっぱりクラウドを使ってクラウドを作ってるように見えてしまう
省4
551(2): 2020/01/30(木)19:32 ID:RH+cWAif(1/2) AAS
ECSも、タスク数をCPU使用率などのメトリクスと連動させれば、
CPU数に応じて「タスク数とインスタンス数」を同時に増やすことが可能
何が違うと言うのか
ECSも以前から「それぞれ別々に」インスタンス数とタスク数を増減する事は出来たが、
協調せずバラバラに動くので、
負荷の増加に反応してサービスのタスク数は増えたのに、
インスタンス数がちゃんと増えなかった、
あるいはインスタンス数は増えたのにサービス数が増えないとか
そんな動きになる可能性があった
1つのノードに複数のコンテナがあるような状況では
省3
552(1): 2020/01/30(木)19:38 ID:RH+cWAif(2/2) AAS
Kubernetesはずっと前から
ポッド数によるノード増減ができた
パクったのはECS
自動でノード数の増減が要らない、
常に2台で良いって言うなら
Cluster AutoScalerを使わなくても良い
553(1): 2020/01/30(木)20:00 ID:VJ/WHmRQ(1) AAS
そもそもECSって目的毎にクラスタ立てるもんだろ?
何でもかんでも一つのクラスタで済ませようなどと考えなければ従来のインスタンスベースのスケーリングで問題ない
それこそ「クラウドなんだから」だ
ID:RH+cWAifの主張は、クラウドの中にクラウドを作っているという批判に対する反論としては的外れに感じる
上下前次1-新書関写板覧索設栞歴
あと 449 レスあります
スレ情報 赤レス抽出 画像レス抽出 歴の未読スレ AAサムネイル
ぬこの手 ぬこTOP 0.025s