GGG

プログラミング言語やソフトウェア開発について思ったことを書いてます

【感想】Kubernetes on AWS アプリケーションエンジニア 本番環境へ備える

kubernetes SRE AWS EKS

Kubernetes on AWS～アプリケーションエンジニア 本番環境へ備える

概要

誰向け？

アプリケーションエンジニアのための書籍

つまり利用者としての立場の方に向けて書かれているような書籍。 EKSを使って構築していくサンプルコードもあるため、動作確認をしながら進められる。

試用時の料金について

EKSは無料ではないため、個人で動作検証する場合にはお金がかかるので注意。

どれくらいかかるかは、書籍に記載してあります。

注意事項「使い終わったらすぐ消す」を意識しましょう。

Kubernetesの詳細度について

kubernetesの詳細な挙動には、触れられておりません。

あくまでも読者の対象者はアプリケーションエンジニアのようです。

要所はしっかり説明してくれているので、さらに理解を深めたい場合には他の書籍をあたると良いと思います。

図解やコラムも豊富です。

そのため、「利用者」としての視点を大切にしているように見受けられる。 これからEKSを構築しようと考えているインフラエンジニアの方にも良いと思います。

Kubernetesへのとっかかりとしてはかなりの良書と思います。書籍がたくさん出ており、何から読み始めるか困ってるいる方は、この本を手にとってみてはいかがでしょうか。

気になったこと

EKS with farget

  • 本書で紹介されているEKS with fargate の構成にとても魅力を感じました。
  • EC2とFargateを混在できることを知りませんでした
  • スケールIN/OUTが何度も発生するようなDeploymentについてはFargateを採用することでワーカーノードのスケール・IN/OUTを考慮する必要性が減りそうです。
  • 保守・運用を2年半以上おこなってきた経験からの辛みからの解放
    • 脆弱性対応やVersionUpに伴うノードの更新作業から解放されるのは非常に大きいメリットと言えます

課題

Fargateは、データプレーンがブラックボックス化されている。 それに伴う様々な制約がある。

  • ワーカーノードへのマウントができなくなります。
  • DaemonSetも使えません。
    • モニタリングやロギング基盤をそのままはできない可能性が高いです。
  • 直近ではEFSがサポートされたため、StatefulSetを利用することはできるようです。

もし、DaemonSetでFluentD / Fluent-bitをScheduleされているようでしたらサイドカーパターンを使うなど何かしら別の方法での対応が必要となりそうです。

この辺のベストプラクティスがまだ確立されていないようですね。 これからのどういった動きがあるのか期待。

TIPS

preStop

  • デプロイする際に数秒間502   のエラーが出ることがあり悩みのタネでした。 preStopを利用することで発生をゼロに抑えられそう。

この本に出会えていなかったら、ずっと悩んでいた未解決の問題として残りそうでした。 今、トライ中！

kubernetes 構築時に既存VPCを使うか、新しく既存VPCを作ってクラスターを構築するか

  • 既存VPCを使った方が柔軟性が高いと記載されていた。 どっちが良いのか、何がGoodPracticeなのかずいぶん悩んだものだが、これで多少すっきりした。

セキュリティについて

紹介されておりました。CIにいれると良さそうです。

イメージスキャン

  • Privy
  • microscanner

ふるまい

  • Falco

商用製品

  • Sysdig
  • Aqua

そのネットワークポリシー、セキュリティーポリシー本当に必要？

今まで、設定するのが「是」であった。この問いは私には衝撃的だった。 そもそもクラスタを分けてしまってロードバランサー（ELB)を介してアクセスを強制することで、自動的にアクセスポリシーができあがる。

複数台クラスタ運用をすると別の新たな課題は発生する。 しかし、１クラスタ内でセキュリティ設定を頑張るのではなく、複数クラスタに分けることでセキュリティポリシーを満たす。

煩雑なNamespaceなどによる制約を設けるよりもクラスタ内での自由度は高くなって良さそうだ。

私の経験

Kopsを使って kubernetes on EC2 を実現して２年半以上本番環境で稼働させております。

Managedサービス利用のススメ

クラスタやメトリクス、モニタリング、ロギングのスタックについて

自前で構築すると保守・運用が大変 SaaS系を使ったり、お使いのパブリッククラウドが提供しているサービスを使うなどして、SelfManagedしないようにした方が良さそうです。 私自身、マネージャを務めるSREはまだまだ小さい組織です。

導入当初は、外部に支払うコストを減らすために自前で構築して運用を進めておりましたが事業規模が大きくなり、クラスターが増え、見るメトリクスが増えるなどの運用負荷増大につれて徐々に運用が辛くなってきました。

現在は、SaaSへの置き換えを進める（ある意味で自動化）ことで、改善作業への取り組むための時間を確保しようとしております。 当然、どれくらいのコストがかかるかは事業規模等によりますがSaaS置き換えによるランニングコストと移行の負荷が妥当であれば十分検討可能なのではないかと思います。

組織は大きくないけど、Kubernetesいれたいよね。という組織にはManagedで整備するのがお勧めです。