JAEN
覚書

CloudNativeサーベイ

https://twitter.com/jyoshise/status/1206175831497687041

結局クラウドネイティブの本質とは雇用形態なのではとも思う

https://twitter.com/nekop/status/1207914381176012800

OpenShift 4のインストール、bootstrapという一時的なk8s masterを立ち上げて、Operator置いて、あとは全てのOperatorが「あるべき状態へ修復する」という動作をすることでクラスタセットアップが完了するんですよ。一般的な「インストール」とはちょっと違うよね。

https://twitter.com/jyoshise/status/1208990757995999232

一方Kubernetesのすごさは、全てがAPIオブジェクトとして扱えることであって、コンテナ技術はそれを実現するための便利なパーツにすぎないと私は思っているのだけど、その辺が伝わってるのか伝わってないのかいまいちわからない。Autonomyの話をしてるのにAutomationの話にすり替わっていたりとか。 自分が考えていたのはこれだなーって思う。コンテナも非常に重要なのだけど、Kubernetesという文脈においては「全てがAPIである」「自律しており、あるべき姿へ向かって調整し続ける」という機能がパラダイムシフト。

https://twitter.com/keisuke69/status/1205698166802149378

k8sでサーバーレスってモヤる。自社内でコストの付け替えしてるだけなんじゃないかと思ってしまうんだが…。確かに開発側からはサーバ管理とかしなくてよくなるけど、自社内の別のチームがサーバ管理してるだけで、会社全体コストで見るとどうなんだろう？集約することで効率化はされるからいいのかな

https://toris.io/2019/12/what-i-think-about-when-i-think-about-kubernetes-and-ecs/

1つ1つのサービスにはそれぞれの責務の範囲が明確にあり、ユーザーはそれらをビルディング・ブロックとして組み合わせることでシステムを作っていく。各 AWS サービスはそれぞれの API を呼ぶ形で疎結合に組み合わせることができ、一部のブロックを他のブロックに、例えば ECS から Lambda に置き換えられる. この思想と哲学が、AWS 上で持続可能なシステム構築と運用を可能にしていると言えます

Kubernetes というソフトウェアは、ユーザー自身が独自の哲学に基づいてそんなプラットフォームを作り上げることを可能にするものです

素の Kubernetes はこの一貫性あるデプロイメントモデルを実現する機能に加え、少しの便利機能をもった非常にシンプルで簡単なソフトウェア

ALB や RDS は AWS の API で、コンテナで動かすものは Kubernetes の API で、というような、一貫性に欠ける構築・運用方法を選ぶことが往々にしてあります

状況と前提条件の中で、どういう決断をするのか. 何が自分たちと自分たちのシステムにとってベストなのかをどうやって判断するのか. これが EKS(Kubernetes) が ECS と比較して『難しい』と言われる正体、その理由の1つ

思想や哲学に基づかない、プラットフォームの敷いたレールを外れた形でものを組み上げようとすると、歪みやアンチパターンを巻き込んだ構造物が仕上がります

https://twitter.com/jyoshise/status/1210443630197923840

ひとつのシステムの中にも、単体での可用性・整合性を保証しなければならない要素と全体のResiliencyで吸収できる要素があって、その実現方法もテクノロジーの発展により変化していく中、画一的なルールで縛るのではなく、最適なアーキテクチャを考えては適用していくということを継続するべき

https://gcn.com/articles/2020/01/07/af-kubernetes-f16.aspx https://thenewstack.io/how-the-u-s-air-force-deployed-kubernetes-and-istio-on-an-f-16-in-45-days/ 米軍のCloudNative事例。F-16の中でk8sとIstioが動いている…！？

https://twitter.com/ido\_kara\_deru/status/1215660248964317186

Cloud Native DevOps with Kubernetes、1章にあるCloud Nativeの特徴の説明が納得感があってとても良い。 CNCFの定義はあくまでCloud Native Tech.に対する説明だし、Cloud Nativeそのものを真っ向から言語化した文献初めて見たかも。

