Calendar参戦です。GMOアドマーケティングの佐藤です。弊社では今年3つのマイクロサービスにKubernetesを導入しました。minikubeのローカル環境で開発、ステージング環境でテスト後、本番環境にデプロイします。弊社ではGKEを使っていますが、ローカルではうまくいっても、本番にデプロイした際に、いくつかのトラブルに見舞れることがありましたので、その内容と解決方法を共有できればと思います。Instanceが買えない場合がある広告のサービスはピーク時間帯とアイドル時間帯でアクセスが10倍以上違う場合があるため、アクセスに応じてオートスケールするように設定しています。いう、24時間以内に終了してしまう、通常より最大80%の割引を受けれるインスタンスを利用しています。instanceを利用しています。Instanceが買えないケースに遭遇しましたので以下のような対応をしました。デフォルトのノードを作ります。instanceのノードを作ります。Affinityを設定します。PoolにPodを配置します。Poolを利用するようにします。PoolのInstanceが使用されます。Preemptiveインスタンスと違い、24時間では終了されず、確約利用割引もないため、そのまま高いインスタンスが居座ってしまいます。Jobとして定期実行しています。Kubernetesのpodを作成するときに重要な点としてあるノードが突然killされても大丈夫なようにpod内のアプリケーションを作成するあるノードが突然killされても大丈夫なようにpodを配置する(SPOFを無くす)どの順番でpodが起動しても問題ないように設定をする突然Nodeがkillされても負荷等に問題が無いようにある程度余裕を持ってリソースを割り当てるがあります。Instanceなどが突然終了しても問題なく自動で復旧できます。resource.limitがあります。300MiCPUは1coreで1000mの計算です。上記設定の600mだと、1coreの6/10を要求します。ここで設定の際にいくつか気をつけなければならない点があります。設定ファイルの合計要求リソースがノードの合計リソースを下回っていてもデプロイできない場合があるrequestsを設定すると、実際に使っていなくても、設定ファイルの合計値が物理ノードの合計値を超えることができません。ノード3つで構成した場合、3個まではpodを増やせます。3000を下回っているので、一見デプロイできるように見えますが、実際は下図のようにデプロイできません。1000mcpuが割り当てられるわけではない実際のnodeは1core(Standard1)のノードを起動しても、1000mを使えるわけではないです。下の図を見ると実際には、940mしか割り当てられていません。1000を割り当てると1podもデプロイすることができません。AutoScalerの設定limits.cpuは設定ファイルの合計値が物理ノードの最大値を超えても、遅くなるだけで問題ありません。killerがprocessをkillします。killerが発生します。50%を超えるとオートスケールが実行されます。不良のnodeを引き当ててしまうまれにネットワークカードなどが物理的に壊れているインスタンスがノードが割り当てられてしまうことがあります。その場合、podが突然終了したり、再起動を繰り返したりすることがあります。nodenameなどでノードを削除しても、同じ物理サーバを使ってノードを作成してしまうため問題が解決されない場合があります。GCEの管理画面上から、直接削除を行っています。削除が終わると、Kubernetesが設定に従って、自動的にインスタンスを増やそうとします。この点はまだ自動化できていないので、今後の解決したい課題でもあります。常にproduction環境を再構築できるようにしておく現在Kubernetes関連のプロジェクトは活発に開発が行われており、頻繁に本体のバージョンアップも行われています。稀に不安定なバージョンがリリースされることもあります。Ingressに大きな変更がある時や、Kubernetes本体のバージョンを上げる場合は、別に新しいproductionクラスターを作り、GSLBを利用して一部のトラフィックを流すようにして、問題なければ、全部のトラフィックを新本番に切り替えて、旧本番クラスターを削除するようにしています。GSLBを使っています。DNSのCNAMEにGSLBのアドレスを書くことによって、GSLBの重み設定に従って負荷を振り分けてくれます。振り分け先IPアドレスの死活監視も行っており、対象サーバが接続できなくなると自動的に振り分け先から外してくれます。GSLBを用いることで、アプリケーションによってはマルチリージョン化、マルチクラウド化なども簡単に行うことができます。gcloudコマンドなどを利用して、すぐに新しいproduction環境を作れるようにしています。Kubernetesについては社内でまだまだやれることは多いですが、インフラチーム、SREチームが行わなければならない運用を減らせることができていると感じています。溜まったノウハウなどがあったらまた投稿できたらと思います。ブロックチェーンを作ってみました。@gmoap_engineer本ブログで発信される情報は、各エンジニア個人の見解であり、弊社の公式見解ではありません。本ブログに掲載、引用等をしている商品またはサービス等の名称は、各社の商標または登録商標です。その他の事項について一切責任を負いかねます。発表する情報には注意を払っておりますが、公式発表、見解については、弊社WEBサイトおよびプレスリリースなどをご確認ください。GMOインターネットグループにおけるソーシャルメディア運用ポリシーについては次のページをご確認ください。本ブログに掲載のあるソフトウェアのダウンロードは自己責任で御願い致します。ソフトウェアのダウンロードの結果、ご利用者に何らかの損失・損害が生じたといえども、当社ではその責任を負いかねます。本ブログに掲載のあるソフトウェアを扱う際は、各ソフトウェアの公式リファレンスを参照のもとご使用下さい。ソフトウェアの実行の結果、ご利用者に何らかの損失・損害が生じたといえども、当社ではその責任を負いかねます。