‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

התעלמות משדות לא מוגדרים

בדף הזה מוסבר איך שדות spec מאוכלסים כברירת מחדל במשאבים של Config Connector, ואיך להעביר משאבים קיימים מההתנהגות הקודמת של Merge להתנהגות המומלצת של Absent. יכול להיות שהדף הזה לא רלוונטי אם אתם משתמשים ב-CustomResourceDefinition‏ (CRD) שנוסף בגרסה 1.114.0 ואילך, כי ה-CRD האלה תומכים רק בהתנהגות של Absent. בקטע סוגים עם תמיכה ב-Merge שבדף הזה מפורטים ה-CRD שתומכים בהתנהגות של Merge.

`spec` התנהגויות של אכלוס שדות

כש-Config Connector יוצר משאב, לשדות שלא צוינו בשדה spec של המשאב ב-Kubernetes יכולות להיות שתי התנהגויות אכלוס שונות: Absent ו-Merge.

היעדרות

ההתנהגות של Absent היא ההתנהגות המומלצת. כשמשאב משתמש בהתנהגות Absent, הכלי Config Connector לא מאכלס שדות לא מוגדרים בשדה spec של המשאב ב-Kubernetes.

החל מגרסה 1.123.1 של Config Connector, ההתנהגות של Absent היא התנהגות ברירת המחדל לאכלוס של כל המשאבים שנוצרו לאחרונה, אלא אם מגדירים את הערך של השדה spec.stateIntoSpec ל-Merge במשאב המותאם אישית ConfigConnector או ConfigConnectorContext. למשאבים שמשתמשים בהערה cnrm.cloud.google.com/state-into-spec, ‏ Config Connector מגדיר את הערך של ההערה ל-absent באותיות קטנות כברירת מחדל (השדה spec.stateIntoSpec משתמש ב-Absent או ב-Merge באותיות רישיות). משאבים שעברו תהליך התאמה (reconciliation) על ידי בקרי ישירים משתמשים בהתנהגות Absent בלי להוסיף את ההערה.

ב-CRD שנוספו בגרסה 1.114.0 ואילך, ההתנהגות של Absent היא ההתנהגות היחידה שנתמכת לאכלוס.

מזג

ההתנהגות של Merge לא נתמכת ב-CRD שנוספו בגרסה 1.114.0 ואילך. כשמשאב משתמש בהתנהגות Merge, השדות של spec מקבלים ערכים מ-API של Google Cloud אחרי התאמה מוצלחת, אלא אם השדות האלה לא ניתנים לקריאה. פרטים נוספים מופיעים במאמר בנושא ניהול שדות חיצוני.

ב-CRD שנוספו בגרסה 1.113.0 ובגרסאות קודמות, Config Connector תומך גם בהתנהגות של Absent וגם בהתנהגות של Merge. כאןMerge מופיעה רשימה מלאה של המשאבים הנתמכים. בגרסאות של Config Connector שקודמות ל-1.123.1, התנהגות ברירת המחדל לאכלוס של ה-CRD האלה הייתה Merge, ו-Config Connector הגדיר את הערך של ההערה cnrm.cloud.google.com/state-into-spec ל-merge כברירת מחדל.

ההערה cnrm.cloud.google.com/state-into-spec לא ניתנת לשינוי אחרי שיוצרים משאב, ולכן משאבים שנוצרו לפני גרסה 1.123.1 שומרים על ההערה cnrm.cloud.google.com/state-into-spec: merge גם אחרי שמשדרגים את Config Connector לגרסה 1.123.1 ואילך. כדי להגדיר משאבים חדשים כך שישתמשו בהתנהגות של Absent, ראו דילוג על מילוי שדות לא מוגדרים במפרט. כדי להעביר משאבים קיימים, ראו העברת משאבים מ-Merge אל Absent.

