BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ ニュース DatadogがKubernetesで大規模クラスタを実現するまで

DatadogがKubernetesで大規模クラスタを実現するまで

原文(投稿日:2019/12/05)へのリンク

DatadogのLaurent Bernauille氏がベルリンのVelocityカンファレンスで、自己管理型Kubernetesクラスタを大規模に運用する際の課題について講演した。Bernaille氏が焦点を当てたのは、レジリエントでスケーラブルなコントロールペーンを設定する方法、証明書(certificate)を高頻度でローテーションする理由と方法、Kubernetesで効率的な通信を実現するためにネットワークプラグインを使用することの必要性、といった話題だ。

従来のアーキテクチャにおけるアプローチは、すべてのKubernetesのマスタを単一サーバに配置して、高可用性のため最低3つのサーバを使用する、というものだった。しかしながら、これらコンポーネントの責務はそれぞれ違うため、同じようにスケールアップすることはできないし、その必要もない。例えば、スケジューラとコントローラはステートレスなコンポーネントなので、ローテーションは容易だが、etcdコンポーネントはステートフルであるため、データの冗長コピーを必要とする。さらにスケジューラのようなコンポーネントでは、唯一のインスタンスがアクティブになるような選挙(election)メカニズムも必要になる。だからスケジューラのスケールアウトには意味がない、とBernaille氏は言う。

そのためDatadogでは、Kubernetesのコンポーネントを別々のサーバに分けて、それぞれにリソースと独自のスケーリングポリシを設定することにした。APIサーバのようなコンポーネントには、その前にロードバランサを配置して、要求を正しく分散できるようにした。etcdサーバも同じように分割して、Kubernetesイベントのみを処理するetcdクラスタを用意した。

次にBernaille氏が指摘したのは、Kubernetesがすべてのコンポーネント間の通信に証明書を使用する点だ。そこで、証明書の期限切れのような問題を回避するため、Datadogでは証明書を毎日ローテーションすることにした。ただしKubernetesでは、さまざまなコンポーネントとサーバにいくつもの証明書をインストールして使用するため、証明書のローテーションは難しい作業になる。さらに、ローテーション毎にAPIサーバなどのコンポーネントの再起動が必要になることも分かっていた。そこでDatadogでは、毎日の証明書のローテーションを自動化し、HashiCorp Vaultを使用して起動することにした。

ただし、kubuletは証明書をオンデマンドで生成するという方法を用いているため、kubeletには日毎のローテーションに例外ルールを設けることにした。問題や手順の複雑さはあるが、Bernaille氏は証明書を頻繁にローテーションすることを推奨する。簡単なタスクではないが、将来的に証明書が期限切れになることを防止して、ログに痕跡が残らないようにすることが可能になるからだ。

Datadogはプラットフォームを動作させるために多くのサーバを必要とするため、ネットワーク上の問題がある、ともBernaille氏は述べた上で、その前提として、Kubernetesのノードがpodにアサインするための一連のIPアドレスを持っていることを、時間を割いて説明した。そのため、小規模なクラスタであれば、pod間の通信を静的に設定しても問題はないが、中規模のクラスタでは、トンネルを経由してノード通信を行うネットワーキングオーバーレイの使用などが、適切に動作するアプローチになる。Datadogでは、同社に適したアプローチとして、ネットワーク全体でルート可能なIPをPodに与える方法を採用している。この方法では、podへの通信は直接行われるため、kube-proxyのような介在は必要なくなる。GCPはこのモデルをIPエイリアスでAWSはENI(Elastic Network Interface)でサポートしている。オンプレミスではCalicoなどのツールが利用可能だ。

最後にBernaille氏は、異なるクラスタ間の通信について語った。デフォルトでは、Kubernetes内において、外部からの要求がクラスタに到達した場合、そのトラフィックはkube-proxyを通じてルートされる。しかし、送信先のpodが動作していない不正なノードに要求が到達した場合には、kube-proxyはその要求を適切なノードにリダイレクトしなければならない。外部トラフィックポリシの生成ingressコントローラを使用するという方法もあるが、大規模なクラスタへのスケールアップが難しい。そこでDatadogでは、AWSのALB ingress contollerを通じたネイティブルーティングを、HTTP通信のみに使用した。

講演の終わりにBernaiile氏は、DNSなどのコンポーネントやステートフルなアプリケーション、あるいはアプリケーションのデプロイメントにも別の問題があると延べて、参考資料としてJerome Petazzoni氏のKubernetes内部を詳細に取り上げた講演や、前回のKubernetes導入の難しさに関するDatadogの講演を見るように推奨した。

この記事に星をつける

おすすめ度
スタイル

BT