هر آنچه که باید در مورد نظارت بر CoreDNS برای عملکرد DNS بدانید

📚 مقدمه:

اجرای بارهای کاری فشرده DNS گاهی اوقات می تواند منجر به خرابی های متناوب CoreDNS ناشی از throttling DNS شود. این مسائل می تواند تاثیر قابل توجهی بر برنامه های شما داشته باشد.

چنین اختلالاتی می تواند قابلیت اطمینان و عملکرد خدمات شما را مختل کند و وجود یک راه حل نظارتی را الزامی کند.
AWS مجموعه ای از ابزارهای منبع باز – CloudWatch، Fluentd و Grafana را ارائه می دهد که می توانند برای نظارت بر CoreDNS ادغام شوند.

معرفی Kubernetes DNS:

Kubernetes برای کشف سرویس در کلاسترها به DNS متکی است. هنگامی که برنامه های کاربردی در حال اجرا در پادها نیاز به ارتباط با یکدیگر دارند، اغلب به سرویس ها با نام دامنه خود اشاره می کنند نه آدرس IP.

اینجاست که Kubernetes DNS وارد عمل می شود. این تضمین می‌کند که این نام‌های دامنه به آدرس‌های IP صحیح حل می‌شوند و به پادها و سرویس‌ها اجازه می‌دهد با هم ارتباط برقرار کنند.

در Kubernetes، به هر پاد یک آدرس IP موقت اختصاص داده می شود. با این حال، این آدرس‌های IP پویا هستند و می‌توانند در طول زمان تغییر کنند و پیگیری آن‌ها را برای برنامه‌ها چالش برانگیز می‌کند.

Kubernetes با تخصیص FQDN نام های دامنه کاملا واجد شرایط به پادها و سرویس ها، این چالش را برطرف می کند.

CoreDNS، ارائه‌دهنده پیش‌فرض DNS در Kubernetes، مسئول رسیدگی به پرسش‌های DNS در داخل خوشه است. این FQDN ها را به آدرس های IP مربوطه نگاشت می کند و ارتباط بین پادها و سرویس ها را امکان پذیر می کند.

چرا مشکلات DNS رایج هستند:

مشکلات DNS یک منبع رایج ناامیدی در عیب یابی شبکه است. DNS نقش بزرگی در ترجمه نام دامنه های قابل خواندن توسط انسان به آدرس های IP قابل خواندن توسط ماشین بازی می کند.

با این حال، مشکلات DNS ممکن است به دلیل عوامل زیادی مانند پیکربندی نادرست، مشکلات شبکه یا خرابی سرور ایجاد شود. هنگامی که DNS نمی تواند نام دامنه را به درستی حل کند، برنامه ها ممکن است با مشکلات اتصال مواجه شوند یا به خدمات خارجی دسترسی پیدا نکنند.

CoreDNS در Kubernetes:

CoreDNS نقش مهمی در ارائه خدمات DNS در خوشه های Kubernetes ایفا می کند. CoreDNS به‌عنوان ارائه‌دهنده پیش‌فرض DNS از زمان Kubernetes نسخه 1.13، شبکه‌های خوشه‌ای را با امکان دسترسی مشتریان به خدمات با استفاده از نام‌های DNS به جای آدرس‌های IP، ساده می‌کند. درخواست‌های نام دامنه را حل می‌کند و کشف سرویس را در خوشه تسهیل می‌کند.

CoreDNS چگونه کار می کند:

CoreDNS به عنوان یک حل کننده و ارسال کننده برای درخواست های DNS در خوشه های Kubernetes عمل می کند. هنگامی که یک پاد نیاز به ارتباط با سرویس دیگری دارد، یک پرس و جو DNS را به CoreDNS ارسال می کند و نام دامنه سرویس مورد نظر را مشخص می کند. سپس CoreDNS این پرس و جو را با نگاشت نام دامنه به آدرس IP مربوطه با استفاده از سوابق داخلی آن حل می کند.