クラウドネイティブなシステムの特徴として、多くの人が同意するであろうもの：

  • Automatable(自動化可能である)
    • 人ではなく機械がアプリケーションのデプロイや管理をしていれば、共通基準やフォーマット、インターフェースに従う
    • k8sはアプリケーション開発者がそれらを気にすることにない標準インタフェースを提供する
  • Ubiquitous and flexible
    • 物理リソースから切り離すことでノード間の移動やクラスタ間の移動が容易になる
  • Resilient and scalable
    • トラディショナルなアプリケーションはSPOF(単一障害点)を持ちがち（プロセスがクラッシュしたり、ハードウェアの異常だったり、ネットワークの混雑によりアプリが止まる）
    • CloudNativeアプリケーションは生まれつき分散されていて、常用性と安全な品質低下？によってHAとなる
  • Dynamic
    • k8sのようなコンテナオーケストレーたーは利用可能なリソースを活かすためコンテナのスケジューリングを行う
    • HAを獲得するための多くの複製を動かすことができ、トラフィックを落とすことなくサービスをスムーズにローリングアップデートできる
  • Observable
    • CloudNativeアプリは調査とデバッグが大変
    • 分散システムにおける重要な要素がObservability。これはモニタリング、ロギング、トレーシング、メトリクスで、システムが何をしているかをしる助けとなる。
  • Distributed
    • クラウドネイティブはクラウド上で分散型・非中央集権型の性質を活用するアプリケーションを構築・実行するためのアプローチである
    • どこで動くかではなく、どのように動くか。
    • シングルエンティティとしうてアプリケーションをデプロイする代わりに、CloudNativeアプリケションは複数の協調する分散されたマイクロサービスとして構成される傾向がある
    • マイクロサービスは1つのことを行う自己完結型のサービスで、組み合わせることでアプリケーションとなる

マイクロサービスは万能ではない話も書かれている。

Kubernetesがいかに自動化の考え方を変えたか? | SOTA https://deeeet.com/writing/2018/12/13/how-kubernetes-change-our-way-of-automation/

Kubernetes以前の自動化ではコマンドラインツールを書くバッチスクリプトを書くもしくはAnsibleのplaybookやChefのRecipeを書くといった手法が使われてきた

個々のControllerはシステムの一部の小さな機能を担っており他のシステムの状態に関しては感知しない．それぞれがそれぞれの問題のみを解決する．UNIX哲学的に作られた独立したControllerの集合こそがKubernetesである．

「Edge Triggering」はSignalの変化に対して反応し，「Level Trigger」は状態を検知して反応する．

バッチを動かすのではなくコマンドを人間が実行するのではなく「Reconciliation Loop」で解決することを考える．

「自動化」するためのコードというよりは、「自律的」にするためのコードという感じ

https://kubernetes.io/docs/concepts/overview/what-is-kubernetes/ デプロイにおける3つの時代：

  • Traditional deployment era
  • Virtualized deployment era
  • Container deployment era

何をして、何をしないかも書かれている

https://twitter.com/int128/status/1192619168601788416?s=20

Kubernetesは12 factor, CI/CD, Monitoringなどのサボってた問題を次々と顕在化させてくれるので、まるでScrumのようだ。強制ギプスといえるのかも

https://twitter.com/udzura/status/1154612144358342656?s=20

10人ぐらいのチームでもそれぞれのマイクロサービスをコンテナにして単体でテストしやすく、かつ統合時の環境もk8sでローカルやステージングで作りやすくするメリットはあるのでは、でもk8sに興味がないんならしょうがないっすね...

https://twitter.com/kis/status/1154614523120066561

k8sに興味がないだけでしょうがなくなるのであれば、興味があっても使わないほうがいい気がする。技術的負債になってしまわない？

https://twitter.com/udzura/status/1154616036294983680

僕の言い方だとそう取られてしまいますね。まず、僕の元の発言は、あるシステムを組むときにPaaS/FaaSを組み合わせるか自分たちでコンテナにしてk8s等オーケストレータに載せるかという選択肢があるのなら、後者は環境の再現性やポータビリティにメリットがありそう、と言い直します

https://twitter.com/udzura/status/1154616801814306818

