התעלמות משדות שלא צוינו

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

spec אופן האכלוס של השדות

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

היעדרות

Absent היא ההתנהגות המומלצת. ‫Config Connector לא יאכלס שדות לא מוגדרים במפרט.

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

מזג

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

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

כברירת מחדל, במשאבי ה-CR האלה, שדות שלא צוינו ב-YAML המקורי תמיד מופיעים במפרט ה-CR. כלומר, כשמריצים את הפקודה kubectl get <resource kind> <resource name> -oyaml, הרבה שדות במפרט לא מופיעים ב-YAML שהוחל.

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

spec:
  foo: "foo"

אם קובץ ה-YAML מוחל בהצלחה והמשאב הוא UpToDate, יופיע עוד שדה בשם bar ב-CR:

spec:
  foo: "foo"
  bar: "bar"

בגלל המורכבות של האינטראקציה בין Config Connector לבין ממשקי API שלGoogle Cloud , יכול להיות שתרצו לשנות את התנהגות ברירת המחדל הזו ולדלג על מילוי מפרט משאב Kubernetes בשדות לא מוגדרים.

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

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

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

הגדרת stateIntoSpec override ברמת האשכול או מרחב השמות

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

spec:
  stateIntoSpec: Absent

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

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

  1. אם הערך של ההערה cnrm.cloud.google.com/state-into-spec מצוין ותקין, צריך להשתמש בו ישירות.
  2. אם לא מציינים את ההערה, משתמשים בערך המתאים של השדה stateIntoSpec ב-CR של ConfigConnectorContext.
  3. אם ה-CR‏ ConfigConnectorContext לא קיים או שהשדה stateIntoSpec לא צוין, צריך להשתמש בערך התואם של השדה stateIntoSpec ב-CR‏ ConfigConnector.
  4. אם ה-CR של ConfigConnector לא קיים או שהשדה stateIntoSpec לא צוין, המערכת תשתמש בהתנהגות ברירת המחדל על סמך ה-CRD שמתואר בspecהתנהגויות של אכלוס שדות.

שימו לב: התנהגות האכלוס היחידה של CRD שנוספו בגרסה 1.114.0 ואילך היא Absent, ללא קשר להערה cnrm.cloud.google.com/state-into-spec או לשדות stateIntoSpec ב-ConfigConnector CR או ב-ConfigConnectorContext CR.

אם כבר יצרתם את המשאב, אבל אתם רוצים לשנות את אופן האכלוס של השדות spec ל-Absent, אתם צריכים:

  1. מוודאים שביטול ברירת המחדל ברמת האשכול או ברמת מרחב השמות stateIntoSpec הוא Absent ב-ConfigConnector CR או ב-ConfigConnectorContext CR.

  2. לנטוש את המשאב ולרכוש אותו. חשוב לוודא שהגדרת ה-YAML שמשמשת לרכישה לא כוללת את ההערה cnrm.cloud.google.com/state-into-spec.

ציון הערה cnrm.cloud.google.com/state-into-spec ברמת המשאב

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

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

ערך ברירת המחדל של האנוטציה הזו הוא merge אם לא מציינים ערך אחר, כלומר Config Connector מאכלס את כל השדות שלא צוינו ב-spec. האנוטציה הזו היא בלתי ניתנת לשינוי, כלומר אי אפשר לעדכן את ערך האנוטציה של משאב קיים של Config Connector.

אם כבר יצרתם את המשאב, אבל אתם רוצים לשנות את הערך של ההערה הזו כדי לשנות את אופן האכלוס, אתם צריכים לפעול לפי השלבים הבאים:

  1. עורכים ומוסיפים הערה cnrm.cloud.google.com/deletion-policy: abandon למשאב הקיים של Kubernetes כדי לוודא שהמחיקה בשלב הבא לא תמחק את משאב Google Cloud הבסיסי.

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

  3. מוסיפים את ההערה cnrm.cloud.google.com/state-into-spec: absent לקובץ ה-YAML של המשאב.

  4. (אופציונלי) מסירים את cnrm.cloud.google.com/deletion-policy: abandon מקובץ ה-YAML.

  5. מחילים את קובץ ה-YAML המעודכן.

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