برای نام‌های دامنه خارجی که CoreDNS برای آنها معتبر نیست، درخواست DNS را برای حل‌وفصل به حل‌کننده‌های عمومی یا سرورهای DNS بالادستی ارسال می‌کند.

برای افزایش عملکرد و کاهش تأخیر، CoreDNS می‌تواند پاسخ‌های DNS را برای نام‌های دامنه‌ای که اغلب به آن‌ها دسترسی دارند، ذخیره کند. این مکانیسم کش پاسخگویی پرس و جوهای DNS را بهبود می بخشد و بار روی سرورهای DNS بالادست را کاهش می دهد.

CoreDNS این قابلیت را از طریق معماری ماژولار و سیستم پلاگین قابل توسعه خود به دست می آورد و به اپراتورها اجازه می دهد تا وضوح DNS را مطابق با نیازهای خاص خود سفارشی و بهینه کنند.

کاهش فشار CoreDNS در آمازون EKS:

در خوشه های آمازون EKS، شناسایی و عیب یابی مشکلات CoreDNS و DNS می تواند چالش برانگیز باشد.

در حالی که بسیاری از کاربران بر نظارت بر گزارش‌ها و معیارهای CoreDNS تمرکز می‌کنند، اغلب از محدودیت سخت 1024 بسته در ثانیه (PPS) که در Elastic Network Interface (ENI) مرحله. درک اینکه چگونه این محدودیت می‌تواند منجر به مشکلات انقباض شود، نیاز به بینش در جریان وضوح DNS معمولی یک pod Kubernetes دارد.

در یک محیط Kubernetes، پادها باید نام دامنه را برای هر دو سرویس داخلی و خارجی حل کنند تا ارتباطات را فعال کنند. این فرآیند حل شامل مسیریابی پرس و جوهای DNS از طریق worker node's ENI، به ویژه هنگام حل نقاط پایانی خارجی. حتی برای نقاط پایانی داخلی، اگر غلاف CoreDNS با غلاف پرس‌وجو هم‌جا قرار نگیرد، بسته‌های DNS همچنان از ENI گره کارگر عبور می‌کنند.

سناریویی را در نظر بگیرید که در آن یک اتفاق ناگهانی وجود دارد موج در پرس‌و‌جوهای DNS، باعث می‌شود PPS به مرز سخت 1024 نزدیک شود. این وضعیت می‌تواند منجر به خفه شدن DNS شود و بر همه میکروسرویس‌های در حال اجرا بر روی گره کارگر آسیب‌دیده تأثیر بگذارد. متأسفانه، عیب‌یابی چنین مسائلی می‌تواند سخت باشد، زیرا تمرکز بیشتر روی پادهای CoreDNS است تا معیارهای ENI.

برای کاهش مشکلات DNS throttling در خوشه‌های EKS، نظارت بر افت بسته‌ها که در سطح ENI رخ می‌دهد به طور مداوم بسیار مهم است. این نظارت امکان تشخیص زودهنگام و جلوگیری از قطعی های احتمالی را فراهم می کند. در این پست وبلاگ، راه‌حلی را معرفی می‌کنیم که از معیارهای عملکرد شبکه برای شناسایی مؤثر مشکلات DNS استفاده می‌کند.

راه حل: 🎉

یک راه آسان برای شناسایی مشکلات throttling DNS در گره های کارگر، گرفتن است linklocal_allowance_exceeded متریک ارائه شده توسط the Elastic Network Adapter (ENA) driver و معیارهای دیگر نیز بدیهی است.

linklocal_allowance_exceeded تعداد بسته‌هایی است که حذف شده‌اند زیرا PPS ترافیک به سرویس‌های پراکسی محلی از حداکثر برای رابط شبکه فراتر رفته است. این بر ترافیک سرویس DNS، سرویس فراداده نمونه و سرویس همگام سازی آمازون تأثیر می گذارد.

به جای ردیابی این رویداد در زمان واقعی، می‌توانیم این معیار را در سرویس مدیریت شده آمازون برای Prometheus نیز پخش کنیم و می‌توانیم آن‌ها را در آمازون مدیریت گرافانا تجسم کنیم.

