פתרון בעיות שקשורות לשגיאות 4xx

טייס אוטומטי רגילה

בדף הזה מוסבר איך לפתור שגיאות מסוג 400, 401, 403 ו-404 שאתם עשויים להיתקל בהן כשאתם משתמשים ב-Google Kubernetes Engine ‏ (GKE).

בעיה: שגיאות באימות ובהרשאה

כשמתחברים לאשכולות GKE, יכול להיות שתופיע שגיאת אימות והרשאה עם קוד סטטוס של HTTP‏ 401 (Unauthorized). הבעיה הזו יכולה להתרחש כשמנסים להריץ פקודה kubectl באשכול GKE מסביבה מקומית.

הסיבות האפשריות לבעיה הזו:

תוסף האימות gke-gcloud-auth-plugin לא הותקן או הוגדר בצורה נכונה.
אין לכם הרשאות להתחבר לשרת ה-API של האשכול ולהריץ פקודות kubectl.

כדי לאבחן את הסיבה, צריך לבצע את השלבים בקטעים הבאים:

התחברות לאשכול באמצעות curl
הגדרת הפלאגין ב-kubeconfig

התחברות לאשכול באמצעות `curl`

כדי לאבחן את הסיבה לשגיאת האימות וההרשאה, מתחברים לאשכול באמצעות curl. השימוש ב-curl מדלג על כלי שורת הפקודה kubectl ועל התוסף gke-gcloud-auth-plugin.

מגדירים משתני סביבה:

APISERVER=https://$(gcloud container clusters describe CLUSTER_NAME \
    --location=COMPUTE_LOCATION --format "value(endpoint)")
TOKEN=$(gcloud auth print-access-token)

בודקים שאסימון הגישה תקין:
```
curl https://oauth2.googleapis.com/tokeninfo?access_token=$TOKEN
```
כשיש לכם אסימון גישה תקין, הפקודה הזו שולחת בקשה לשרת OAuth 2.0 של Google, והשרת מגיב עם מידע על האסימון.
מנסים להתחבר לנקודת קצה ל-API המרכזי בשרת ה-API:
```
# Get cluster CA certificate
gcloud container clusters describe CLUSTER_NAME \
    --location=COMPUTE_LOCATION \
    --format "value(masterAuth.clusterCaCertificate)" | \
    base64 -d > /tmp/ca.crt

# Make API call with authentication and CA certificate
curl -s -X GET "${APISERVER}/api/v1/namespaces" \
    --header "Authorization: Bearer $TOKEN" \
    --cacert /tmp/ca.crt
```
אם הפקודה curl מצליחה, תוצג רשימה של מרחבי שמות. כדי לבדוק אם הפלאגין הוא הגורם לבעיה, פועלים לפי השלבים שבקטע הגדרת הפלאגין ב-kubeconfig.

אם הפקודה curl נכשלת והפלט שלה דומה לזה שמופיע בהמשך, סימן שאין לכם את ההרשאות הנכונות לגשת לאשכול:
```
{
"kind": "Status",
"apiVersion": "v1",
"metadata": {},
"status": "Failure",
"message": "Unauthorized",
"reason": "Unauthorized",
"code": 401
}
```
כדי לפתור את הבעיה, צריך להתייעץ עם האדמין כדי לקבל את ההרשאות הנכונות לגישה לאשכול.

הגדרת השימוש בפלאגין ב-kubeconfig

אם אתם מקבלים שגיאות אימות והרשאה כשאתם מתחברים לאשכולות, אבל הצלחתם להתחבר לאשכול באמצעות curl, אתם צריכים לוודא שאתם יכולים לגשת לאשכול בלי להשתמש בתוסף gke-gcloud-auth-plugin.

כדי לפתור את הבעיה, צריך להגדיר את הסביבה המקומית כך שתתעלם מהקובץ הבינארי gke-gcloud-auth-plugin במהלך האימות לאשכול. בלקוחות Kubernetes שפועלת בהם גרסה 1.25 ואילך, gke-gcloud-auth-pluginהקובץ הבינארי נדרש, ולכן צריך להשתמש בגרסה 1.24 או בגרסה קודמת של כלי שורת הפקודה kubectl.

כדי לגשת לאשכול בלי להשתמש בתוסף:

מתקינים את כלי שורת הפקודה kubectl בגרסה 1.24 או בגרסה קודמת באמצעות curl. בדוגמה הבאה מותקן הכלי בגרסה 1.24:
```
curl -LO https://dl.k8s.io/release/v1.24.0/bin/linux/amd64/kubectl
```
פותחים את קובץ הסקריפט לטעינה בזמן ההפעלה של Shell בכלי לעריכת טקסט. לדוגמה, כדי לפתוח את .bashrc במעטפת Bash:
```
vi ~/.bashrc
```
אם אתם משתמשים ב-macOS, צריך להשתמש ב-~/.bash_profile במקום ב-.bashrc בהוראות האלה.
מוסיפים את השורה הבאה לקובץ סקריפט לטעינה בזמן ההפעלה ושומרים אותו:
```
export USE_GKE_GCLOUD_AUTH_PLUGIN=False
```
מריצים את הסקריפט לטעינה בזמן ההפעלה:
```
source ~/.bashrc
```
מקבלים פרטי כניסה לאשכול, שמגדירים את הקובץ .kube/config:
```
gcloud container clusters get-credentials CLUSTER_NAME \
    --location=COMPUTE_LOCATION
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫CLUSTER_NAME: שם האשכול.
- ‫COMPUTE_LOCATION: המיקום של Compute Engine.
מריצים את הפקודה kubectl. לדוגמה:
```
kubectl cluster-info
```
אם מופיעה שגיאה 401 או שגיאה דומה של הרשאה אחרי הפעלת הפקודות האלה, צריך לוודא שיש לכם את ההרשאות הנכונות ואז להפעיל מחדש את השלב שהחזיר את השגיאה.

שגיאה 400: צריך ליצור מחדש את מאגר הצמתים

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

ERROR: (gcloud.container.clusters.update) ResponseError: code=400, message=Node pool "test-pool-1" requires recreation.

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

בסביבת העורף, מאגרי הצמתים מסומנים ליצירה מחדש, אבל יכול להיות שיעבור זמן מה עד שהפעולה של היצירה מחדש תתחיל. לכן, הפעולה נכשלת כי GKE עדיין לא יצר מחדש מאגר אחד או יותר של צמתים באשכול.

כדי לפתור את הבעיה, בוחרים אחד מהפתרונות הבאים:

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

כדי להתחיל יצירה מחדש, מריצים את הפקודה הבאה:
```
gcloud container clusters upgrade CLUSTER_NAME \
    --node-pool=POOL_NAME
