התאמה אישית של תכונות ב-Kf

אזהרה: מומלץ להמשיך בזהירות ולבדוק לפני שמשתמשים בהתאמות אישיות בסביבת הייצור.

שיפור שיעור השימור

אתם יכולים לקבוע כמה Kf Builds יישמרו לפני שיתבצע איסוף אשפה.

הערה: בדוגמה הזו, תקופת השמירה מוגדרת ל-1 Build. משנים את הערך לפי הצורך.

kubectl patch \
kfsystem kfsystem \
--type='json' \
-p="[{'op': 'replace', 'path': '/spec/kf/config/buildRetentionCount', 'value': 1}]"

הפעלה או השבתה של Istio Sidecar

אם אתם לא צריכים את ה-sidecar של Istio בשביל ה-pods של Build, אתם יכולים להשבית אותם על ידי הגדרת הערך true. כדי להפעיל את ההגדרה, צריך להגדיר את הערך false.

kubectl patch \
kfsystem kfsystem \
--type='json' \
-p="[{'op': 'replace', 'path': '/spec/kf/config/buildDisableIstioSidecar', 'value': true}]"

הגבלות על משאבים של Pod

אפשר להגדיל את גודל המשאב של ה-Pod מברירת המחדל כדי להתאים אותו לבנייה של קבצים גדולים מאוד. יחידות המרחק הקבילות הן Mi וGi.

הערה: האפשרות הזו רלוונטית רק למשימות מובנות (שזה המצב הרגיל בגרסת kf push). בגרסאות build של V2 buildpack, ההגדרה הזו תתבצע בשני שלבים, ובגרסאות build של V3 buildpacks או Dockerfiles, בשלב אחד. כלומר, בגרסה 2, גודל ה-Pod הנדרש יהיה כפול מהמגבלה. לדוגמה, אם מגבלת הזיכרון היא 1Gi, הפוד ידרוש 2Gi.

kubectl patch \
kfsystem kfsystem \
--type='json' \
-p="[{'op': 'replace', 'path': '/spec/kf/config/buildPodResources', 'value': {'limits': {'memory': '234Mi'}}}]"

מידע נוסף על ניהול משאבי קונטיינרים זמין במסמכים בנושא משאבי קונטיינרים ב-Kubernetes.

אישורים בחתימה עצמית עבור ברוקרים של שירותים

אם רוצים להשתמש באישורים בחתימה עצמית ל-TLS ‏ (https במקום http) לכתובת ה-URL של מתווך השירותים, נדרש אישור CA לבקר Kf. כדי להגדיר את Kf לתרחיש הזה, צריך ליצור סוד Kubernetes שלא ניתן לשינוי במרחב השמות kf ולעדכן את האובייקט kfsystem.spec.kf.config.secrets.controllerCACerts.name כך שיצביע אליו.

1. יוצרים סוד לאחסון האישור בחתימה עצמית.

   הערה: אם רוצים, אפשר לשנות את שם הסוד, או להשאיר את שם ברירת המחדל cacerts. מחליפים את /path/to/cert/certs.pem בנתיב לאישור בחתימה עצמית.

   kubectl create secret generic cacerts -nkf --from-file /path/to/cert/certs.pem
   

2. הופכים את הסוד לבלתי ניתן לשינוי.

   kubectl patch -nkf secret cacerts \
     --type='json' \
     -p="[{'op':'add','path':'/immutable','value':true}]"
   

3. מעדכנים את kfsystem כך שיצביע על הסוד.

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

   kubectl patch \
     kfsystem kfsystem \
     --type='json' \
     -p="[{'op':'add','path':'/spec/kf/config/secrets','value':{'controllerCACerts':{'name':'cacerts'}}}]"
   

הגדרת ערכי מינימום ויחסי מעבד

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

הערכים מוגדרים ביחידות CPU. היחידות מבוטאות בדרך כלל במילי-מעבדים (m) או באלפיות של מעבד.

המאפיין spec.kf.config.appCPUMin מציין כמות מינימלית של מעבד לכל אפליקציה, גם אם המפתח ציין כמות קטנה יותר.

kubectl patch \
    kfsystem kfsystem \
    --type='json' \
    -p="[{'op':'add','path':'/spec/kf/config/appCPUMin','value':'200m'}]"

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

המאפיין spec.kf.config.appCPUPerGBOfRAM מציין את כמות ברירת המחדל של CPU שמוקצית לכל אפליקציה לכל GB או RAM שנדרש.

אתם יכולים לבחור גישות שונות בהתאם לתוצאה הרצויה:

• בוחרים את היחס בין CPU ל-RAM לצמתים של האשכול אם רוצים למקסם את הניצול.
• מומלץ לבחור יחס של 1 CPU ל-4GB של RAM, שבדרך כלל מתאים לאפליקציות אינטרנט שמוגבלות על ידי קלט/פלט או זיכרון.

kubectl patch \
    kfsystem kfsystem \
    --type='json' \
    -p="[{'op':'add','path':'/spec/kf/config/appCPUPerGBOfRAM','value':'250m'}]"