عملی: معیارهای CoreDNS را در AWS EKS جمع آوری و تجسم کنید:

این CoreDNS افزونه prometheus معیارها را در قالب OpenMetrics، یک استاندارد مبتنی بر متن که از فرمت Prometheus تکامل یافته است، نشان می دهد. در یک خوشه Kubernetes، این افزونه به طور پیش‌فرض فعال است، بنابراین می‌توانید به محض راه‌اندازی خوشه خود، نظارت بر بسیاری از معیارهای کلیدی را شروع کنید.

به طور پیش فرض، prometheus افزونه معیارها را به a می نویسد /metrics نقطه پایانی در پورت 9153 در هر غلاف CoreDNS.

یک سرویس مدیریت شده آمازون برای فضای کاری Prometheus و سرویس مدیریت شده برای Grafana ایجاد کنید:

در این مرحله، ما یک فضای کاری برای سرویس مدیریت آمازون برای Prometheus و سرویس مدیریت شده برای Grafana ایجاد می کنیم:

• پیکربندی در این فایل ها ایجاد می کند:
• فضای کاری AMP
• تعریف مدیر هشدار AMP.

main.tf:

module "prometheus" {
  source = "terraform-aws-modules/managed-service-prometheus/aws"

  workspace_alias = "demo-coredns"

  alert_manager_definition = <<-EOT
  alertmanager_config: |
    route:
      receiver: 'default'
    receivers:
      - name: 'default'
  EOT

  rule_group_namespaces = {}
}

versions.tf:

terraform {
  required_version = ">= 1.3"

  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = ">= 5.32"
    }
  }
}

برای اجرای terraform باید موارد زیر را اجرا کنید:

$ terraform init
$ terraform plan
$ terraform apply

فایل های پیکربندی زیر ایجاد می شود:

• فضای کاری پیش‌فرض Grafana (با استفاده از پیش‌فرض‌های ارائه‌شده توسط ماژول).

main.tf:

provider "aws" {
  region = local.region
}

data "aws_availability_zones" "available" {}

locals {
  region      = "eu-west-1"
  name        = "amg-ex-${replace(basename(path.cwd), "_", "-")}"
  description = "AWS Managed Grafana service for ${local.name}"

  vpc_cidr = "10.0.0.0/16"
  azs      = slice(data.aws_availability_zones.available.names, 0, 3)
}

################################################################################
# Managed Grafana Module
################################################################################

module "managed_grafana" {
  source = "../.."

  # Workspace
  name                      = local.name
  associate_license         = false
  description               = local.description
  account_access_type       = "CURRENT_ACCOUNT"
  authentication_providers  = ["AWS_SSO"]
  permission_type           = "SERVICE_MANAGED"
  data_sources              = ["CLOUDWATCH", "PROMETHEUS", "XRAY"]
  notification_destinations = ["SNS"]
  stack_set_name            = local.name
  grafana_version           = "9.4"

  configuration = jsonencode({
    unifiedAlerting = {
      enabled = true
    },
    plugins = {
      pluginAdminEnabled = false
    }
  })

  # vpc configuration
  vpc_configuration = {
    subnet_ids = module.vpc.private_subnets
  }
  security_group_rules = {
    egress_postgresql = {
      description = "Allow egress to PostgreSQL"
      from_port   = 5432
      to_port     = 5432
      protocol    = "tcp"
      cidr_blocks = module.vpc.private_subnets_cidr_blocks
    }
  }

  # Workspace API keys
  workspace_api_keys = {
    viewer = {
      key_name        = "viewer"
      key_role        = "VIEWER"
      seconds_to_live = 3600
    }
    editor = {
      key_name        = "editor"
      key_role        = "EDITOR"
      seconds_to_live = 3600
    }
    admin = {
      key_name        = "admin"
      key_role        = "ADMIN"
      seconds_to_live = 3600
    }
  }

  # Workspace IAM role
  create_iam_role                = true
  iam_role_name                  = local.name
  use_iam_role_name_prefix       = true
  iam_role_description           = local.description
  iam_role_path                  = "/grafana/"
  iam_role_force_detach_policies = true
  iam_role_max_session_duration  = 7200
  iam_role_tags                  = { role = true }