```
אחרי שהשדרוג יסתיים, נסו לבצע שוב את הפעולה.

שגיאה 401: אין הרשאה

זיהוי אשכולות שבהם לחשבונות השירות של הצמתים חסרות הרשאות קריטיות

כדי לזהות אשכולות שבהם לחשבונות השירות של הצמתים חסרות הרשאות קריטיות, משתמשים בהמלצות GKE מסוג NODE_SA_MISSING_PERMISSIONS סוג משנה של שירות המלצות:

משתמשים במסוף Google Cloud . עוברים לדף Kubernetes clusters ובודקים אם ההמלצה Grant critical permissions מופיעה בעמודה Notifications עבור אשכולות ספציפיים.

משתמשים ב-CLI של gcloud או ב-Recommender API ומציינים את סוג המשנה של שירות ההמלצות NODE_SA_MISSING_PERMISSIONS.

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

gcloud recommender recommendations list \
    --recommender=google.container.DiagnosisRecommender \
    --location LOCATION \
    --project PROJECT_ID \
    --format yaml \
    --filter="recommenderSubtype:NODE_SA_MISSING_PERMISSIONS"

הערה: יכולות לחלוף עד 24 שעות עד שההמלצה תופיע. הוראות מפורטות זמינות במאמר בנושא הצגת תובנות והמלצות.

כדי ליישם את ההמלצה הזו, מקצים את התפקיד roles/container.defaultNodeServiceAccount לחשבון השירות של הצומת.

אפשר להריץ סקריפט שמחפש מאגרי צמתים באשכולות Standard ו-Autopilot של הפרויקט, כדי למצוא חשבונות שירות של צמתים שאין להם את ההרשאות הנדרשות ל-GKE. הסקריפט הזה משתמש ב-CLI של gcloud ובכלי jq. כדי לראות את הסקריפט, מרחיבים את הקטע הבא:

הצגת התסריט

#!/bin/bash

# Set your project ID
project_id=PROJECT_ID
project_number=$(gcloud projects describe "$project_id" --format="value(projectNumber)")
declare -a all_service_accounts
declare -a sa_missing_permissions

# Function to check if a service account has a specific permission
# $1: project_id
# $2: service_account
# $3: permission
service_account_has_permission() {
  local project_id="$1"
  local service_account="$2"
  local permission="$3"

  local roles=$(gcloud projects get-iam-policy "$project_id" \
          --flatten="bindings[].members" \
          --format="table[no-heading](bindings.role)" \
          --filter="bindings.members:\"$service_account\"")

  for role in $roles; do
    if role_has_permission "$role" "$permission"; then
      echo "Yes" # Has permission
      return
    fi
  done

  echo "No" # Does not have permission
}

# Function to check if a role has the specific permission
# $1: role
# $2: permission
role_has_permission() {
  local role="$1"
  local permission="$2"
  gcloud iam roles describe "$role" --format="json" | \
  jq -r ".includedPermissions" | \
  grep -q "$permission"
}

# Function to add $1 into the service account array all_service_accounts
# $1: service account
add_service_account() {
  local service_account="$1"
  all_service_accounts+=( ${service_account} )
}

# Function to add service accounts into the global array all_service_accounts for a Standard GKE cluster
# $1: project_id
# $2: location
# $3: cluster_name
add_service_accounts_for_standard() {
  local project_id="$1"
  local cluster_location="$2"
  local cluster_name="$3"

  while read nodepool; do
    nodepool_name=$(echo "$nodepool" | awk '{print $1}')
    if [[ "$nodepool_name" == "" ]]; then
      # skip the empty line which is from running `gcloud container node-pools list` in GCP console
      continue
    fi
    while read nodepool_details; do
      service_account=$(echo "$nodepool_details" | awk '{print $1}')

      if [[ "$service_account" == "default" ]]; then
        service_account="${project_number}-compute@developer.gserviceaccount.com"
      fi
      if [[ -n "$service_account" ]]; then
        printf "%-60s| %-40s| %-40s| %-10s| %-20s\n" $service_account $project_id  $cluster_name $cluster_location $nodepool_name
        add_service_account "${service_account}"
      else
        echo "cannot find service account for node pool $project_id\t$cluster_name\t$cluster_location\t$nodepool_details"
      fi
    done <<< "$(gcloud container node-pools describe "$nodepool_name" --cluster "$cluster_name" --zone "$cluster_location" --project "$project_id" --format="table[no-heading](config.serviceAccount)")"
  done <<< "$(gcloud container node-pools list --cluster "$cluster_name" --zone "$cluster_location" --project "$project_id" --format="table[no-heading](name)")"

}

# Function to add service accounts into the global array all_service_accounts for an Autopilot GKE cluster
# Autopilot cluster only has one node service account.
# $1: project_id
# $2: location
# $3: cluster_name
add_service_account_for_autopilot(){
  local project_id="$1"
  local cluster_location="$2"
  local cluster_name="$3"

  while read service_account; do
      if [[ "$service_account" == "default" ]]; then
        service_account="${project_number}-compute@developer.gserviceaccount.com"
      fi
      if [[ -n "$service_account" ]]; then
        printf "%-60s| %-40s| %-40s| %-10s| %-20s\n" $service_account $project_id  $cluster_name $cluster_location $nodepool_name
        add_service_account "${service_account}"
      else
        echo "cannot find service account" for cluster  "$project_id\t$cluster_name\t$cluster_location\t"
      fi
  done <<< "$(gcloud container clusters describe "$cluster_name" --location "$cluster_location" --project "$project_id" --format="table[no-heading](autoscaling.autoprovisioningNodePoolDefaults.serviceAccount)")"
}


# Function to check whether the cluster is an Autopilot cluster or not
# $1: project_id
# $2: location
# $3: cluster_name
is_autopilot_cluster() {
  local project_id="$1"
  local cluster_location="$2"
  local cluster_name="$3"
  autopilot=$(gcloud container clusters describe "$cluster_name" --location "$cluster_location" --format="table[no-heading](autopilot.enabled)")
  echo "$autopilot"
}


echo "--- 1. List all service accounts in all GKE node pools"
printf "%-60s| %-40s| %-40s| %-10s| %-20s\n" "service_account" "project_id" "cluster_name" "cluster_location" "nodepool_name"
while read cluster; do
  cluster_name=$(echo "$cluster" | awk '{print $1}')
  cluster_location=$(echo "$cluster" | awk '{print $2}')
  # how to find a cluster is a Standard cluster or an Autopilot cluster
  autopilot=$(is_autopilot_cluster "$project_id" "$cluster_location" "$cluster_name")
  if [[ "$autopilot" == "True" ]]; then
    add_service_account_for_autopilot "$project_id" "$cluster_location"  "$cluster_name"
  else
    add_service_accounts_for_standard "$project_id" "$cluster_location"  "$cluster_name"
  fi
done <<< "$(gcloud container clusters list --project "$project_id" --format="value(name,location)")"

echo "--- 2. Check if service accounts have permissions"
unique_service_accounts=($(echo "${all_service_accounts[@]}" | tr ' ' '\n' | sort -u | tr '\n' ' '))

echo "Service accounts: ${unique_service_accounts[@]}"
printf "%-60s| %-40s| %-40s| %-20s\n" "service_account" "has_logging_permission" "has_monitoring_permission" "has_performance_hpa_metric_write_permission"
for sa in "${unique_service_accounts[@]}"; do
  logging_permission=$(service_account_has_permission "$project_id" "$sa" "logging.logEntries.create")
  time_series_create_permission=$(service_account_has_permission "$project_id" "$sa" "monitoring.timeSeries.create")
  metric_descriptors_create_permission=$(service_account_has_permission "$project_id" "$sa" "monitoring.metricDescriptors.create")
  if [[ "$time_series_create_permission" == "No" || "$metric_descriptors_create_permission" == "No" ]]; then
    monitoring_permission="No"
  else
    monitoring_permission="Yes"
  fi
  performance_hpa_metric_write_permission=$(service_account_has_permission "$project_id" "$sa" "autoscaling.sites.writeMetrics")
  printf "%-60s| %-40s| %-40s| %-20s\n" $sa $logging_permission $monitoring_permission $performance_hpa_metric_write_permission

  if [[ "$logging_permission" == "No" || "$monitoring_permission" == "No" || "$performance_hpa_metric_write_permission" == "No" ]]; then
    sa_missing_permissions+=( ${sa} )
  fi
done

echo "--- 3. List all service accounts that don't have the above permissions"
if [[ "${#sa_missing_permissions[@]}" -gt 0 ]]; then
  printf "Grant roles/container.defaultNodeServiceAccount to the following service accounts: %s\n" "${sa_missing_permissions[@]}"
else
  echo "All service accounts have the above permissions"
fi

זיהוי חשבונות שירות של צמתים שחסרות להם הרשאות קריטיות באשכול

‫GKE משתמש בחשבונות שירות של IAM שמצורפים לצמתים כדי להריץ משימות מערכת כמו רישום ביומן ומעקב. לפחות, חשבונות השירות של הצמתים צריכים לקבל את התפקיד Kubernetes Engine Default Node Service Account ‏(roles/container.defaultNodeServiceAccount) בפרויקט. כברירת מחדל, GKE משתמש בחשבון השירות שמוגדר כברירת מחדל ב-Compute Engine, שנוצר באופן אוטומטי בפרויקט, כחשבון השירות של הצומת.

אם בארגון שלכם נאכף iam.automaticIamGrantsForDefaultServiceAccounts אילוץ מדיניות הארגון, יכול להיות שלחשבון השירות שמוגדר כברירת מחדל ב-Compute Engine בפרויקט שלכם לא יוקצו באופן אוטומטי ההרשאות הנדרשות ל-GKE.

מוצאים את השם של חשבון השירות שבו הצמתים משתמשים:
המסוף
1. עוברים לדף Kubernetes clusters:
  מעבר אל Kubernetes clusters
2. ברשימת האשכולות, לוחצים על שם האשכול שרוצים לבדוק.
3. בהתאם למצב הפעולה של האשכול, מבצעים אחת מהפעולות הבאות:
  
  עבור אשכולות במצב Autopilot, בקטע Security, מוצאים את השדה Service account.
  
  לגבי אשכולות במצב רגיל:
  
  לוחצים על הכרטיסייה Nodes.
  
  בטבלה Node pools (מאגרי צמתים), לוחצים על שם של מאגר צמתים. הדף פרטי מאגר צמתים נפתח.
  
  בקטע Security, מוצאים את השדה חשבון שירות.
אם הערך בשדה חשבון שירות הוא default, הצמתים משתמשים בחשבון השירות שמוגדר כברירת מחדל של Compute Engine. אם הערך בשדה הזה לא default, הצמתים משתמשים בחשבון שירות בהתאמה אישית. במאמר שימוש בחשבונות שירות ב-IAM עם הרשאות מינימליות מוסבר איך מקצים את התפקיד הנדרש לחשבון שירות בהתאמה אישית.
gcloud

עבור אשכולות במצב Autopilot, מריצים את הפקודה הבאה:
gcloud container clusters describe CLUSTER_NAME \ --location=LOCATION \ --flatten=autoscaling.autoprovisioningNodePoolDefaults.serviceAccount
לגבי אשכולות במצב רגיל, מריצים את הפקודה הבאה:
gcloud container clusters describe CLUSTER_NAME \ --location=LOCATION \ --format="table(nodePools.name,nodePools.config.serviceAccount)"
אם הפלט הוא default, הצמתים משתמשים בחשבון השירות שמוגדר כברירת מחדל של Compute Engine. אם הפלט לא default, הצמתים משתמשים בחשבון שירות בהתאמה אישית. במאמר שימוש בחשבונות שירות עם הרשאות מינימליות ב-IAM מוסבר איך מקצים את התפקיד הנדרש לחשבון שירות בהתאמה אישית.
כדי להעניק את התפקיד roles/container.defaultNodeServiceAccount לחשבון השירות שמוגדר כברירת המחדל של Compute Engine, מבצעים את השלבים הבאים:
המסוף
1. נכנסים לדף Welcome:
  מעבר לדף Welcome
2. בשדה מספר הפרויקט, לוחצים על העתקה ללוח.
3. נכנסים לדף IAM:
  כניסה לדף IAM
4. לוחצים על Grant access.
5. בשדה New principals, מציינים את הערך הבא:
  ‫
  PROJECT_NUMBER-compute@developer.gserviceaccount.com
  מחליפים את PROJECT_NUMBER במספר הפרויקט שהעתקתם.
6. בתפריט Select a role (בחירת תפקיד), בוחרים בתפקיד Kubernetes Engine Default Node Service Account (חשבון השירות שמשמש כברירת מחדל לצומת ב-Kubernetes Engine).
7. לוחצים על Save.
gcloud
1. איך מוצאים את Google Cloud מספר הפרויקט:
  gcloud projects describe PROJECT_ID \ --format="value(projectNumber)"
  
  מחליפים את PROJECT_ID במזהה הפרויקט.
  
  הפלט אמור להיראות כך:
  
  12345678901
2. מקצים לחשבון השירות של Compute Engine שמוגדר כברירת מחדל את התפקיד roles/container.defaultNodeServiceAccount:
  gcloud projects add-iam-policy-binding PROJECT_ID \ --member="serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com" \ --role="roles/container.defaultNodeServiceAccount"
  
  מחליפים את PROJECT_NUMBER במספר הפרויקט מהשלב הקודם.

שגיאה 403: אין מספיק הרשאות

השגיאה הבאה מתרחשת כשמנסים להתחבר לאשכול GKE באמצעות gcloud container clusters get-credentials, אבל לחשבון אין הרשאה לגשת לשרת Kubernetes API:

ERROR: (gcloud.container.clusters.get-credentials) ResponseError: code=403, message=Required "container.clusters.get" permission(s) for "projects/<your-project>/locations/<region>/clusters/<your-cluster>".

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

מזהים את החשבון שיש בו בעיית גישה:
```
gcloud auth list
```
נותנים את הגישה הנדרשת לחשבון באמצעות ההוראות במאמר אימות לשרת Kubernetes API.

שגיאה 403: מיצית את תקציב הניסיונות

יכול להיות שתקבלו את השגיאה הבאה כשאתם מנסים ליצור אשכול GKE:

Error: googleapi: Error 403: Retry budget exhausted: Google Compute Engine:
Required permission 'PERMISSION_NAME' for 'RESOURCE_NAME'.

בהודעת השגיאה הזו, המשתנים הבאים רלוונטיים:

‫PERMISSION_NAME: שם ההרשאה, כמו compute.regions.get.
‫RESOURCE_NAME: הנתיב אל Google Cloudהמשאב שניסיתם לגשת אליו, כמו אזור של Compute Engine.

השגיאה הזו מתרחשת אם לחשבון השירות של IAM שמצורף לאשכול אין את ההרשאות המינימליות שנדרשות ליצירת האשכול.

כדי לפתור את הבעיה:

יוצרים או משנים חשבון שירות של IAM כך שיהיו לו כל ההרשאות הנדרשות להפעלת אשכול GKE. הוראות מפורטות זמינות במאמר שימוש בחשבונות שירות ב-IAM עם הרשאות מינימליות.
מציינים את חשבון השירות המעודכן של IAM בפקודה ליצירת האשכול באמצעות הדגל --service-account. הוראות מפורטות מופיעות במאמר בנושא יצירת אשכול Autopilot.

לחלופין, אפשר להשמיט את הדגל --service-account כדי לאפשר ל-GKE להשתמש בחשבון השירות שמשמש כברירת מחדל של Compute Engine בפרויקט, שכולל את ההרשאות הנדרשות כברירת מחדל.

שגיאה 404: המשאב לא נמצא

אם מקבלים שגיאה 404, משאב לא נמצא, כשמפעילים פקודות gcloud container, צריך לפתור את הבעיה על ידי אימות מחדש ב-Google Cloud CLI:

gcloud auth login

שגיאה 400 או 403: חסרות הרשאות עריכה בחשבון

שגיאה שקשורה להרשאות עריכה חסרות בחשבון (שגיאה 400 או 403), מציינת שאחד מהפריטים הבאים נמחק או נערך באופן ידני:

כשמפעילים את Compute Engine API או GKE API, Google Cloud נוצרים חשבונות השירות והסוכנים הבאים:

חשבון השירות של Compute Engine שמוגדר כברירת מחדל בפרויקט. כברירת מחדל,‏ GKE מצרף את חשבון השירות הזה לצמתים למשימות מערכת כמו רישום ביומן ומעקב.
סוכן שירות של Google APIs בפרויקט שמנוהל על ידי Google, עם הרשאות עריכה בפרויקט שלכם.
סוכני שירות של Google Kubernetes Engine בפרויקט שמנוהל על ידי Google, עם סוכן השירות של Kubernetes Engine וסוכן השירות של צומת ברירת המחדל של Kubernetes Engine בפרויקט.

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

הערה: אם אתם לא משתמשים בחשבונות שירות מותאמים אישית של IAM כדי ליצור את אשכולות GKE או מאגרי הצמתים, אתם צריכים לוודא שלחשבון השירות שמוגדר כברירת מחדל ב-Compute Engine בפרויקט שלכם יש את ההרשאות הנדרשות ל-GKE. בארגונים שבהם נאכף אילוץ מדיניות הארגון iam.automaticIamGrantsForDefaultServiceAccounts, חשבון השירות שמשמש כברירת מחדל ב-Compute Engine לא יקבל באופן אוטומטי את ההרשאות הנדרשות ל-GKE. ההגבלה הזו נאכפת כברירת מחדל בארגונים שנוצרו החל מ-3 במאי 2024. פרטים נוספים זמינים במאמר חשבון שירות של צומת GKE שמוגדר כברירת מחדל.

אימות ההרשאות של סוכני השירות של GKE

ל-Google Kubernetes Engine יש את סוכני השירות הבאים:

‫סוכן שירות של Kubernetes Engine, שמשמש לניהול משאבי מחשוב כמו מכונות, דיסקים ומאזני עומסים.
‫Kubernetes Engine Default Node Service Agent, שמשמש לעומסי עבודה של מערכת הצמתים ב-Google Kubernetes Engine כדי לתמוך ביכולות סטנדרטיות כמו רישום ביומן ומעקב.

כדי לבדוק אם לסוכני השירות של Google Kubernetes Engine מוקצה התפקיד סוכן שירות של Kubernetes Engine בפרויקט, מבצעים את השלבים הבאים:

קובעים את השם של סוכני השירות של Google Kubernetes Engine. סוכני השירות מופיעים בפורמט הבא:
- סוכן שירות של Kubernetes Engine:
```
service-PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com
```
- סוכן השירות של הצומת שמוגדר כברירת מחדל ב-Kubernetes Engine:
```
service-PROJECT_NUMBER@gcp-sa-gkenode.iam.gserviceaccount.com
```
מחליפים את PROJECT_NUMBER במספר הפרויקט.
מוודאים שסוכני השירות של Google Kubernetes Engine קיבלו את התפקידים Kubernetes Engine Service Agent ו-Kubernetes Engine Default Node Service Agent בפרויקט:
```
gcloud projects get-iam-policy PROJECT_ID
```
מחליפים את PROJECT_ID במזהה הפרויקט.

כדי לפתור את הבעיה, אם מישהו הסיר את סוכן שירות של Kubernetes Engine או את Kubernetes Engine Default Node Service Agent מסוכני השירות של Google Kubernetes Engine, צריך לפעול לפי ההוראות הבאות כדי לוודא ש-Kubernetes Engine API מופעל ולהעניק את התפקידים הנדרשים לסוכני השירות:

המסוף

נכנסים לדף APIs & Services במסוף Google Cloud .

כניסה אל APIs & Services
בוחרים את הפרויקט הרצוי.
לוחצים על Enable APIs and Services.
מחפשים את Kubernetes ובוחרים את ה-API מתוצאות החיפוש.
לוחצים על Enable. אם הפעלתם בעבר את ה-API, אתם צריכים להשבית אותו קודם ואז להפעיל אותו מחדש. יכול להיות שיעברו כמה דקות עד שה-API והשירותים הקשורים יופעלו.

gcloud

מריצים את הפקודות הבאות ב-CLI של gcloud:

PROJECT_NUMBER=$(gcloud projects describe "PROJECT_ID"
    --format 'get(projectNumber)')
gcloud projects add-iam-policy-binding PROJECT_ID \
    --member "serviceAccount:service-${PROJECT_NUMBER?}@container-engine-robot.iam.gserviceaccount.com" \
    --role roles/container.serviceAgent
gcloud projects add-iam-policy-binding PROJECT_ID \
    --member "serviceAccount:service-${PROJECT_NUMBER?}@gcp-sa-gkenode.iam.gserviceaccount.com" \
    --role roles/container.defaultNodeServiceAgent

המאמרים הבאים

אם לא מצאתם פתרון לבעיה שלכם במסמכים, תוכלו להיעזר בקבלת תמיכה, כולל עצות בנושאים הבאים:
- פתיחת בקשת תמיכה באמצעות פנייה אל Cloud Customer Care.
- קבלת תמיכה מהקהילה על ידי פרסום שאלות ב-StackOverflow ושימוש בתג google-kubernetes-engine כדי לחפש בעיות דומות. אפשר גם להצטרף לערוץ Slack‏ #kubernetes-engine כדי לקבל תמיכה נוספת מהקהילה.
- פתיחת באגים או בקשות להוספת תכונות באמצעות הכלי הציבורי למעקב אחר בעיות.

פתרון בעיות שקשורות לשגיאות 4xx קל לארגן דפים בעזרת אוספים אפשר לשמור ולסווג תוכן על סמך ההעדפות שלך.

בעיה: שגיאות באימות ובהרשאה

התחברות לאשכול באמצעות curl

הגדרת השימוש בפלאגין ב-kubeconfig

שגיאה 400: צריך ליצור מחדש את מאגר הצמתים

שגיאה 401: אין הרשאה

זיהוי אשכולות שבהם לחשבונות השירות של הצמתים חסרות הרשאות קריטיות

זיהוי חשבונות שירות של צמתים שחסרות להם הרשאות קריטיות באשכול

המסוף

gcloud

המסוף

gcloud

שגיאה 403: אין מספיק הרשאות

שגיאה 403: מיצית את תקציב הניסיונות

שגיאה 404: המשאב לא נמצא

שגיאה 400 או 403: חסרות הרשאות עריכה בחשבון

אימות ההרשאות של סוכני השירות של GKE

המסוף

gcloud

המאמרים הבאים

פתרון בעיות שקשורות לשגיאות 4xx

התחברות לאשכול באמצעות `curl`