כשמשאב משתמש בהתנהגות Merge, שדות שלא צוינו במניפסט המקורי של YAML מאוכלסים בשדה המשאב המותאם אישית spec בשרת Kubernetes API. המשמעות היא שכאשר מריצים את הפקודה kubectl get RESOURCE_KIND RESOURCE_NAME -o yaml, השדה spec בפלט יכול לכלול שדות משנה שלא נמצאים בקובץ ה-YAML שהוחל.

לדוגמה, נניח שסכימת ה-CRD מאפשרת לציין שני שדות בשם field1 ו-field2 בשדה spec, אבל קובץ ה-YAML שהחלתם מציין רק את השדה field1:

spec:
  field1: "value-1"

אם מניפסט ה-YAML מיושם בהצלחה והמשאב הוא UpToDate, השדה field2 מופיע במשאב בהתאמה אישית:

spec:
  field1: "value-1"
  field2: "value-2"

‫Config Connector לא מאכלס שדות של הפניות למשאבים שלא צוינו, כמו projectRef,‏ folderRef,‏ organizationRef או billingAccountRef, מ-Google Cloud ל-spec. לדוגמה, למרות שהסוג Project תומך ב-Merge, כל השדות האופציונליים של spec (billingAccountRef,‏ folderRef ו-organizationRef) הם שדות של הפניות למשאבים. לכן, Merge לא מאכלס שדות לא מוגדרים במשאב Project.

בגלל המורכבות של האינטראקציות בין Config Connector לבין ממשקי ה-API שלGoogle Cloud , צריך להשתמש בהתנהגות של Absent כדי ש-Config Connector ידלג על אכלוס השדה spec של המשאב ב-Kubernetes בשדות לא מוגדרים.

דילוג על אכלוס שדות לא מוגדרים במפרט

אפשר להגדיר את Config Connector כך שידלג על אכלוס שדות לא מוגדרים בשדה spec של CRD שנוספו ב-Config Connector בגרסה 1.113.0 ובגרסאות קודמות, באחת מהדרכים הבאות:

מגדירים את הערך של השדה stateIntoSpec ברמת האשכול או ברמת מרחב השמות ל-Absent.
במשאב, מגדירים את הערך של ההערה cnrm.cloud.google.com/state-into-spec ל-absent.

מגדירים את הביטול של `stateIntoSpec` ברמת האשכול או ברמת מרחב השמות

כשמתקינים את Config Connector או מעדכנים את ההתקנה שלו, אפשר להגדיר את הערך של השדה stateIntoSpec ברמת האשכול או ברמת מרחב השמות ל-Absent במשאב המותאם אישית ConfigConnector או ConfigConnectorContext:

spec:
  stateIntoSpec: Absent

ההגדרה הזו הופכת את ההתנהגות של Absent להתנהגות ברירת המחדל של אכלוס השדות של spec בכל המשאבים החדשים שנוצרים באשכול או במרחב השמות, כשלא מציינים את ההערה cnrm.cloud.google.com/state-into-spec במניפסטים של YAML במשאב. Config Connector מדלג על אכלוס שדות לא מוגדרים בשדה spec של המשאב ב-Kubernetes בשביל המשאבים האלה.

בשדה stateIntoSpec במשאבים המותאמים אישית ConfigConnector ו-ConfigConnectorContext לא מוגדר ערך ברירת מחדל. ‫Config Connector קובע את אופן האכלוס של השדות spec על סמך הערך של ההערה cnrm.cloud.google.com/state-into-spec, והוא פועל לפי סדר העדיפות הבא כדי לקבוע את הערך של ההערה כשיוצרים משאב:

משתמשים בערך של ההערה cnrm.cloud.google.com/state-into-spec ישירות אם היא צוינה והיא תקינה.
אם ההערה לא צוינה, משתמשים בערך התואם של השדה stateIntoSpec במשאב המותאם אישית ConfigConnectorContext.
אם המשאב המותאם אישית ConfigConnectorContext לא קיים או שהשדה stateIntoSpec לא צוין, משתמשים בערך התואם של השדה stateIntoSpec במשאב המותאם אישית ConfigConnector.
אם המשאב המותאם אישית של ConfigConnector לא קיים או שהשדה stateIntoSpec לא צוין, גרסה 1.123.1 של Config Connector והגרסאות שאחריה מוגדרות כברירת מחדל לערך absent. בגרסאות מוקדמות יותר מ-1.123.1, נעשה שימוש בהתנהגות ברירת המחדל של ה-CRD, כפי שמתואר במאמר התנהגויות של מילוי שדות spec.

הגדרות CRD שנוספו בגרסה 1.114.0 ואילך תומכות רק בהתנהגות האכלוס של Absent, בלי קשר לשדה stateIntoSpec במשאב המותאם אישית ConfigConnector או ConfigConnectorContext.

אם כבר יצרתם משאב עם ההתנהגות Merge, עדכון הערך של השדה stateIntoSpec ל-Absent במשאב המותאם אישית ConfigConnector או ConfigConnectorContext לא משנה את ההערה של המשאב הקיים. כדי להעביר משאבים קיימים, קראו את המאמר העברת משאבים מ-Merge אל Absent.

הגדרת ההערה `cnrm.cloud.google.com/state-into-spec` ברמת המשאב

כשיוצרים את קובץ ה-YAML, אפשר להגדיר את הערך של ההערה cnrm.cloud.google.com/state-into-spec כ-absent. ההערה הזו מדלגת על אכלוס שדות לא מוגדרים בשדה spec של המשאב ב-Kubernetes:

metadata:
  annotations:
    cnrm.cloud.google.com/state-into-spec: absent

בגרסה 1.123.1 של Config Connector ואילך, ברירת המחדל של ההערה הזו היא הערך absent אם הוא לא צוין (אלא אם משנים אותו על ידי הגדרת הערך של השדה spec.stateIntoSpec ל-Merge במשאב המותאם אישית ConfigConnector או ConfigConnectorContext). בגרסאות שקדמו ל-1.123.1, ברירת המחדל של ההערה הזו הייתה הערך merge ל-CRD שנוספו בגרסה 1.113.0 ובגרסאות קודמות, כלומר Config Connector אכלס את כל השדות שלא צוינו בשדה spec.

ההערה הזו לא ניתנת לשינוי, כלומר אי אפשר לעדכן את הערך שלה ישירות במשאב קיים של Config Connector. אם כבר יצרתם משאב עם הערך merge ואתם רוצים לשנות את ההתנהגות שלו לערך absent, קראו את המאמר העברת משאבים מ-Merge ל-Absent.

כדי להסביר את ההבדל שנוצר בעקבות ההערה הזו, נניח שלמשאב יש שדה spec עם הסכימה הבאה:

field1: string
field2: string
listField:
- itemField1: string
  itemField2: string
objectField:
  subField1: string
  subField2: string

נניח שציינתם את השדה spec במניפסט YAML כך:

spec:
  field1: "value-1"
  listField:
  - itemField1: "1_value1"
  - itemField1: "2_value1"
  objectField:
    subField1: "sub-value-1"

כשהערך של ההערה cnrm.cloud.google.com/state-into-spec מוגדר כ-merge, השדה spec שמאוכלס במשאב שנוצר ב-Kubernetes נראה כך:

spec:
  field1: "value-1"
  field2: "value-2"
  listField:
  - itemField1: "1_value1"
    itemField2: "1_value2"
  - itemField1: "2_value1"
    itemField2: "2_value2"
  objectField:
    subField1: "sub-value-1"
    subField2: "sub-value-2"

כשמגדירים את האנוטציה cnrm.cloud.google.com/state-into-spec: absent, השדה spec הסופי במשאב ב-Kubernetes שנוצר נשאר:

spec:
  field1: "value-1"
  listField:
  - itemField1: "1_value1"
  - itemField1: "2_value1"
  objectField:
    subField1: "sub-value-1"

העברת משאבים מ-`Merge` אל `Absent`

מכיוון שהאנוטציה cnrm.cloud.google.com/state-into-spec היא בלתי ניתנת לשינוי במשאב ב-Kubernetes קיים, שדרוג של Config Connector לגרסה 1.123.1 ואילך לא משנה אוטומטית משאבים קיימים מהערך merge לערך absent.

העברת המשאבים הקיימים ומרחבי השמות מההתנהגות של Merge להתנהגות של Absent עוזרת למנוע את הבעיות הבאות:

שגיאות התאמה בשדות שעודכנו אוטומטית: Google Cloud מעדכנת אוטומטית שדות מסוימים במשאבים הבסיסיים, כמו גרסאות תחזוקה או הגדרות של התאמה אוטומטית לעומס. יכול להיות שמשאבים עם ההערה state-into-spec: merge לא יצליחו לבצע תיאום או ייכנסו ללולאת עדכון אינסופית בניסיון להחזיר את השדה לערך הישן spec.
התנגשויות עם GitOps וכלים לניהול הגדרות אישיות: כלים כמו סנכרון תצורות ו-Argo CD יכולים להתנגש עם Config Connector כשההתנהגות של Merge מאכלסת שדות משנה לא מוגדרים ברשימות.
שגיאות אימות בסוגי משאבים חדשים יותר: אם הערך של השדה spec.stateIntoSpec מוגדר ל-Merge במשאב בהתאמה אישית של ConfigConnector או ConfigConnectorContext, ניהול משאבים שלא תומכים בהתנהגות של Merge עלול לגרום לשגיאות אימות (invalid value "merge" for "cnrm.cloud.google.com/state-into-spec" annotation).

זיהוי מרחבי השמות והמשאבים המושפעים

לפני המעבר, כדאי לבדוק את ההגדרות ברמת האשכול, ברמת מרחב השמות וברמת המשאב כדי לזהות איפה עדיין נעשה שימוש בהתנהגות של Merge:

בודקים אם יש שינוי של השדה stateIntoSpec במשאב המותאם אישית של ConfigConnector ברמת האשכול:
```
kubectl get configconnector configconnector.core.cnrm.cloud.google.com \
    -o jsonpath='{.spec.stateIntoSpec}{"\n"}'
```
בודקים את כל המשאבים המותאמים אישית של ConfigConnectorContext ברמת מרחב השמות כדי לראות אם יש ביטולים של השדה stateIntoSpec:
```
kubectl get configconnectorcontext -A \
    -o custom-columns=NAMESPACE:.metadata.namespace,STATE_INTO_SPEC:.spec.stateIntoSpec
```
בודקים את הערך של ההערה cnrm.cloud.google.com/state-into-spec במשאב קיים של Config Connector:
```
kubectl get RESOURCE_KIND RESOURCE_NAME -n NAMESPACE \
    -o jsonpath='{.metadata.annotations.cnrm\.cloud\.google\.com/state-into-spec}{"\n"}'
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫RESOURCE_KIND: סוג המשאב של Config Connector, למשל SQLInstance.
- ‫RESOURCE_NAME: שם המשאב.
- ‫NAMESPACE: מרחב השמות של המשאב.

העברת משאב אל `Absent`

כדי לשנות את התנהגות האכלוס של משאב קיים מ-Merge ל-Absent, צריך לנטוש את המשאב ב-Kubernetes ולרכוש מחדש את המשאב הבסיסי ב- Google Cloud עם ההערה cnrm.cloud.google.com/state-into-spec: absent. כדי לנטוש את המשאב ולרכוש אותו מחדש:

אם הערך של השדה spec.stateIntoSpec מוגדר כ-Merge במשאב המותאם אישית של ConfigConnector או ConfigConnectorContext, צריך לעדכן את הערך של השדה ל-Absent:
```
spec:
  stateIntoSpec: Absent