  tags = local.tags
}

module "managed_grafana_default" {
  source = "../.."

  name              = "${local.name}-default"
  associate_license = false

  tags = local.tags
}

module "managed_grafana_disabled" {
  source = "../.."

  name   = local.name
  create = false
}

################################################################################
# Supporting Resources
################################################################################

module "vpc" {
  source  = "terraform-aws-modules/vpc/aws"
  version = "~> 5.0"

  name = local.name
  cidr = local.vpc_cidr

  azs             = local.azs
  private_subnets = [for k, v in local.azs : cidrsubnet(local.vpc_cidr, 4, k)]
  public_subnets  = [for k, v in local.azs : cidrsubnet(local.vpc_cidr, 8, k + 48)]

  enable_nat_gateway = false 
  single_nat_gateway = true

  tags = local.tags
}

versions.tf:

terraform {
  required_version = ">= 1.0"

  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = ">= 5.0"
    }
  }
}

برای اجرای این کد باید اجرا کنید:

$ terraform init
$ terraform plan
$ terraform apply

استقرار صادرکننده ethtool Prometheus:

Ethtool یک ابزار لینوکس برای پیکربندی و جمع آوری اطلاعات در مورد دستگاه های اترنت در گره های کارگر است. ما از خروجی ethtool برای تشخیص از دست رفتن بسته و تبدیل آن به فرمت Prometheus با ابزار صادرکننده ابزار Prometheus استفاده خواهیم کرد.

این استقرار شامل یک اسکریپت پایتون است که اطلاعات را از ethtool می کشد و آن را در قالب Prometheus منتشر می کند.

kubectl apply -f https://raw.githubusercontent.com/Showmax/prometheus-ethtool-exporter/master/deploy/k8s-daemonset.yaml

استقرار کلکتور ADOT برای خراش دادن معیارهای ethtool:

در این مرحله ما جمع‌آورنده ADOT را مستقر می‌کنیم و جمع‌آورنده ADOT را پیکربندی می‌کنیم تا معیارها را در سرویس مدیریت شده آمازون برای Prometheus وارد کند.

ما از افزونه Amazon EKS برای اپراتور ADOT برای ارسال معیارهای “linklocal_allowance_exceeded” به سرویس مدیریت آمازون برای Prometheus برای نظارت بر CoreDNS استفاده خواهیم کرد.

یک نقش IAM و حساب سرویس Amazon EKS ایجاد کنید:

ما جمع‌آورنده ADOT را برای اجرا تحت هویت یک حساب سرویس Kubernetes “adot-collector” مستقر خواهیم کرد.

IAM roles for service accounts (IRSA) به شما امکان می دهد AmazonPrometheusRemoteWriteAccess نقش با یک حساب سرویس Kubernetes، بنابراین مجوزهای IAM را برای هر پادهایی که از حساب سرویس برای دریافت معیارهای سرویس مدیریت شده آمازون برای Prometheus استفاده می کند، ارائه می دهد.

برای اجرای اسکریپت به ابزارهای kubectl و eksctl CLI نیاز دارید. آنها باید برای دسترسی به خوشه آمازون EKS شما پیکربندی شوند.

eksctl create iamserviceaccount \
--name adot-collector \
--namespace default \
--region eu-west-1\
--cluster coredns-monitoring-demo\
--attach-policy-arn arn:aws:iam::aws:policy/AmazonPrometheusRemoteWriteAccess \
--approve \
--override-existing-serviceaccounts

افزونه ADOT را نصب کنید:

با استفاده از دستور زیر می توانید لیست افزونه های فعال شده برای نسخه های مختلف Amazon EKS را بررسی کنید:

نسخه های ADOT موجود که توسط نسخه خوشه شما پشتیبانی می شوند را تعیین کنید.

aws eks describe-addon-versions --addon-name adot --kubernetes-version 1.28 \
  --query "addons[].addonVersions[].[addonVersion, compatibilities[].defaultVersion]" --output text