foo1: string
foo2: string
bars:
- bar:
    br1: string
    br2: string
barz:
  bz1: string
  bz2: string

נניח שציינתם את המפרט בקובץ ה-YAML כך:

spec:
  foo1: "foo1"
  bars:
  - br1: "1_br1"
  - br1: "2_br1"
  barz:
    bz1: "bz1"

אז כברירת מחדל, יכול להיות שהמפרט שאוכלס במשאב Kubernetes שנוצר יהיה:

spec:
  foo1: "foo1"
  foo2: "foo2"
  bars:
  - br1: "1_br1"
    br2: "1_br2"
  - br1: "2_br1"
    br2: "2_br2"
  barz:
    bz1: "bz1"
    bz2: "bz2"

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

spec:
  foo1: "foo1"
  bars:
  - br1: "1_br1"
  - br1: "2_br1"
  barz:
    bz1: "bz1"

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

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

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

‫Config Connector מתייחס לכל השדות של רשימות במפרט של משאב Kubernetes כשדות אטומיים. כתוצאה מכך, כברירת מחדל, Config Connector יבטל את השינוי שביצעתם בשדה משנה ברשימה מחוץ ל-Config Connector. עם זאת, אפשר להשתמש בהערה הזו כדי לאפשר ל-Config Connector לבטל את הניהול של שדות משנה ברשימה. מידע נוסף זמין במאמר התנהגות של שדות רשימה במפרט משאבים.

פתרון בעיות שנובעות משימוש בכלי ניהול תצורה וב-Config Connector בו-זמנית

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

  1. ‫Config Connector יאכלס ערכים שלא צוינו ברשימה ויגדיר אותם כברירת מחדל במפרט. spec.bars[0].br2 הוא דוגמה לכך.
  2. גם כלי ניהול ההגדרות וגם Config Connector מתייחסים לשדות רשימה כאל אטומיים, ולכן התוספת spec.bars[0].br2 נחשבת כסטייה על ידי כלי ניהול ההגדרות והיא תוסר כדי לתקן את drift.

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

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

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

השדות הלא מוגדרים שאוכלסו על ידי Config Connector במפרט של משאב Kubernetes הם תוצאה של בקשת GET. המשמעות היא שבעתיד, במהלך התאמות, יכול להיות ש-Config Connector ישלח בקשת PUT או PATCH ל-Google Cloud API הבסיסי, עם ערכי השדות הלא מוגדרים האלה שנלמדו מבקשת ה-GET. בדרך כלל זה לא גורם לבעיות, אבל יכול להיות שחלק מ-API‏ Google Cloud ידחו את בקשת PUT או PATCH בגלל ערכי השדות הלא מוגדרים האלה. באותה דוגמה, אם הערך "bz2" מאוכלס ב-spec.barz.bz2, יכול להיות שיתקבל קוד שגיאת לקוח 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 במהלך ההתאמה האחרונה שבוצעה בהצלחה. השדות שנצפו נבחרים אם הם תלויים בתרחישים נפוצים לשימוש, והם שדות מחושבים spec. אפשר למצוא את השדות שנצפו בסכימות של ה-CRD.

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

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

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

  • AccessContextManagerAccessLevel
  • AccessContextManagerAccessPolicy
  • AccessContextManagerServicePerimeter
  • AlloyDBBackup
  • AlloyDBCluster
  • AlloyDBUser
  • ApigeeEnvironment
  • ApigeeOrganization
  • ArtifactRegistryRepository
  • BigQueryDataset
  • BigQueryJob
  • BigQueryTable
  • BigtableAppProfile
  • BigtableGCPolicy
  • BigtableInstance
  • BigtableTable
  • BillingBudgetsBudget
  • BinaryAuthorizationAttestor
  • BinaryAuthorizationPolicy
  • CertificateManagerCertificate
  • CertificateManagerCertificateMap
  • CertificateManagerCertificateMapEntry
  • CloudBuildTrigger
  • CloudFunctionsFunction
  • CloudIdentityGroup
  • CloudIdentityMembership
  • 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
  • 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
  • VPCAccessConnector

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

שם סוג גרסה
LoggingLogMetric 1.118.1