```
מוסיפים את ההערה cnrm.cloud.google.com/deletion-policy: abandon למשאב Config Connector הקיים באשכול. האנוטציה הזו עוזרת לוודא שמחיקת משאב ב-Kubernetes בשלב הבא לא תגרום למחיקת משאב Google Cloud בסיס:
```
kubectl annotate RESOURCE_KIND RESOURCE_NAME -n NAMESPACE \
    cnrm.cloud.google.com/deletion-policy=abandon --overwrite
```

מוחקים את המשאב מאשכול Kubernetes:

kubectl delete RESOURCE_KIND RESOURCE_NAME -n NAMESPACE

במניפסט ה-YAML של המשאב, מגדירים את הערך של ההערה cnrm.cloud.google.com/state-into-spec ל-absent:
```
metadata:
  annotations:
    cnrm.cloud.google.com/state-into-spec: absent
```
בודקים את השדה spec במניפסט ה-YAML כדי לוודא שהוא כולל את כל השדות שרוצים ש-Config Connector ינהל. השמיטו שדות שאתם רוצים ש- Google Cloud או מערכות חיצוניות ינהלו באופן אוטומטי, כמו השדה spec.maintenanceVersion במשאב SQLInstance.
אופציונלי: אם מניפסט ה-YAML המקומי כולל גם את האנוטציה cnrm.cloud.google.com/deletion-policy: abandon ואתם לא רוצים יותר את המדיניות בנושא מחיקת נתונים abandon, צריך להסיר את האנוטציה הזו ממניפסט ה-YAML.
מחילים את מניפסט ה-YAML המעודכן כדי לרכוש מחדש את המשאב:
```
kubectl apply -f MANIFEST_FILE
```
מחליפים את MANIFEST_FILE בנתיב לקובץ ה-YAML של המשאב.

מתי כדאי להשתמש ב`cnrm.cloud.google.com/state-into-spec: absent`

ברוב המקרים, כדאי להשתמש בהערה cnrm.cloud.google.com/state-into-spec: absent כדי לקבל את Absent אופן האכלוס של שדות spec. בקטעים הבאים מתוארים תרחישים נפוצים שבהם כדאי להשתמש בהתנהגות האכלוס של Absent.

הימנעות מהתנגשויות עם שדות שמתעדכנים אוטומטית על ידי Google Cloud

כשמשתמשים באנוטציה cnrm.cloud.google.com/state-into-spec: merge במשאב, Config Connector קורא ערכים מ-API Google Cloud במהלך התאמה ראשונית וכותב אותם בשדה spec של משאב ב-Kubernetes. אם שירות של Google Cloud מעדכן באופן אוטומטי את אחד מהשדות האלה, Config Connector מתייחס לערך הישן שמאוחסן בשדה spec כמצב היעד, ומנסה לבטל את השינוי במשאבGoogle Cloud הבסיסי.

לדוגמה, אם יוצרים משאב SQLInstance עם ההערה cnrm.cloud.google.com/state-into-spec: merge בלי לציין את השדה spec.maintenanceVersion, Config Connector מאכלס את גרסת התחזוקה הראשונית בשדה spec.maintenanceVersion. כש-Cloud SQL מבצע מאוחר יותר עדכון תחזוקה אוטומטי במכונה, גרסת התחזוקה הפעילה ב-Cloud SQL מתקדמת. במהלך התיאום הבא, Config Connector מנסה לתקן את המופע בחזרה לערך spec.maintenanceVersion הישן. מכיוון ש-Cloud SQL דוחה שדרוגים לאחור של גרסאות תחזוקה, התיאום נכשל שוב ושוב עם שגיאה UpdateFailed (The requested maintenance version is not an available maintenance version to upgrade).

כשמגדירים את ההערה cnrm.cloud.google.com/state-into-spec: absent, צריך להשמיט מהמניפסט של YAML שדות שמתעדכנים אוטומטית, כמו spec.maintenanceVersion. ‫Config Connector לא מתעד את השדות האלה בשדה spec, מה שמאפשר Google Cloud לעדכן אותם בלי לגרום להתנגשויות בהתאמה.

ניהול שדות לא מוגדרים ברשימה באופן חיצוני

‫Config Connector מתייחס לכל שדות הרשימה בשדה spec של משאב ב-Kubernetes כשדות אטומיים. כתוצאה מכך, כשהערך של ההערה state-into-spec מוגדר ל-merge, Config Connector מבטל כל שינוי שנעשה בשדה משנה ברשימה מחוץ ל-Config Connector. עם זאת, אפשר להשתמש בהערה cnrm.cloud.google.com/state-into-spec: absent כדי לאפשר ל-Config Connector להשאיר שדות משנה לא מוגדרים ברשימה ללא ניהול. למידע נוסף, קראו את המאמר התנהגות של שדות רשימה במפרט המשאבים.

פתרון בעיות שקשורות להתנגשויות בין כלים לניהול הגדרות לבין Config Connector

אם אתם משתמשים בכלים לניהול הגדרות כמו סנכרון תצורות או Argo CD, יכול להיות שתבחינו בהתנגשויות בין הכלי לניהול הגדרות לבין Config Connector. דוגמה לכך היא השגיאה KNV2005 שמוסברת במדריך לפתרון בעיות. הבעיות האלה מתרחשות מהסיבות הבאות:

כשהערך של ההערה state-into-spec מוגדר ל-merge,‏ Config Connector מאכלס ערכים לא מוגדרים ברשימות בשדה spec, כמו השדה spec.listField[0].itemField2, ומגדיר אותם כברירת מחדל.
גם כלי ניהול ההגדרות וגם Config Connector מתייחסים לשדות של רשימות כאל יחידות בסיסיות, ולכן כלי ניהול ההגדרות מתייחסים לשדה spec.listField[0].itemField2 שנוסף כאל סחף ומסירים אותו.

כדי לפתור את הבעיות האלה, אפשר להגדיר את ההערה cnrm.cloud.google.com/state-into-spec: absent כך ש-Config Connector לא יוסיף את השדה spec.listField[0].itemField2 שלא צוין לשדה spec.

פתרון בעיות סימטריה של GET/PUT

הסימטריה של GET/PUT היא עקרון עיצוב בממשקי API בארכיטקטורת REST. באופן ספציפי, המשמעות היא שכאשר תגובת GET נשלחת כבקשת PUT לאותה כתובת URL, התוצאה הצפויה היא קוד סטטוס HTTP 200 OK ללא שינוי במצב של משאב ה-REST הבסיסי.

כשהערך של האנוטציה state-into-spec מוגדר כ-merge, השדות הלא מוגדרים שאוכלסו על ידי Config Connector בשדה spec של משאב ב-Kubernetes הם תוצאה של בקשת GET. המשמעות של ההתנהגות הזו היא שבהתאמות עתידיות, Config Connector עשוי לשלוח בקשת PUT או PATCH ל-API הבסיסי שלGoogle Cloud עם ערכי השדות הלא מוגדרים האלה שנלמדו מבקשת ה-GET. ההתנהגות הזו בדרך כלל לא גורמת לבעיות, אבל יכול להיות שחלק מממשקי ה-API של Google Cloud ידחו את הבקשה מסוג PUT או PATCH בגלל ערכי השדות הלא מוגדרים האלה. באותה דוגמה, השדה spec.objectField.subField2 המאוכלס עם הערך "sub-value-2" עלול לגרום לשגיאת לקוח מסוג HTTP 400 או לתגובות לא צפויות אחרות, אם הטמעת ה-API מפרה את עקרון הסימטריה של GET/PUT.

כדי להימנע מבעיות מהסוג הזה, אפשר להגדיר את ההערה cnrm.cloud.google.com/state-into-spec: absent ולבדוק אם השגיאות נעלמות במהלך ההתאמה.

מצב נצפה

אם אתם צריכים להגדיר את ההערה cnrm.cloud.google.com/state-into-spec: absent, אבל הפתרון שלכם תלוי בערכים המאוכלסים משדות לא מוגדרים, בדקו אם השדות האלה קיימים בשדה status.observedState בסכימת ה-CRD. אם הם מיוצגים בשדה status.observedState, אפשר להגדיר את ההערה cnrm.cloud.google.com/state-into-spec: absent ועדיין לגשת לערכים של השדות שלא צוינו אחרי התאמה מוצלחת.

השדה status.observedState מכיל את המצב בזמן אמת של השדות הנצפים שנבחרו במשאב, ש-Config Connector צפה בהם בהתאמה המוצלחת האחרונה. ‫Config Connector בוחר שדות נצפים שהם שדות spec מחושבים ויחסי תלות לתרחישים נפוצים לדוגמה. השדות שנצפו מופיעים בסכימות של ה-CRD.

אם אתם לא מוצאים את השדות שאתם רוצים, אתם יכולים לבדוק אם יש בעיה קיימת או לפתוח בעיה חדשה בכלי הציבורי למעקב אחר בעיות.

סוגים עם תמיכה ב-`Merge`

אלה כל סוגי Config Connector שתומכים בהתנהגות של Merge מילוי:

AccessContextManagerAccessLevel
AccessContextManagerAccessPolicy
AccessContextManagerServicePerimeter
AlloyDBBackup
AlloyDBCluster
AlloyDBUser
ApigeeEnvironment
ApigeeOrganization
ArtifactRegistryRepository
BigQueryDataset
BigQueryJob
BigQueryRoutine
BigQueryTable
BigtableAppProfile
BigtableGCPolicy
BigtableInstance
BigtableTable
BillingBudgetsBudget
BinaryAuthorizationAttestor
BinaryAuthorizationPolicy
CertificateManagerCertificate
CertificateManagerCertificateMap
CertificateManagerCertificateMapEntry
CloudBuildTrigger
CloudFunctionsFunction
CloudSchedulerJob
ComputeAddress
ComputeBackendBucket
ComputeBackendService
ComputeDisk
ComputeExternalVPNGateway
ComputeFirewall
ComputeFirewallPolicy
ComputeFirewallPolicyAssociation
ComputeForwardingRule
ComputeHTTPHealthCheck
ComputeHTTPSHealthCheck
ComputeHealthCheck
ComputeImage
ComputeInstance
ComputeInstanceGroup
ComputeInstanceGroupManager
ComputeInstanceTemplate
ComputeInterconnectAttachment
ComputeNetwork
ComputeNetworkEndpointGroup
ComputeNetworkFirewallPolicy
ComputeNetworkPeering
ComputeNodeGroup
ComputeNodeTemplate
ComputePacketMirroring
ComputeProjectMetadata
ComputeRegionNetworkEndpointGroup
ComputeReservation
ComputeResourcePolicy
ComputeRoute
ComputeRouter
ComputeRouterInterface
ComputeRouterNAT
ComputeRouterPeer
ComputeSSLCertificate
ComputeSSLPolicy
ComputeSecurityPolicy
ComputeServiceAttachment
ComputeSharedVPCHostProject
ComputeSharedVPCServiceProject
ComputeSnapshot
ComputeSubnetwork
ComputeTargetGRPCProxy
ComputeTargetHTTPProxy
ComputeTargetHTTPSProxy
ComputeTargetInstance
ComputeTargetPool
ComputeTargetSSLProxy
ComputeTargetTCPProxy
ComputeTargetVPNGateway
ComputeURLMap
ComputeVPNGateway
ComputeVPNTunnel
ConfigControllerInstance
ContainerAnalysisNote
ContainerAttachedCluster
ContainerCluster
ContainerNodePool
DLPDeidentifyTemplate
DLPInspectTemplate
DLPJobTrigger
DLPStoredInfoType
DNSManagedZone
DNSPolicy
DNSRecordSet
DataCatalogPolicyTag
DataCatalogTaxonomy
DataFusionInstance
DataflowFlexTemplateJob
DataflowJob
DataprocAutoscalingPolicy
DataprocCluster
DataprocWorkflowTemplate
EdgeContainerCluster
EdgeContainerNodePool
EdgeContainerVpnConnection
EdgeNetworkNetwork
EdgeNetworkSubnet
EventarcTrigger
FilestoreBackup
FilestoreInstance
FirestoreIndex
תיקייה
GKEHubFeature
GKEHubMembership
IAMAccessBoundaryPolicy
IAMAuditConfig
IAMCustomRole
IAMPartialPolicy
IAMPolicy
IAMPolicyMember
IAMServiceAccount
IAMServiceAccountKey
IAMWorkforcePool
IAMWorkforcePoolProvider
IAMWorkloadIdentityPool
IAMWorkloadIdentityPoolProvider
IAPBrand
IAPIdentityAwareProxyClient
IdentityPlatformConfig
IdentityPlatformOAuthIDPConfig
IdentityPlatformTenant
IdentityPlatformTenantOAuthIDPConfig
KMSCryptoKey
KMSKeyRing
LoggingLogBucket
LoggingLogExclusion
LoggingLogSink
LoggingLogView
MemcacheInstance
MonitoringAlertPolicy
MonitoringGroup
MonitoringMetricDescriptor
MonitoringMonitoredProject
MonitoringNotificationChannel
MonitoringService
MonitoringServiceLevelObjective
MonitoringUptimeCheckConfig
NetworkConnectivityHub
NetworkConnectivitySpoke
NetworkSecurityAuthorizationPolicy
NetworkSecurityClientTLSPolicy
NetworkSecurityServerTLSPolicy
NetworkServicesEndpointPolicy
NetworkServicesGRPCRoute
NetworkServicesGateway
NetworkServicesHTTPRoute
NetworkServicesMesh
NetworkServicesTCPRoute
NetworkServicesTLSRoute
OSConfigGuestPolicy
OSConfigOSPolicyAssignment
PrivateCACAPool
PrivateCACertificate
PrivateCACertificateAuthority
PrivateCACertificateTemplate
פרויקט
PubSubLiteReservation
PubSubSchema
PubSubSubscription
PubSubTopic
RecaptchaEnterpriseKey
RedisInstance
ResourceManagerLien
ResourceManagerPolicy
RunJob
RunService
SQLDatabase
SQLSSLCert
SQLUser
SecretManagerSecret
SecretManagerSecretVersion
שירות
ServiceDirectoryEndpoint
ServiceDirectoryNamespace
ServiceDirectoryService
ServiceIdentity
ServiceNetworkingConnection
SourceRepoRepository
SpannerDatabase
SpannerInstance
StorageBucket
StorageBucketAccessControl
StorageDefaultObjectAccessControl
StorageNotification
StorageTransferJob
TagsTagBinding
TagsTagKey
TagsTagValue
VPCAccessConnector

הסוגים הבאים לא תומכים בהתנהגות האכלוס של Merge החל מהגרסה התואמת:

שם הסוג	גרסה
AlloyDBInstance	1.129.2
CertificateManagerDNSAuthorization	1.124.0
CloudIdentityGroup	1.134.0
CloudIdentityMembership	‫1.134.0
ComputeFirewallPolicyRule	‫1.125.0
GKEHubFeatureMembership	1.128.0
LoggingLogMetric	1.118.1
MonitoringDashboard	1.119.0
SQLInstance	1.129.2