4年ほど本番運用してきたGoogle Kubernetes Engine。４年の間で変化し続けてきた弊社のIngress周りの歴史 きづけば2021年ですね。12月末に書いたこの記事は年末休暇の関係で、公開がこのタイミングになりました。あけましておめでとうございます。 今回は、マネーフォワードケッサイが利用しているGCP/GKEのIngreeまわりを振り返ってみたいとおもいます。 創業初期 2017年3月時点ではGCPには証明書を自動的に作成する仕組みがなかった事もありますが、まだまだ証明証は信用の為にEVを買うという考えが強かったので、EV証明書とワイルドカード証明書を購入してIngressに設定してました。 証明書の自動作成と更新できるように ユーザが利用するドメインのみ購入した証明書を使い、社内利用のドメインは、cert-managerを利用して作成したLet’s Encriptの証

*1 デフォルトでは Pod に割り当て可能なセカンダリ IP アドレスを ENI 1個分(その ENI に割り当てできる最大数)確保する設定ですが、実際には DaemonSet などがありすぐに ENI 1個分の空きという条件は満たさなくなるので、ワーカーノード起動時に ENI 2個分(「そのインスタンスタイプが ENI ごとに割り当てできる IP アドレス数」の2倍)が確保されるということになります。ドキュメントとしては次のリンクをご参照ください。 参考: https://docs.aws.amazon.com/ja_jp/eks/latest/userguide/cni-env-vars.html 参考: https://github.com/aws/amazon-vpc-cni-k8s/blob/master/docs/cni-proposal.md 例えば、ピーク時に c5.4x

※この投稿は米国時間 2020 年 1 月 8 日に、Google Cloud blog に投稿されたものの抄訳です。 数年前、Kubernetes はコンテナ化されたアプリケーションの管理をサポートし、大いに注目を集めました。今では、本番環境でのアプリケーションの大規模なデプロイや管理に広く使用されています。その過程で私たちは、Kubernetes と Google Kubernetes Engine（GKE）を最大限に活用するためのヒントやベスト プラクティスを収集してきました。ここでは、Kubernetes のデプロイと利用方法に関する Google Cloud ブログのなかから、最も人気の高い記事の一部をご紹介します。 リソース管理を容易にする Kubernetes の Namespace : Kubernetes 上でサービスを構築すると、単純なタスクが複雑になっていきます。一種

とあるスマートフォン向けMMORPGのプロジェクトで、アプリケーションサーバをほぼすべてGKE(Google Kubernetes Engine)に乗っけて動かしていました。 このゲームは、モバイル向けながら、複数プレイヤ間でそこそこリアルタイム性の高い同時プレイができるものでした。同じフィールドを誰かが歩けば、自分が見ている画面でもほぼ同時にそいつが歩いて横切っていく、同じ敵と皆で一緒に戦えば、誰かが繰り出した攻撃が参加者全員の画面に即同期される、もちろんチャットもできる、そんな具合です。今ではさほど珍しくないのかもしれませんが、PCのオンラインゲームのような機能を搭載した、リアルタイム性の高いモバイルゲームでした。 さて、こうなってくると、オーソドックスなWebサーバのような、HTTP/1でリクエスト/リプライを捌く、というサーバだけでは要件を満たすことができません。 複数プレイヤ間で

この度、Kubernetesの認定資格「CKA(Certified Kubernetes Administrator)」を取得いたしました！ 今後受ける方のお役に立てばと、受験レポートを残しておきます。 要約 〜忙しい人はここだけ読んでね〜 試験に関する説明の書かれている英語のドキュメント「Handbook」「Important Tips」を熟読しよう！ 「Kubernetes完全ガイド」の4章から8章は可能な限り、9章から12章は余力と相談して押さえておこう！ 「Kubernetes The Hard Way」を1度実施し、各オペレーションの意味を理解しておこう！ 受験動機 私の場合は、今まで培ってきたKubernetesの技術知識を試すことが目的でした。また副次的な目的で、社内でコンテナ技術推進活動をしているため、その発言に説得力をもたせる意味もありました。 「Kubernetesの技

まぁこれは基本的に膨大なログを見ている時に、ピンポイントで絞り込み検索をするという行動を前提としてるからだと思うんだけど、デバッグとかしてるときは「スゴク、コレジャナイ感…」がするわけです。 なので、そんな時はもう素直にkubectl get podsして、kubectl logs -f …. している自分がいました。 まぁこれでも充分なんです。充分なんですけど、辛い事が二つあって。 まず複数のコンテナにロードバランスされるペイロードに関しては自分が見てるコンテナにアクセスが来るとは限らないから全部のコンテナのログを見てるか、自分の見てるコンテナにアクセスが来るまで読み込み続けなければならない。 もうひとつは、開発をしている間の話なので、kubectl applyでdeploymentをガンガン入れ替えているのでコンテナもどんどん世代交代するわけです。そうすると… そう、当然コンテナはデコ