> ## Documentation Index > Fetch the complete documentation index at: https://clickhouse.com/docs/llms.txt > Use this file to discover all available pages before exploring further. # تجهيز البنية التحتية على AWS باستخدام Terraform > أنشئ عنقود Amazon EKS للوضع المُدار، أو أضف المتطلبات اللازمة إلى شبكة VPC أو عنقود لديك بالفعل، باستخدام Terraform أو OpenTofu معاينة خاصة يعمل الوضع المُدار على عنقود Amazon EKS تملكه أنت. ويتضمن كل إصدار أربع وحدات Terraform جذرية (يُشار إليها أدناه بالجذور)، تُنشئ إما عنقودًا يستوفي متطلباته، وإما تضيف ما يلزمه إلى شبكة VPC أو عنقود لديك بالفعل. تُنشئ الجذور العنقود مع مجموعة عقد النظام والإضافات المُدارة (`vpc-cni` و`kube-proxy` و`coredns` و`aws-ebs-csi-driver`)، إلى جانب أدوار IAM ومفاتيح KMS والوسوم؛ أما `existing-eks` فلا يثبّت إلا الإضافات التي تحددها في `install_addons`. وعند استهداف Helm، يثبّت الأمر `clicklink clctl init` بعد ذلك طبقة المنصة اعتمادًا على المخرجات وحزمة المنصة، وتشمل: Karpenter، ووحدة تحكم AWS Load Balancer، وStorageClass، والمكوّنات ذات الإصدارات المثبّتة (راجع [تهيئة الموصل من مخرجات Terraform](#hand-off)). تتطلب الجذور Terraform 1.10+ أو OpenTofu 1.12+، ومزوّد AWS بالإصدار `~> 6.0`. ويمكن استخدام `tofu` بدلًا من `terraform` في جميع الأوامر الواردة في هذه الصفحة. ![مسار التجهيز باستخدام Terraform لموصل ClickHouse على AWS](https://mintcdn.com/private-7c7dfe99/rJQNifKkddKyB_KW/images/cloud/reference/byoc-connector-terraform-flow.svg?fit=max\&auto=format\&n=rJQNifKkddKyB_KW\&q=85\&s=8b0e95133f61d6b4278f29df9631e44e) ## قبل أن تبدأ ستحتاج إلى ما يلي: * Terraform 1.10+‎ أو OpenTofu 1.12+‎، إلى جانب مزوّد AWS بالإصدار `~> 6.0`. * هوية AWS تملك صلاحية إنشاء الموارد التي يتطلبها الجذر الذي اخترته وتعديلها. * الأداة `curl`، وأداة SHA-256 (`sha256sum` أو `shasum`)، والأداة `cosign`، وذلك لتنزيل أرشيف الإصدار والتحقق منه. * من خطوة [التسجيل](/docs/ar/products/bring-your-own-cloud/connector/onboarding#registration): قيمة `chart_repository_arn` التي يتطلبها كل جذر، إضافةً إلى نقطة نهاية الموصّل، ورمز التسجيل، وحزمة المنصة اللازمة لخطوة التسليم عبر `init` في النهاية. بالنسبة إلى `production` و`existing-vpc`، حدّد مسبقًا كيف سيصل الجهاز الذي يشغّل `clicklink clctl init` و`kubectl` إلى واجهة برمجة تطبيقات EKS الخاصة، كأن يكون ذلك عبر شبكة VPN، أو مضيف bastion، أو شبكة مقترنة، أو إعادة توجيه منفذ عبر SSM. ## 1. اختر المجلد الجذري لـ Terraform المناسب لبيئتك تُنتج الجذور الأربعة جميعها مُخرَجات `clicklink` نفسها، وتبقى عملية التسليم إلى `clicklink clctl init` واحدة أيًّا كان الجذر الذي تطبّقه. | الجذر | البدء من | يُنشئ | | - | - | - | | `minimal` | عناقيد للتطوير وإثبات المفهوم | الموارد نفسها، منطقة توافر واحدة، نقطة نهاية عامة، دون نقاط نهاية أو CMKs | | `production` | حساب ومنطقة خاليان من الموارد | شبكة VPC، عنقود EKS، مجموعة عقد، IAM، KMS | | `existing-vpc` | شبكة VPC لديك بالفعل | عنقود EKS، مجموعة عقد، IAM، KMS، وسوم الشبكات الفرعية | | `existing-eks` | عنقود تشغّله بالفعل | IAM، إضافات مسمّاة، أذونات المفاتيح، وسوم الاكتشاف | ### `minimal` يخفّف `minimal` من متطلبات نقطة النهاية العامة، ونقاط نهاية الواجهات، وسجلات التدفق، ومدة الاحتفاظ بالسجلات، وحجم مجمّع العُقد الخاص بالنظام. وكل متغير مخفَّف موجود في كلا الجذرين بالاسم نفسه، لذا فإن رفع أحدها إلى قيمته في بيئة الإنتاج لا يتطلب سوى تعديل في `terraform.tfvars` ثم إعادة التطبيق. أما منطقة التوفر الوحيدة لعبء العمل وغياب مفاتيح KMS فهما أمران ثابتان: إذ لا يمكن للشبكات الفرعية تغيير منطقتها، ولا يحتوي الجذر على متغير لتشفير Secret في EKS. ولمعالجة ذلك، يجب تطبيق `production` بوصفه عنقودًا جديدًا. ### `production` تمتد شبكة VPC عبر ثلاث مناطق (`availability_zone_count`، من 2 إلى 4) مع شبكة فرعية خاصة `/19` وأخرى عامة `/21` لكل منطقة، وبوابة NAT واحدة لكل منطقة، ونقطة نهاية بوابة S3، ونقاط نهاية من نوع interface لكل من ECR وSTS وEKS وEC2 وCloudWatch Logs وSSM وSQS وKMS وELB، بالإضافة إلى سجلات تدفق VPC. يتضمن عنقود EKS نقطة نهاية خاصة لواجهة برمجة التطبيقات، ومصادقة قائمة على access entries، وجميع أنواع سجلات طبقة التحكم ضمن مجموعة سجلات تابعة للوحدة الجذرية، وكائنات Secret مشفّرة بمفتاح KMS يديره العميل. يحصل العنقود على الإضافات المُدارة `vpc-cni` و`kube-proxy` و`coredns` و`aws-ebs-csi-driver`، ومجموعة عقد نظام واحدة غير موسومة بـ taint وتحمل الوسم `clickhouseGroup=system` (من عقدتين إلى أربع عقد من نوع `m7g.large` افتراضيًا). كما تُنشئ الوحدة الجذرية موارد IAM الخاصة بـ Karpenter مع قائمة انتظار لأحداث المقاطعة ووسوم `karpenter.sh/discovery`، وأدوار IRSA لوحدة تحكم AWS Load Balancer ولمنفّذ الموصل، ومفاتيح KMS لوحدات تخزين EBS ولحاويات التخزين الكائني. ### `existing-vpc` و`existing-eks` لا يُعدِّل أيٌّ من الجذرين ما لم يُنشئه: جداول التوجيه، وبوابات NAT، ونقاط النهاية، وقواعد مجموعات الأمان، ومجموعات العقد، وقوالب الإطلاق، وتهيئة العنقود، ومفاتيح KMS. ويضع كلاهما وسمَي `karpenter.sh/discovery=` و`kubernetes.io/role/internal-elb=1` على الشبكات الفرعية الخاصة؛ كما يضع `existing-vpc` الوسم `kubernetes.io/role/elb=1` على الشبكات الفرعية العامة، ويضع `existing-eks` وسمًا على مجموعة أمان العنقود. في حالة `existing-vpc`، يجب أن تتوفّر شبكة VPC مسبقًا على ما يلي: * تفعيل دعم DNS وأسماء المضيفين في DNS. * من شبكتين إلى أربع شبكات فرعية خاصة موزعة على منطقتَي توافر على الأقل، مع تعطيل `map_public_ip_on_launch`، وتوجيه حركة المرور إلى NAT gateway أو إلى نقاط نهاية من نوع الواجهة (interface endpoints) لخدمات ECR وSTS وEKS وEC2 وCloudWatch Logs وSSM وSQS وKMS وELB. أضف نقطة نهاية من نوع بوابة (gateway endpoint) لخدمة S3، وإلا فستمر حركة مرور التخزين الكائني عبر بوابات NAT. * لا تلزم الشبكات الفرعية العامة إلا إذا أردت موازنات أحمال متاحة للوصول من الإنترنت. اترك `public_subnet_ids` فارغًا إذا لم تتضمن شبكة VPC طبقة عامة. بالنسبة إلى `existing-eks`، يجب أن يتوفر في العنقود مسبقًا ما يلي: * Kubernetes 1.34 أو أحدث. * وضع المصادقة `API` أو `API_AND_CONFIG_MAP`. وفي حال كان العنقود يستخدم `CONFIG_MAP`، تعرض الخطة أمر التبديل. * مزوّد IAM OIDC لجهة الإصدار (issuer) الخاصة بالعنقود. * شبكات فرعية خاصة في منطقتي توافر على الأقل، مع إمكانية الوصول الصادر إلى واجهات برمجة تطبيقات AWS عبر NAT أو نقاط نهاية الواجهة (interface endpoints). تستنتج الوحدة الجذرية هذه الشبكات افتراضيًا من الشبكات الفرعية للعنقود، مستبعدةً أي شبكة يصل جدول توجيهها إلى بوابة إنترنت. عيّن `private_subnet_ids` إذا كانت الشبكات الفرعية للعنقود من نوع `/28` ومخصصة لطبقة التحكم فقط، أو إذا كان ينبغي وضع العقد في شبكات فرعية أخرى. * ألا يكون Karpenter مثبّتًا؛ إذ تُنشئ هذه الوحدة الجذرية موارد IAM الخاصة بـ Karpenter وقائمة انتظار المقاطعات. وتحمل قائمة الانتظار الاسم `-clicklink`، لذا لا يمكن أن تتعارض مع قائمة متبقية من تثبيت سابق لـ Karpenter أُزيل. * عقد نظام خالية من الـ taints وتحمل الوسوم المحددة في `system_node_selector` (والقيمة الافتراضية هي `clickhouseGroup=system`). لا تُنشئ هذه الوحدة الجذرية أي مجموعة عقد. يفشل تنفيذ الأمر `terraform plan` إذا كان أيٌّ من هذه العناصر مفقودًا. إذا كانت إحدى الإضافات المدرجة في `install_addons` مثبّتة بالفعل وتعمل كتثبيت مُدار ذاتيًا، فسيُرجع EKS الخطأ `Conflicts found when trying to apply`. اضبط `addon_resolve_conflicts_on_create = "OVERWRITE"` لتتولى الإضافة المُدارة إدارتها بدلًا منه، أو احذفها من `install_addons`. ## 2. نزّل أرشيف إصدار Terraform وتحقّق من سلامته تُوزَّع الجذور في أرشيف واحد لكل إصدار، ويتبع رقم إصداره إصدار الملف التنفيذي `clicklink`. نزِّل أرشيف الإصدار الحالي مع قيمة التحقق الخاصة به وحزمة cosign: ```bash theme={null} CLICKLINK_VERSION="$(curl -fsSL https://releases.clicklink.clickhouse.com/latest-version.txt)" # Or pin a specific release: CLICKLINK_VERSION='vX.Y.Z' TERRAFORM_TARBALL="clicklink-terraform-${CLICKLINK_VERSION}.tar.gz" for suffix in '' .sha256 .bundle; do curl -fsSLO "https://releases.clicklink.clickhouse.com/${TERRAFORM_TARBALL}${suffix}" done if command -v sha256sum >/dev/null; then sha256sum -c "${TERRAFORM_TARBALL}.sha256" else shasum -a 256 -c "${TERRAFORM_TARBALL}.sha256" fi ``` تحقّق من التوقيع باستخدام cosign قبل استخراج الملفات: ```bash theme={null} cosign verify-blob \ --bundle "${TERRAFORM_TARBALL}.bundle" \ --certificate-identity-regexp '^https://github\.com/ClickHouse/data-plane-clicklink/\.github/workflows/release\.yaml@refs/tags/v[0-9]+\.[0-9]+\.[0-9]+(-.*)?$' \ --certificate-oidc-issuer https://token.actions.githubusercontent.com \ "${TERRAFORM_TARBALL}" ``` ثم فُكَّ ضغطه: ```bash theme={null} tar -xzf "${TERRAFORM_TARBALL}" cd "clicklink-terraform-${CLICKLINK_VERSION}" ``` يُستخرج الأرشيف إلى دليل واحد يضم `aws/production` و`aws/minimal` و`aws/existing-vpc` و`aws/existing-eks` و`aws/modules`. وتشير وحدات الجذر إلى الوحدات عبر المسار `../modules`، لذا احتفظ بالشجرة المستخرجة كاملةً ولا تنسخ أحد الجذور منها بمعزل عنها. قد تعرض ملفات README الخاصة بالجذور في الأرشيف خطوة التسليم عبر `init` دون الخيار `--platform-bundle`؛ غير أن الأمر المدعوم هو الوارد في [تهيئة الموصل من مخرجات Terraform](#hand-off). ## 3. هيّئ الجذر المحدد وطبّقه من الدليل الجذري، انسخ ملف المتغيرات النموذجي واملأ قيمه: ```bash theme={null} cp terraform.tfvars.example terraform.tfvars ``` يتطلب كل جذر تحديد `region` و`cluster_name` و`chart_repository_arn`. يحدد `cluster_name` اسم العنقود، ويُستخدم بادئةً لاسم كل مورد، كما يمثل قيمة الوسم المستخدمة في الاكتشاف. في `production` و`minimal` و`existing-vpc` يتكون من 3 إلى 32 محرفًا من الأحرف الصغيرة والأرقام والشرطات، على أن يبدأ بحرف ولا ينتهي بشرطة. أما في `existing-eks` فيأخذ اسم العنقود الذي تشغّله بالفعل، بحد أقصى 32 محرفًا. ويشير `chart_repository_arn` إلى مستودع ECR الخاص بمخطط عنقود ClickHouse، والذي يزوّدك به فريق حسابك عند [التسجيل](/docs/ar/products/bring-your-own-cloud/connector/onboarding#registration). كما تتطلب الجذور التي تُنشئ عنقودًا تحديد `cluster_admin_principal_arns`، وهي الجهات التي تُمنح صلاحيات مدير العنقود عبر عناصر الوصول في EKS. يجب أن تكون الهوية التي تشغّل الجذر ضمن هذه القائمة، وإلا فلن تتمكن من الوصول إلى العنقود لاحقًا، إذ لا يحصل منشئ العنقود على أي وصول ضمني. وفيما يلي متطلبات كل جذر: * يتطلب `minimal` تحديد `endpoint_public_access_cidrs`، وهي قائمة السماح لعناوين IPv4 الخاصة بنقطة نهاية واجهة برمجة التطبيقات العامة. يجب أن تكون الشبكة التي تشغّل منها `init` و`kubectl` ضمن هذه القائمة. يُرفض النطاق `/0` ما لم يُضبط `allow_public_endpoint_from_anywhere = true`. أما عند ضبط `endpoint_public_access = false` فيمكن ترك القائمة فارغة، وتصبح نقطة النهاية خاصة فقط، كما هو الحال في `production`. * يتطلب `existing-vpc` تحديد `vpc_id` و`private_subnet_ids`. أما `public_subnet_ids` فهو اختياري، ويُستخدم لموازنات التحميل المكشوفة على الإنترنت. * لا يتطلب `existing-eks` أي متغيرات إضافية. يحدد `install_addons` الإضافات المُدارة غير المتوفرة في العنقود، ويوفر `ebs_kms_key_arn` مفتاحًا لوحدات تخزين الخدمة. بعد ذلك، نفّذ التهيئة ثم التخطيط ثم التطبيق: ```bash theme={null} terraform init terraform providers lock -platform=linux_amd64 -platform=darwin_arm64 terraform plan terraform apply ``` لا يحتوي الأرشيف على ملف قفل للمزوّدين، لكن الأمر `terraform providers lock` ينشئه لك لتثبّته في نسختك. تُخزَّن الحالة محليًا افتراضيًا، ويتضمن الملف `versions.tf` كتلة `backend "s3"` مُعلَّقة توضّح شكل الحالة المشتركة. > [!NOTE] > > نقاط نهاية واجهة برمجة التطبيقات في `production` و`existing-vpc` خاصة. لذا شغّل `init` و`kubectl` من داخل شبكة VPC (عبر إعادة توجيه منفذ باستخدام SSM إلى عقدة نظام، أو عبر مضيف bastion، أو شبكة VPN، أو شبكة مقترنة)، أو فعّل الوصول العام بضبط `endpoint_public_access = true` مع تحديد قائمة سماح في `endpoint_public_access_cidrs`. ## 4. هيّئ الموصل باستخدام مخرجات Terraform صدِّر المخرجات، ثم مرِّرها إلى `init` مع حزمة المنصة، على أن يتم ذلك من جهاز يشير سياق kube فيه إلى العنقود الجديد: ```bash theme={null} terraform output -json > outputs.json clicklink clctl init --enroll https://. --target helm --managed \ --from-terraform outputs.json --platform-bundle bundle.yaml ``` لا تدعم الجذور سوى هدف Helm. فعلى جهاز افتراضي (`--target systemd`) يرفض `init` الخيار `--platform-bundle`، ولا يثبّت `clicklink clctl platform approve --bundle` إلا المكونات المثبّتة الإصدار، فيبقى العنقود بلا أي مزوّد للعُقد. لا تستخدم `--target systemd` إلا للموصلات التي تسجّل ClickHouse تشغّله بنفسك؛ فهو غير مدعوم مع هذه الجذور. يثبّت `--platform-bundle` ما لا تتضمنه الجذور: Karpenter مع `EC2NodeClass` ومجموعتَي العُقد `clickhouse-server` و`clickhouse-keeper`، ووحدة تحكم AWS Load Balancer، وفئة التخزين `gp3-encrypted` (مشفّرة بمفتاح EBS إن تضمّنته المخرجات)، ومكونات المنصة التي تثبّت الحزمة إصداراتها: وحدة تحكم اللقطات، وClickHouse operator، وجامعات المراقبة. والحزمة هي بيان المنصة الذي يولّده ClickHouse Cloud لبيئتك؛ يسلّمها إليك فريق حسابك أثناء الإعداد الأولي، ويحدّد قسم `cluster:` فيها إصدارات Karpenter ووحدة تحكم موازن التحميل. تتطلب هذه العلامة `--target helm` و`--managed` و`--from-terraform`. يُترك أي مكوّن موجود مسبقًا على حاله، لذا يمكن إعادة تشغيل الأمر بأمان، ويطبع `init` تقريرًا بما ثبّته وما تخطّاه وسبب ذلك. أما من دون هذه العلامة، فيسجّل `init` الموصل دون أن يثبّت أيًّا من هذه المكونات، ولا يستطيع العنقود تشغيل أي خدمة قبل تثبيتها. وتُحدِّث [تحديثات المنصة](/docs/ar/products/bring-your-own-cloud/connector/platform-updates) اللاحقة وحدةَ تحكم اللقطات والمشغّل والجامعات؛ بينما يبقى Karpenter ووحدة تحكم موازن التحميل وفئة التخزين كما ثبّتها `init`. يقبل `--from-terraform` إما المستند الكامل الذي يطبعه `terraform output -json` أو الكائن المجرّد الناتج عن `terraform output -json clicklink`. يتضمن الإخراج `clicklink` هوية العنقود (`account_id` و`region` و`cluster_name` و`cluster_endpoint` و`cluster_ca`)، ومزوّد OIDC، ومساحة أسماء الموصل، ودور IAM الخاص بالمنفّذ (`executor_role_arn`)، ومفتاح EBS، ودور عُقد Karpenter وطابوره، ودور وحدة تحكم موازن التحميل، و`system_node_selector`. يقرأ `init` هوية العنقود ومساحة أسماء الموصل من الملف، ويعيّن `executor_role_arn` تعليقًا توضيحيًا لـ IRSA على ServiceAccount ‏`pcm-executor` الخاص بالموصل، ويطبّق محدِّد العُقد على حاويات الموصل. ولا تتشارك الخدمات المُدارة هذا الدور: إذ ينشئ `clicklink clctl executor prepare` دورًا مستقلًا لكل خدمة (`CH-S3---00-Role` افتراضيًا)، يُربط بالخدمة عند إنشائها؛ راجع [نموذج الامتيازات](/docs/ar/products/bring-your-own-cloud/connector/reference/privilege-model#identities). يرفض `init` أي علامة مثل `--cluster-name` أو `--target-namespace` تتعارض مع الملف، ويذكر كلتا القيمتين. احذف العلامة أو صحّح المخرجات. كما يرفض أي سياق kube لا يكون خادم API فيه هو `cluster_endpoint`، أو يشير معرّف EKS ARN فيه إلى عنقود آخر. ويحتوي الإخراج على الحقل `schema`، وقيمته حاليًا `1`، ويرفض `clctl` أي ملف بقيمة `schema` لا يدعمها. أما بقية خطوات التسجيل فتتبع المسار القياسي الموضّح في [الإعداد الأولي](/docs/ar/products/bring-your-own-cloud/connector/onboarding#install-and-enroll). ## مفاتيح KMS والأذونات المطلوبة ينشئ كلٌّ من `production` و`existing-vpc` ثلاثة مفاتيح KMS يديرها العميل مع تفعيل التدوير، وذلك لكائنات Secret في EKS ووحدات تخزين EBS وحاويات التخزين الكائني، ما لم تمرّر معرّفات ARN في `kms`. أما `existing-eks` فينشئ مفتاح التخزين ما لم تضبط `storage_kms_key_arn`، ويقبل `ebs_kms_key_arn` لوحدات تخزين الخدمات دون أن ينشئ مفتاحًا لها. ولا ينشئ `minimal` أي مفتاح؛ وفي غياب `storage_kms_key_arn` تظل حاوياته معتمدةً على SSE-S3. ويتضمّن كل مفتاح يُنشأ عبارةً واحدة خاصة بجذر الحساب تفوّض صلاحية الوصول إلى IAM. أما المفتاح الذي توفّره بنفسك، فيحتاج إلى التفويض نفسه، أو إلى الأذونات التالية في سياسة المفتاح الخاصة به: | المفتاح | الكيان المخوَّل | الإجراءات | | - | - | - | | كائنات Secret في EKS | `-cluster` | `kms:Encrypt`، `kms:Decrypt`، `kms:DescribeKey` | | EBS | `-ebs-csi-driver`، `-karpenter-controller` | `kms:Encrypt`، `kms:Decrypt`، `kms:ReEncrypt*`، `kms:GenerateDataKey*`، `kms:DescribeKey`، `kms:CreateGrant` مع الشرط `kms:GrantIsForAWSResource = true` | | التخزين | كل دور `CH-S3---00-Role` ينشئه الأمر `clicklink clctl executor prepare --storage-kms-key-arn` | `kms:Decrypt`، `kms:GenerateDataKey`، `kms:DescribeKey` | | التخزين | `-clicklink-executor`، من أجل سجل المفتاح `_tde/` الموجود بجانب النسخ الاحتياطية للخدمة | `kms:GenerateDataKey`، `kms:Decrypt` | تُرفق الوحدات الجذرية سياسات دور IAM لمفتاحَي كائنات Secret في EKS وEBS في كلتا الحالتين، كما تُرفق سياسة مفتاح التخزين الخاصة بالمنفّذ كلما احتوت الوحدة الجذرية على مفتاح تخزين؛ في حين يتولّى الأمر `executor prepare` إرفاق سياسة دور كل خدمة. أما وحدات التخزين الجذرية لعُقد النظام، فتحتوي على الصور وسجلات kubelet، لا على بيانات الخدمات، وتستخدم مفتاح EBS الافتراضي للحساب. ## إزالة البنية التحتية المُدارة بواسطة Terraform يزيل الأمر `terraform destroy` كل ما أنشأته الوحدة الجذرية. وتدخل مفاتيح KMS المُنشأة فترة حذف مدتها 30 يومًا. أما مجموعات السجلات فتُحذف مع السجلات المحفوظة فيها، لذا صدِّر ما تحتاج إليه أولًا. ولا تُدرج المثيلات التي أطلقها Karpenter ولا وحدات التخزين التي أنشأها ClickHouse Operator ضمن حالة Terraform؛ لذا احذف خدماتك وأزل تثبيت Karpenter أولًا، وإلا فسيفشل حذف شبكة VPC ودور العقدة. تُبقي الوحدة `existing-eks` العنقود كما هو، وتزيل الأدوار وقائمة انتظار المقاطعات وقواعدها وإدخال الوصول والوسوم التي أضافتها. أما الإضافات `vpc-cni` و`kube-proxy` و`coredns` التي ثبّتتها فتُحرَّر من إدارة EKS، وتستمر وحدات pod التابعة لها في العمل. وإذا كانت قد ثبّتت إضافة مشغّل EBS CSI، فإنها تُزال مع الوحدة الجذرية، لأن دور IRSA الخاص بها يُحذف أيضًا. للإبقاء على المشغّل، أعد إنشاء الإضافة باستخدام دورك الخاص قبل تنفيذ الإزالة. تزيل عملية الإزالة جميع الوسوم التي أضافتها هذه الوحدات الجذرية، بما في ذلك الوسم `kubernetes.io/role/internal-elb` حتى لو كان موجودًا قبل الوحدة الجذرية، لأن `aws_ec2_tag` يتولى ملكية الوسم الموجود مسبقًا. للإبقاء على هذه الوسوم، اضبط `manage_subnet_tags = false` (في `existing-vpc`) أو `manage_discovery_tags = false` (في `existing-eks`) وطبّق التغييرات قبل الإزالة، أو نفّذ `terraform state rm` على موارد `aws_ec2_tag`.