دستور زیر را برای نصب افزونه ADOT اجرا کنید، همانطور که در مرحله بالا نشان داده شده است، پرچم –addon-version را بر اساس نسخه خوشه آمازون EKS خود جایگزین کنید.

aws eks create-addon --addon-name adot --addon-version v0.66.0-
eksbuild.1 --cluster-name coredns-monitoring-demo

با استفاده از دستور زیر مطمئن شوید که افزونه ADOT آماده است.

kubectl get po -n opentelemetry-operator-system

رویه زیر از یک نمونه فایل YAML با استقرار به عنوان مقدار حالت استفاده می کند. این حالت پیش‌فرض است و ADOT Collector را مشابه یک برنامه مستقل مستقر می‌کند. این پیکربندی معیارهای OTLP را از برنامه نمونه و سرویس مدیریت آمازون برای معیارهای Prometheus که از غلاف های روی خوشه جدا شده است دریافت می کند.

curl -o collector-config-amp.yaml https://raw.githubusercontent.com/aws-observability/aws-otel-community/master/sample-configs/operator/collector-config-amp.yaml

در collector-config-amp.yaml، مقادیر زیر را با مقادیر خود جایگزین کنید:

*** حالت: استقرار * سرویس حساب: adot-collector * نقطه پایانی: “” * منطقه: “” * نام: adot-collector**

kubectl apply -f collector-config-amp.yaml

پس از استقرار جمع‌آورنده aot، معیارها با موفقیت در آمازون Prometheus ذخیره می‌شوند.

معیارهای ethtool را در آمازون Managed Grafana تجسم کنید:

سرویس مدیریت شده آمازون را برای فضای کاری Prometheus به عنوان یک منبع داده در کنسول مدیریت آمازون Grafana پیکربندی کنید.

بیایید اکنون معیارهای موجود در Grafana مدیریت شده آمازون را بررسی کنیم: روی دکمه کاوش کلیک کنید و ابزار ethtool را جستجو کنید:

بیایید یک داشبورد برای متریک linklocal_allowance_exceeded با استفاده از پرس و جو بسازیم:

rate(node_net_ethtool{device="eth0",type="linklocal_allo
wance_exceeded"} [30s])

می بینیم که هیچ بسته ای حذف نشده است زیرا مقدار آن صفر است. می توانید با پیکربندی هشدارها در مدیر هشدار در سرویس مدیریت آمازون برای Prometheus برای ارسال اعلان ها، این را بیشتر گسترش دهید.

نتیجه:

در این پست، نحوه نظارت و ایجاد هشدار برای مسائل مربوط به throttling CoreDNS را با استفاده از AWS Distro برای OpenTelemetry (ADOT)، سرویس مدیریت آمازون برای Prometheus و Amazon Managed Grafana نشان دادیم. با نظارت بر معیارهای coreDNS، مشتریان می توانند به طور فعال افت بسته را تشخیص دهند و اقدامات پیشگیرانه را انجام دهند.

تا دفعه بعد 🎉

با تشکر از شما برای خواندن !! 🙌🏻😁📃 میبینمت تو وبلاگ بعدی.🤘

🚀 ممنون که تا انتها ادامه دادید. اگر در مورد این وبلاگ سوالی یا بازخوردی دارید با من در ارتباط باشید:

♻️ لینکدین: https://www.linkedin.com/in/rajhi-saif/
♻️توئیتر: https://twitter.com/rajhisaifeddine

پایان ✌🏻

**_🔰 به یادگیری ادامه دهید!! به اشتراک گذاری ادامه دهید!! 🔰

منابع:_**

https://cilium.io/blog/2019/12/18/how-to-debug-dns-issues-in-k8s/

https://sysdig.com/blog/how-to-monitor-coredns/

https://www.datadoghq.com/blog/coredns-metrics/

https://www.datadoghq.com/blog/coredns-monitoring-tools/

https://aws.amazon.com/blogs/mt/monitoring-coredns-for-dns-throttling-issues-using-aws-open-source-monitoring-services/