Google Cloudとコンテナの継続的なセキュリティ
本文の内容は、2020年11月3日にDavid Lorite Solanasが投稿したブログ(https://sysdig.com/blog/how-to-monitor-coredns/)を元に日本語に翻訳・再構成した内容となっております。
Kubernetes クラスターで最も一般的な問題や停止は coreDNS に起因する事象であり、coreDNS を監視する方法を学ぶことは非常に重要です。
フロントエンドアプリケーションが突然ダウンしたとしましょう。しばらく調査した後、DNSが500のエラーコードを返し続けているため、バックエンドのエンドポイントを解決できていないことがわかります。この結論に早くたどり着くことができれば、アプリケーションをより早く復旧させることができます。
coreDNSを監視することで、クラスターが最悪のタイミングでダウンして手遅れになる前に、問題を修正する時間を確保することができます。
落ち着いて DNS をチェックしましょう。
coreDNSはKubernetesのバージョンv1.12以降のデフォルトのkube-DNSで、推奨されているDNSサーバーです。各ポッドやサービスが完全修飾ドメイン名（FQDN）を持つため、重要なコンポーネントです。kube-dnsがダウンすると、クラスタのすべてがダウンします。
通常はマスターノードで coreDNS を実行しているのを見ることができますが、Docker のようなコンテナを使用する非 Kubernetes 環境でサービスディスカバリを提供するためにベアメタルで実行することもできます。
CoreDNSはインストルメントされており、Kubernetesコントロールプレーンの他のコンポーネントと同様に、ポート9153でPrometheusメトリクスを公開しています。これはDNSサーバーへのリクエストと内部のプラグインに関する情報を提供します。クラスターのサイズに応じて、レプリカは1つまたは複数になります。各レプリカでCoreDNSをスクレイプする必要があります。
エンドポイントにアクセスしてメトリクスを取得することができます：
curl localhost:9153/metrics
そして、この構造を持つメトリクスのロングリストを返します。(省略）
# HELP coredns_build_info A metric with a constant '1' value labeled by version, revision, and goversion from which CoreDNS was built.
# TYPE coredns_build_info gauge
coredns_build_info{goversion="go1.14.4",revision="f59c03d",version="1.7.0"} 1
# HELP coredns_cache_entries The number of elements in the cache.
# TYPE coredns_cache_entries gauge
coredns_cache_entries{server="dns://:53",type="denial"} 41
coredns_cache_entries{server="dns://:53",type="success"} 15
# HELP coredns_cache_hits_total The count of cache hits.
# TYPE coredns_cache_hits_total counter
coredns_cache_hits_total{server="dns://:53",type="denial"} 366066
coredns_cache_hits_total{server="dns://:53",type="success"} 135
# HELP coredns_cache_misses_total The count of cache misses.
# TYPE coredns_cache_misses_total counter
coredns_cache_misses_total{server="dns://:53"} 106654
# HELP coredns_dns_request_duration_seconds Histogram of the time (in seconds) each request took.
# TYPE coredns_dns_request_duration_seconds histogram
coredns_dns_request_duration_seconds_bucket{server="dns://:53",type="A",zone=".",le="0.00025"} 189356
coredns_dns_request_duration_seconds_bucket{server="dns://:53",type="A",zone=".",le="0.0005"} 189945
coredns_dns_request_duration_seconds_bucket{server="dns://:53",type="A",zone=".",le="0.001"} 190102
coredns_dns_request_duration_seconds_bucket{server="dns://:53",type="A",zone=".",le="0.002"} 235026
Prometheus で coreDNS を監視するには、対応するジョブを追加するだけです。
- job_name: kube-dns
honor_labels: true
kubernetes_sd_configs:
- role: pod
relabel_configs:
- action: keep
source_labels:
- __meta_kubernetes_namespace
- __meta_kubernetes_pod_name
separator: '/'
regex: 'kube-system/coredns.+'
- source_labels:
- __meta_kubernetes_pod_container_port_name
action: keep
regex: metrics
- source_labels:
- __meta_kubernetes_pod_name
action: replace
target_label: instance
- action: labelmap
免責事項: coreDNSのメトリクスはKubernetesのバージョンによって異なる場合があります。ここでは、Kubernetes 1.18とcoreDNSのバージョンを使用しました。バージョンに応じたメトリクスはKubernetesのレポで確認できます。
リクエストレイテンシー：ゴールデンシグナルに続いて、リクエストの待ち時間は、サービスの劣化を検知するための重要なメトリックです。これをチェックするには、常にパーセンタイルと平均値を比較しなければなりません。Prometheus でこれを行うには、演算子ヒストグラムを使用します。
histogram_quantile(0.99, sum(rate(coredns_dns_request_duration_seconds_bucket{job="kube-dns"}[5m])) by(server, zone, le))
エラーレート：エラーレートは、監視しなければならないもう一つのゴールデンシグナルです。エラーはDNSの失敗が原因とは限りませんが、それでも注意深く監視しなければならない重要な指標です。エラーについての coreDNS の重要なメトリクスの 1 つは coredns_dns_responses_total であり、コードも関連しています。例えば、NXDOMAINエラーは、クエリされたドメイン名が存在しないためにDNSクエリーが失敗したことを意味します。
# HELP coredns_dns_responses_total Counter of response status codes.
# TYPE coredns_dns_responses_total counter
coredns_dns_responses_total{rcode="NOERROR",server="dns://:53",zone="."} 1336
coredns_dns_responses_total{rcode="NXDOMAIN",server="dns://:53",zone="."} 471519
etcdを監視するときと同様に、coreDNSのポッドはデフォルトではアノテーションされていません。Sysdigエージェントでメトリクスを取得するには、アノテーションを付ける必要があります。
さらに簡単なのは、 promcat で与えられた手順に従ってコントロールプレーン全体を監視し、必要なメトリクスだけを Prometheus サーバにフェデレートして、それ以外のものはすべて捨ててしまうことです。
既に helm と helmfile を持っていれば、プロセスは簡単です。そうでない場合は、公式の指示に従って helm をインストールし、次に helmfile をインストールすれば簡単にインストールできます。これら2つのアプリケーションを使用すると、適切なルールと設定でPrometheusサーバーをすぐにデプロイすることができます。これには、対応するファイル、helmfile.yaml、recording_rules.yaml、prometheus.yaml、およびprometheus.yml.getmplが含まれています。
この行を実行するだけです：
helmfile sync
Prometheusサーバーをインストールしたら、次はSysdigエージェントを設定します。configmapに以下をコピーすることで設定できます。
apiVersion: v1
kind: ConfigMap
metadata:
name: sysdig-agent
namespace: sysdig-agent
data:
prometheus.yaml: |-
global:
scrape_interval: 15s
evaluation_interval: 15s
scrape_configs:
- job_name: 'prometheus' # config for federation
honor_labels: true
metrics_path: '/federate'
metric_relabel_configs:
- regex: 'kubernetes_pod_name'
action: labeldrop
params:
'match[]':
- '{sysdig="true"}'
sysdig_sd_configs:
- tags:
namespace: monitoring
そして、このコントロールプレーンダッシュボードを promcat から追加します：
このコマンドを実行するだけです：
docker run -it --rm \
sysdiglabs/promcat-connect:0.1 \
install \
kubernetes-control-plane:1.18.0\
-t YOUR-API-TOKEN
coreDNSはクラスタ内で最も一般的な問題の発生源です。DNSが障害を起こすと、多くのサービスが（すべてではないにしても）障害を起こし、アプリケーションがダウンしてしまいます。coreDNSを監視することで、問題が発生する前に問題を修正したり、トラブルシューティングをして問題から素早く回復することができます。
Sysdig MonitorでcoreDNSを監視するのはとても簡単です。たった1つのツールで、coreDNSとKubernetesの両方を監視することができます。Sysdig MonitorエージェントがすべてのcoreDNSのメトリクスを収集し、最も重要なcoreDNSのアラートを素早く設定できます。
まだSysdig Monitorをお試しになっていない方は、1クリックで無料トライアルをご利用いただけます。