k 8 sとdns-corednsのいくつかの実戦経験
corednsの概要
新しいバージョンk 8 sをインストールし、corednsはデフォルトdnsになりました.以前はkube-dnsでした.corednsは、KubernetesクラスタDNSとして機能する柔軟で拡張可能なDNSサーバです.Kubernetesと同様にCoreDNSプロジェクトはCNCFが主宰する.しかし、実際の使用では、いくつかの注意点が必要です.
アプリケーションの反親和性を向上させ、corednsが1台のホストにスケジューリングされることを防止
corednsに必要なリソースは非常に小さいので、ホストに簡単にスケジューリングできます.corednsはシステムコンポーネントであり、corednsをできるだけ分散して導入し、可用性を向上させる必要があります.したがってdeploymentのyamlでは、次の設定を追加します.
ここではk 8 sの属性反親和性を利用した.
合理的なcoredns伸縮を選択
多くのk 8 sデプロイでは、デフォルトでは2つのcorednsインスタンスがデプロイされますが、クラスタが徐々に大きくなると、2つのインスタンスは需要を満たすことができません.したがってcorednsの伸縮は非常に重要である.corednsはhpaでcorednsを弾性伸縮させないでください.頻繁な伸縮は,業務の多くのdns解析に失敗する場合を招く.cluster-proportional-autoscalerコンポーネントを使用する必要があります.私は一般的にnodeノード数に基づいてdnsを伸縮することを選択します.具体的な伸縮戦略は皆さんが選択できます.
corednsを使用してipv 6の解析を無効にする方法
K 8 SクラスタホストがIPV 6カーネルモジュールを閉じていない場合、コンテナがcorednsを要求するときのデフォルトの動作は、IPV 4とIPV 6の解析を同時に開始することである.私たちは通常IPV 4アドレスしか使用しないか、ホスト環境に対してipv 6を一時的にサポートしていないため、実際のビジネスシーンでは、AAAA解析に成功して返されたIPv 6アドレスは、アクセスに失敗します.次のようになります.
したがって、corednsでDOMAIN->IPV 4アドレスの解析を構成するだけでは、corednsがIPV 6解析要求を受信すると、ローカルで構成が見つからないためfowardがupstream DNSサーバに解析され、コンテナのDNS解析要求が遅くなる.corednsはpluginをtemplateと呼び、構成後、すべてのIPV 6要求に直ちに空の結果の応答を返すことができ、forwardを上流DNSに要求することを避けることができる.ビジネスではipv 6解析が成功せず、ipv 4のA解析に降格します.templateプラグインのデフォルトはcorednsで有効です.プロファイルに次の構成を追加するだけです.
coredns構成stub domainとupstream nameserver
実際のシーンでは、Consulドメインサーバが10.150.0.1にあり、すべてのConsul名に接尾辞.consul.localがあるなど、独自の内部dnsサーバがあります.CoreDNSで構成するには、クラスタ管理者がCoreDNS ConfigMapで次の構成を作成します.
新しいバージョンk 8 sをインストールし、corednsはデフォルトdnsになりました.以前はkube-dnsでした.corednsは、KubernetesクラスタDNSとして機能する柔軟で拡張可能なDNSサーバです.Kubernetesと同様にCoreDNSプロジェクトはCNCFが主宰する.しかし、実際の使用では、いくつかの注意点が必要です.
アプリケーションの反親和性を向上させ、corednsが1台のホストにスケジューリングされることを防止
corednsに必要なリソースは非常に小さいので、ホストに簡単にスケジューリングできます.corednsはシステムコンポーネントであり、corednsをできるだけ分散して導入し、可用性を向上させる必要があります.したがってdeploymentのyamlでは、次の設定を追加します.
affinity:
podAntiAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: app
operator: In
values:
- coredns
topologyKey: kubernetes.io/hostname
ここではk 8 sの属性反親和性を利用した.
合理的なcoredns伸縮を選択
多くのk 8 sデプロイでは、デフォルトでは2つのcorednsインスタンスがデプロイされますが、クラスタが徐々に大きくなると、2つのインスタンスは需要を満たすことができません.したがってcorednsの伸縮は非常に重要である.corednsはhpaでcorednsを弾性伸縮させないでください.頻繁な伸縮は,業務の多くのdns解析に失敗する場合を招く.cluster-proportional-autoscalerコンポーネントを使用する必要があります.私は一般的にnodeノード数に基づいてdnsを伸縮することを選択します.具体的な伸縮戦略は皆さんが選択できます.
corednsを使用してipv 6の解析を無効にする方法
K 8 SクラスタホストがIPV 6カーネルモジュールを閉じていない場合、コンテナがcorednsを要求するときのデフォルトの動作は、IPV 4とIPV 6の解析を同時に開始することである.私たちは通常IPV 4アドレスしか使用しないか、ホスト環境に対してipv 6を一時的にサポートしていないため、実際のビジネスシーンでは、AAAA解析に成功して返されたIPv 6アドレスは、アクセスに失敗します.次のようになります.
2019/09/06 18:12:37 [error] 37#0: *265 connect() to [2404:6800:4003:c03::5f]:443 failed (101: Network is unreachable), client: 100.125.198.131, server: , request: "POST /user/google/signin HTTP/1.1", host: "user.inner.xxx.com"
2019/09/06 18:12:37 [error] 37#0: *265 [lua] http_util.lua:49: http_get(): http request error, url = https://www.googleapis.com/oauth2/v1/userinfo?access_token=ya29.Glt7B5qqIHMVkyJNSmE32jGAo-hkEgIyK2CzMcO0ksrXcCZSMts4VcBoY-uNQmXdEhb8QJQAhVsv-5LxESalKNiD7rJrBgYJgfV-z81No9a_vwW59RgBEvYJMAAr; request headers = null ; request body = ; error = network is unreachable, client: 100.125.198.131, server: , request: "POST /user/google/signin HTTP/1.1", host: "user.inner.xxx.com"
したがって、corednsでDOMAIN->IPV 4アドレスの解析を構成するだけでは、corednsがIPV 6解析要求を受信すると、ローカルで構成が見つからないためfowardがupstream DNSサーバに解析され、コンテナのDNS解析要求が遅くなる.corednsはpluginをtemplateと呼び、構成後、すべてのIPV 6要求に直ちに空の結果の応答を返すことができ、forwardを上流DNSに要求することを避けることができる.ビジネスではipv 6解析が成功せず、ipv 4のA解析に降格します.templateプラグインのデフォルトはcorednsで有効です.プロファイルに次の構成を追加するだけです.
template ANY AAAA {
rcode NXDOMAIN
}
coredns構成stub domainとupstream nameserver
実際のシーンでは、Consulドメインサーバが10.150.0.1にあり、すべてのConsul名に接尾辞.consul.localがあるなど、独自の内部dnsサーバがあります.CoreDNSで構成するには、クラスタ管理者がCoreDNS ConfigMapで次の構成を作成します.
consul.local:53 {
errors
cache 30
forward . 10.150.0.1
}