その上で技術的負債になるかならないか、ですが、コンテナに分割する設計がうまく行っていればそもそもPaaS/FaaSへの載せ替えは容易であろうこと、コンテナオーケストレータ自体は無くならないであろうこと、k8sの強力なコミュニティを今見ていることから、単純には負債にならないかと考えています

https://twitter.com/jyoshise/status/1131552780060155904?s=20

K8s構築してくれじゃねーよ、K8sは"Platform of Platforms" なんだよk8s使ってどんなPlatformsを構築するかが俺たちの仕事なんだよわかってんのか？と覚えた言い回しさっそく使って、昨日から社内のやりとりでドヤりまくっている

https://twitter.com/jyoshise/status/1113094110703845376?s=20

k8sは全体最適化のためのものであって、個別のサービス/アプリケーションだけ見てる人が「k8sいらねー」って言ってもまあそりゃそうだろうなあ、あなたにとっては。としか言えない

https://twitter.com/superbrothers/status/1113215299036176384

開発成果をもっとも素早くプロダクションに届けるために何を使うかという話で、PaaS や FaaS では要件に合わないときに、これまでは VM を使うしかなかったところに Kubernetes が使えると思っている。

https://twitter.com/superbrothers/status/1113215666679468032

難しさの点では PaaS と比べるとインフラが透けてみえるので、もちろん難しくなる。PaaS はソースコードをコミットすればデプロイされるが変更できる余地が少ない。Kubernetes では CI/CD を自分たちで用意しなければならないが自由にできる。

https://twitter.com/superbrothers/status/1113216433733771265

Kubernetes は一般に PaaS より難しく自由度が高いが、VM より簡単で（利用限った話でクラスタの運用は含まない）自由度が低い。Kubernetes に”不要な”難しさを感じるなら、PaaS を検討するべき。

https://twitter.com/superbrothers/status/1113233846894354433

Kubernetes で良いなと思うことは、Google が考えるアプリケーション(コンテナ)を安定運用するために必要なことがマニフェストの設定として定義されて定型化されていること。この知識は他の環境でアプリケーションを運用するときにも役に立つので、学ぶ価値がある。

多分あなたにKubernetesは必要ない https://yakst.com/ja/posts/5455 k8sではなくNomadを採用した事例

https://twitter.com/matsumotory/status/1113254509592010754?s=20

クラウドネイティブの時代には後方互換性とかよりも、ベンダーやOSSへの依存を避けるという意味でも、いかに異なる仕様とその変更に対して追従できるようなシステム設計を追求するのが大事なんじゃないの。というかそれがクラウドネイティブなんじゃないかと

https://twitter.com/ymmt2005/status/1113510647021494272

Kubernetes 難しいかどうかはさておき、使いたい大きな理由としてエコシステムがどんどん拡大しているのは指摘しておきたい。良い周辺ミドルウェアが多数あるので、工夫次第で工数節約できる。

https://twitter.com/ymmt2005/status/1113511524658581504

難しい・易しいは受け取る人次第なので絶対的なことは言えないけど、私にとって Linux カーネルやデータベースやコンパイラよりずっとシンプルで易しい。設計の筋が良いのが特徴で、その仕事は素晴らしいものだと思っている。

https://twitter.com/ymmt2005/status/1113515967634493440

特に良い点として、JSON オブジェクトを etcd に登録するだけの宣言的 API が挙げられる。Kubernetes のその他の機能は皆、オブジェクトの状態に応じて何かをするという形に一般化されており、オブジェクトを見て何かをする人は自作も可能なため無限の拡張性を持つ。

https://twitter.com/ymmt2005/status/1113515968469159936

なので、Kubernetes が持つ拡張性と、その拡張性が生んだエコシステムを活用したいかどうかで採用するしないを考えるのがよろしいのではないか。コンテナ管理に使うだけは少しもったいない、かも。

  • 書籍
    • Cloud Native Infrastructure (2017-11)
    • Cloud Native Patterns (2019-05)
    • Programming Kubernetes (2019-06)
  • 論文
    • Understanding Cloud-native Applications after 10 Years of Cloud Computing - A Systematic Mapping Study (2017-01)