ABC ya Ewlekariyê li Kubernetes: Nasname, Destûrkirin, Kontrolkirin

Zû an dereng, di xebata her pergalê de, pirsgirêka ewlehiyê derdikeve holê: misogerkirina rastkirinê, veqetandina mafan, vekolîn û karên din. Jixwe ji bo Kubernetes hatî afirandin gelek çareserî, ku dihêle hûn di hawîrdorên pir dijwar de jî bi standardan re tevbigerin... Heman materyal ji aliyên bingehîn ên ewlehiyê yên ku di nav mekanîzmayên çêkirî yên K8 de têne bicîh kirin ve girêdayî ye. Berî her tiştî, ew ê ji bo kesên ku dest bi nasîna Kubernetes-ê dikin re kêrhatî be - wekî xalek destpêkek ji bo xwendina mijarên têkildarî ewlehiyê.

Daxuyanî

Di Kubernetes de du celeb bikarhêner hene:

• Hesabên Xizmetê - Hesabên ku ji hêla Kubernetes API ve têne rêve kirin;
• Bikarhêner li - Bikarhênerên "normal" ên ku ji hêla karûbarên derveyî, serbixwe ve têne rêve kirin.

Cûdahiya sereke di navbera van celeban de ev e ku ji bo Hesabên Karûbarê di Kubernetes API de tiştên taybetî hene (ew jê re tê gotin - ServiceAccounts), yên ku bi navek û komek daneyên destûrnameyê ve girêdayî ne ku di komê de di nav tiştên ji celebê Veşartî de têne hilanîn. Bikarhênerên bi vî rengî (Hesabên Karûbar) di serî de ji bo birêvebirina mafên gihîştina Kubernetes API-ya pêvajoyên ku di koma Kubernetes de dimeşin têne armanc kirin.

Bikarhênerên Asayî di API-ya Kubernetes de têketin tune: Divê ew ji hêla mekanîzmayên derveyî ve werin rêvebirin. Ew ji bo kes an pêvajoyên ku li derveyî komê dijîn têne armanc kirin.

Her daxwazek API bi Hesabek Karûbar, Bikarhênerek ve girêdayî ye, an jî nenas tê hesibandin.

Daneyên erêkirina bikarhêner tê de hene:

• Username - navê bikarhêner (hesas bi doza!);
• UID - Rêzek nasnameya bikarhêner a ku ji hêla makîneyê ve tê xwendin ku "ji navê bikarhêner hevgirtîtir û bêhempatir e";
• Groups - navnîşa komên ku bikarhêner tê de ye;
• Biserde - Zeviyên zêde yên ku ji hêla mekanîzmaya destûrnameyê ve têne bikar anîn.

Kubernetes dikare hejmareke mezin ji mekanîzmayên erêkirinê bikar bîne: Sertîfîkayên X509, Nîşaneyên Hilgir, proxy rastrastkirin, HTTP Bingehîn Auth. Bi karanîna van mekanîzmayan, hûn dikarin hejmareke mezin a nexşeyên destûrnameyê bicîh bikin: ji pelek statîk bi şîfre heya OpenID OAuth2.

Digel vê yekê, gengaz e ku meriv çend nexşeyên destûrnameyê bi hevdemî bikar bîne. Bi xwerû, komik bikar tîne:

• nîşaneyên hesabê karûbarê - ji bo Hesabên Karûbar;
• X509 - ji bo Bikarhêneran.

Pirsa di derbarê rêvebirina Hesabên Servîsê de li derveyî çarçoweya vê gotarê ye, lê ji bo kesên ku dixwazin xwe bi vê pirsgirêkê bi hûrgulî nas bikin, ez pêşniyar dikim ku bi rûpelên belgeyên fermî. Em ê ji nêz ve li ser mijara ku sertîfîkayên X509 çawa dixebitin binihêrin.

Sertîfîkayên ji bo bikarhêneran (X.509)

Rêbaza klasîk a xebatê bi sertîfîkayan re ev e:

• nifşê sereke:

  mkdir -p ~/mynewuser/.certs/
  openssl genrsa -out ~/.certs/mynewuser.key 2048

• afirandina daxwaznameyek sertîfîkayê:

  openssl req -new -key ~/.certs/mynewuser.key -out ~/.certs/mynewuser.csr -subj "/CN=mynewuser/O=company"

• pêkanîna daxwaznameyek sertîfîkayê bi karanîna bişkokên CA-yê yên Kubernetes, wergirtina sertîfîkayek bikarhêner (ji bo bidestxistina sertîfîkayê, divê hûn hesabek bikar bînin ku bigihîje mifteya CA ya Kubernetes, ku bi xwerû tê de ye /etc/kubernetes/pki/ca.key):

  openssl x509 -req -in ~/.certs/mynewuser.csr -CA /etc/kubernetes/pki/ca.crt -CAkey /etc/kubernetes/pki/ca.key -CAcreateserial -out ~/.certs/mynewuser.crt -days 500

• çêkirina pelê veavakirinê:
  • danasîna komê (navnîşan û cîhê pelê sertîfîkaya CA-ê ji bo sazkirina komek taybetî diyar bike):

    kubectl config set-cluster kubernetes --certificate-authority=/etc/kubernetes/pki/ca.crt --server=https://192.168.100.200:6443

  • an çawa neVebijarka pêşniyarkirî - hûn ne hewce ne ku hûn sertîfîkaya root diyar bikin (wê hingê kubectl dê rastbûna api-servera komê kontrol neke):

    kubectl config set-cluster kubernetes  --insecure-skip-tls-verify=true --server=https://192.168.100.200:6443

  • zêdekirina bikarhênerek li pelê veavakirinê:

    kubectl config set-credentials mynewuser --client-certificate=.certs/mynewuser.crt  --client-key=.certs/mynewuser.key

  • pêvekirina çarçoveyê:

    kubectl config set-context mynewuser-context --cluster=kubernetes --namespace=target-namespace --user=mynewuser

  • peywira çarçoweya xwerû:

    kubectl config use-context mynewuser-context

Piştî manîpulasyonên jorîn, di pelê de .kube/config konfigurasyonek bi vî rengî dê were afirandin:

apiVersion: v1
clusters:
- cluster:
    certificate-authority: /etc/kubernetes/pki/ca.crt
    server: https://192.168.100.200:6443
  name: kubernetes
contexts:
- context:
    cluster: kubernetes
    namespace: target-namespace
    user: mynewuser
  name: mynewuser-context
current-context: mynewuser-context
kind: Config
preferences: {}
users:
- name: mynewuser
  user:
    client-certificate: /home/mynewuser/.certs/mynewuser.crt
    client-key: /home/mynewuser/.certs/mynewuser.key

Ji bo ku veguheztina mîhengê di navbera hesab û pêşkêşkeran de hêsantir bike, guheztina nirxên bişkojkên jêrîn bikêr e:

• certificate-authority
• client-certificate
• client-key

Ji bo kirina vê yekê, hûn dikarin pelên ku di wan de hatine destnîşan kirin bi karanîna base64-ê şîfre bikin û wan di mîhengê de tomar bikin, paşgira li ser navê kilîtan zêde bikin. -data, yanî wergirtin certificate-authority-data û mîna.

Sertîfîkayên bi kubeadm

Bi berdanê Kubernetes 1.15 xebata bi sertîfîkayan re bi saya guhertoya alpha ya piştgirîya wê pir hêsantir bûye kargêriya kubeadm. Mînakî, ev e ku çêkirina pelek vesazkirinê bi bişkojkên bikarhêner re dibe ku nuha wusa xuya bike:

kubeadm alpha kubeconfig user --client-name=mynewuser --apiserver-advertise-address 192.168.100.200

NB: Pêwîste navnîşan reklam bikin dikare di veavakirina api-server de, ku bi xwerû tê de ye, were dîtin /etc/kubernetes/manifests/kube-apiserver.yaml.

Vesazkirina encam dê ji stdout re derkeve. Pêdivî ye ku ew tê de were xilas kirin ~/.kube/config hesabê bikarhêner an pelê ku di guhêrbarek jîngehê de hatî destnîşan kirin KUBECONFIG.

Dig Deeper

Ji bo kesên ku dixwazin mijarên bi hûrgulî hatine vegotin fam bikin:

• gotara cuda li ser xebata bi sertîfîkayên di belgeyên fermî yên Kubernetes de;
• gotara baş ji Bitnami, ku tê de mijara sertîfîkayan ji perspektîfek pratîkî ve tê destgirtin.
• belgeya giştî li ser piştrastkirina li Kubernetes.

Destûrkirin

Hesabê rayedar a xwerû maf nîne ku li ser komê bixebite. Ji bo dayîna destûran, Kubernetes mekanîzmayek destûrnameyê bicîh tîne.

Berî guhertoya 1.6, Kubernetes celebek destûrnameyê bikar anî ku jê re tê gotin ABAC (Kontrola gihîştina-bingeha taybetmendiyê). Agahiyên li ser wê dikarin di nav de werin dîtin belgeyên fermî. Ev nêzîkatî niha wekî mîras tê hesibandin, lê hûn hîn jî dikarin wê li kêleka celebên din ên rastkirinê bikar bînin.

Awayê heyî (û maqûltir) yê dabeşkirina mafên gihîştina komê tê gotin RBAC (Kontrolkirina gihîştinê ya bingehîn). Ew ji ber guhertoya stabîl hatiye ragihandin Kubernetes 1.8. RBAC modelek mafan pêk tîne ku tê de her tiştê ku bi eşkere destûr nayê qedexe kirin.
Ji bo çalakkirina RBAC, hûn hewce ne ku hûn api-servera Kubernetes bi parametreyê dest pê bikin --authorization-mode=RBAC. Parametre di manîfestoyê de bi veavakirina api-server, ku ji hêla xwerû ve li ser rêkê ye, têne danîn /etc/kubernetes/manifests/kube-apiserver.yaml, di beşê de command. Lêbelê, RBAC jixwe ji hêla xwerû ve hatî çalak kirin, ji ber vê yekê bi îhtîmalek mezin divê hûn jê netirsin: hûn dikarin vê bi nirxê verast bikin authorization-mode (di ya ku berê hatî behs kirin kube-apiserver.yaml). Bi awayê, di nav wateyên wê de dibe ku celebên destûrnameyê yên din jî hebin (node, webhook, always allow), lê em ê nêrîna wan li derveyî çarçoveya materyalê bihêlin.

Bi awayê, me berê jî weşandiye gotar bi danasînek pir berfireh a prensîb û taybetmendiyên xebata bi RBAC re, ji ber vê yekê ez ê xwe bi navnîşek kurt a bingehîn û mînakan sînordar bikim.

Saziyên API-ê yên jêrîn ji bo kontrolkirina gihîştina Kubernetes bi riya RBAC têne bikar anîn:

• Role и ClusterRole - Rolên ku ji bo danasîna mafên gihîştinê xizmet dikin:
• Role destûrê dide te ku hûn di nav cîhek navan de mafên şirove bikin;
• ClusterRole - di nav komê de, di nav de tiştên taybetî yên komê yên wekî girêk, url-ên ne-çavkaniyê (ango ne girêdayî çavkaniyên Kubernetes - mînakî, /version, /logs, /api*);
• RoleBinding и ClusterRoleBinding - ji bo girêdanê tê bikaranîn Role и ClusterRole ji bikarhênerek, grûpek bikarhêner an Hesabê Xizmetê re.

Saziyên Role û RoleBinding ji hêla navan ve têne sînorkirin, ango. divê di nav heman navan de be. Lêbelê, RoleBinding dikare referansek ClusterRole bike, ku destûrê dide te ku hûn komek destûrên gelemperî biafirînin û bi karanîna wan gihîştina kontrol bikin.

Rol bi karanîna rêzikên qaîdeyên ku tê de mafan vedibêjin:

• Komên API - bibînin belgeyên fermî ji hêla apiGroups û derketinê ve kubectl api-resources;
• çavkaniyên (Çavkaniyên: pod, namespace, deployment wate ya vê çîye.);
• Lêker (lêker: set, update wate ya vê çîye.).
• navên çavkaniyê (resourceNames) - ji bo rewşa ku hûn hewce ne ku bigihîjin çavkaniyek taybetî, û ne hemî çavkaniyên bi vî rengî.

Analîzek berfirehtir a destûrnameyê li Kubernetes dikare li ser rûpelê were dîtin belgeyên fermî. Di şûna wê de (an jî ji bilî vê yekê), ez ê mînakên ku xebata wê ronî dikin bidim.

Nimûneyên saziyên RBAC

Asan Role, ku dihêle hûn navnîşek û statûya podan bistînin û wan di cîhê navan de bişopînin target-namespace:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: target-namespace
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

Nimûne: ClusterRole, ku dihêle hûn navnîşek û statûya podan bistînin û wan li seranserê komê bişopînin:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  # секции "namespace" нет, так как ClusterRole задействует весь кластер
  name: secret-reader
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "watch", "list"]

Nimûne: RoleBinding, ku destûrê dide bikarhêner mynewuser "xwendin" pods di navan de my-namespace:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: target-namespace
subjects:
- kind: User
  name: mynewuser # имя пользователя зависимо от регистра!
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role # здесь должно быть “Role” или “ClusterRole”
  name: pod-reader # имя Role, что находится в том же namespace,
                   # или имя ClusterRole, использование которой
                   # хотим разрешить пользователю
  apiGroup: rbac.authorization.k8s.io

Kontrola bûyerê

Skematîkî, mîmariya Kubernetes dikare wekî jêrîn were temsîl kirin:

Parçeya sereke ya Kubernetes ku ji bo pêvajoyên daxwaznameyê berpirsiyar e api-server. Hemî operasyonên li ser komê di nav wê de derbas dibin. Hûn dikarin li ser van mekanîzmayên navxweyî di gotarê de bêtir bixwînin "Dema ku hûn kubectl run dimeşînin di Kubernetes de çi diqewime?".

Kontrolkirina pergalê di Kubernetes de taybetmendiyek balkêş e, ku ji hêla xwerû ve hatî asteng kirin. Ew dihêle hûn hemî bangên Kubernetes API-ê têkevin. Wekî ku hûn texmîn dikin, hemî çalakiyên têkildarî şopandin û guheztina rewşa komê bi vê API-ê têne kirin. Danasînek baş a kapasîteyên wê dikare (wek gelemperî) tê de were dîtin belgeyên fermî K8s. Paşê, ez ê hewl bidim ku mijarê bi zimanekî hêsan pêşkêşî bikim.

Û vî awayî, ji bo venêrînê çalak bike, pêdivî ye ku em sê pîvanên pêdivî bi konteynerê di api-server de derbas bikin, ku li jêr bi hûrgulî têne vegotin:

• --audit-policy-file=/etc/kubernetes/policies/audit-policy.yaml
• --audit-log-path=/var/log/kube-audit/audit.log
• --audit-log-format=json

Ji bilî van sê pîvanên pêwîst, gelek mîhengên pêvek ên têkildarî lênihêrînê hene: ji zivirandina têketinê heya ravekirinên webhook. Mînak parametreyên zivirîna têketinê:

• --audit-log-maxbackup=10
• --audit-log-maxsize=100
• --audit-log-maxage=7

Lê em ê bi hûrgulî li ser wan nesekinin - hûn dikarin hemî hûrguliyan tê de bibînin belgeyên kube-apiserver.

Wekî ku berê jî behs kir, hemî pîvan di manîfestoyê de bi veavakirina api-server (bi xwerû /etc/kubernetes/manifests/kube-apiserver.yaml), di beşê de command. Ka em vegerin ser 3 parametreyên pêwîst û wan analîz bikin:

1. audit-policy-file - riya pelê YAML ku polîtîkaya kontrolê vedibêje. Em ê paşê vegerin naveroka wê, lê ji bo naha ez ê destnîşan bikim ku pel divê ji hêla pêvajoya api-server ve were xwendin. Ji ber vê yekê, pêdivî ye ku ew di hundurê konteynerê de were danîn, ji bo vê yekê hûn dikarin koda jêrîn li beşên guncan ên mîhengê zêde bikin:

     volumeMounts:
       - mountPath: /etc/kubernetes/policies
         name: policies
         readOnly: true
     volumes:
     - hostPath:
         path: /etc/kubernetes/policies
         type: DirectoryOrCreate
       name: policies

2. audit-log-path - riya pelê têketinê. Pêdivî ye ku rê ji pêvajoya api-server re jî bigihîje, ji ber vê yekê em bi heman rengî lêkirina wê vedibêjin:

     volumeMounts:
       - mountPath: /var/log/kube-audit
         name: logs
         readOnly: false
     volumes:
     - hostPath:
         path: /var/log/kube-audit
         type: DirectoryOrCreate
       name: logs

3. audit-log-format - Forma têketinê ya kontrolê. Vebijêrk e json, lê formata nivîsê ya mîras jî heye (legacy).

Polîtîkaya Kontrolê

Naha di derbarê pelê navborî de ku polîtîkaya têketinê vedibêje. Têgeha yekem a siyaseta kontrolê ye level, asta têketinê. Ew wiha ne:

• None - têketinê neke;
• Metadata - Metadata daxwaza têketinê: bikarhêner, dema daxwazê, çavkaniya armancê (pod, cîhê nav, hwd.), celebê çalakiyê (lêker), hwd.;
• Request - metadata têketin û laşê daxwazê;
• RequestResponse - metadata têketinê, laşê daxwaz û laşê bersivê.

Du astên dawî (Request и RequestResponse) Daxwazên ku xwe negihandine çavkaniyan tomar nekin (gehiştinên ku jê re url-yên ne-çavkaniyê têne gotin).

Her wiha hemû daxwaz derbas dibin çend qonaxan:

• RequestReceived - qonaxa ku daxwaz ji hêla pêvajoyê ve tê wergirtin û hîn jî li ser zincîra pêvajokeran nehatiye şandin;
• ResponseStarted - Sernivîsên bersivê têne şandin, lê berî ku laşê bersivê were şandin. Ji bo pirsên demdirêj hatine çêkirin (mînak, watch);
• ResponseComplete - laşê bersivê hat şandin, dê bêtir agahdarî neyê şandin;
• Panic - Dema ku rewşek nenormal were tespît kirin bûyer têne çêkirin.

Ji bo ku hûn gavên ku hûn dikarin bikar bînin derbas bikin omitStages.

Di pelek polîtîkayê de, em dikarin çend beşan bi astên têketinê yên cihêreng diyar bikin. Yekem qaîdeya lihevhatinê ya ku di danasîna polîtîkayê de tê dîtin dê were sepandin.

Daemonê kubelet bi veavakirina api-server ve guheztinên di manîfestoyê de dişopîne û heke yek were tespît kirin, konteynerê bi api-server re ji nû ve dest pê dike. Lê hûrguliyek girîng heye: guhertinên di pelê polîtîkayê de dê ji hêla wê ve bêne paşguh kirin. Piştî ku hûn di pelê polîtîkayê de guhertinan bikin, hûn ê hewce bikin ku api-server bi destan ji nû ve bidin destpêkirin. Ji ber ku api-server wekî dest pê dike pod statîk, tîm kubectl delete dê nebe sedem ku ew ji nû ve dest pê bike. Divê hûn bi destan bikin docker stop li ser kube-master, ku li wir polîtîkaya kontrolê hate guheztin:

docker stop $(docker ps | grep k8s_kube-apiserver | awk '{print $1}')

Dema ku vedîtinê çalak dike, girîng e ku meriv vê yekê ji bîr bike barkirina li ser kube-apiserver zêde dibe. Bi taybetî, mezaxtina bîranînê ji bo hilanîna naveroka daxwazê ​​zêde dibe. Têketin tenê piştî ku sernavê bersivê tê şandin dest pê dike. Barkirin jî bi veavakirina siyaseta kontrolê ve girêdayî ye.

Nimûneyên polîtîkayên

Ka em bi mînakan li avahiya pelên polîtîkayê binêrin.

Li vir pelek hêsan e policyku her tiştî di astê de tomar bike Metadata:

apiVersion: audit.k8s.io/v1
kind: Policy
rules:
- level: Metadata

Di siyasetê de hûn dikarin navnîşek bikarhêneran diyar bikin (Users и ServiceAccounts) û komên bikarhêneran. Mînakî, bi vî rengî em ê bikarhênerên pergalê paşguh bikin, lê her tiştê din di astê de tomar bikin Request:

apiVersion: audit.k8s.io/v1
kind: Policy
rules:
  - level: None
    userGroups:
      - "system:serviceaccounts"
      - "system:nodes"
    users:
      - "system:anonymous"
      - "system:apiserver"
      - "system:kube-controller-manager"
      - "system:kube-scheduler"
  - level: Request

Di heman demê de gengaz e ku meriv armancan jî diyar bike:

• cîhên navan (namespaces);
• Lêker (lêker: get, update, delete û yên din);
• çavkaniyên (Çavkaniyên, namely: pod, configmaps hwd.) û komên çavkaniyê (apiGroups).

Bawer bike! Çavkanî û komên çavkaniyê (komên API, ango apiGroups), û her weha guhertoyên wan ên ku di komê de hatine saz kirin, dikarin bi karanîna fermanan werin wergirtin:

kubectl api-resources
kubectl api-versions

Siyaseta kontrolê ya jêrîn wekî xwenîşandanek pratîkên çêtirîn tê pêşkêş kirin Belgekirina Alibaba Cloud:

apiVersion: audit.k8s.io/v1beta1
kind: Policy
# Не логировать стадию RequestReceived
omitStages:
  - "RequestReceived"
rules:
  # Не логировать события, считающиеся малозначительными и не опасными:
  - level: None
    users: ["system:kube-proxy"]
    verbs: ["watch"]
    resources:
      - group: "" # это api group с пустым именем, к которому относятся
                  # базовые ресурсы Kubernetes, называемые “core”
        resources: ["endpoints", "services"]
  - level: None
    users: ["system:unsecured"]
    namespaces: ["kube-system"]
    verbs: ["get"]
    resources:
      - group: "" # core
        resources: ["configmaps"]
  - level: None
    users: ["kubelet"]
    verbs: ["get"]
    resources:
      - group: "" # core
        resources: ["nodes"]
  - level: None
    userGroups: ["system:nodes"]
    verbs: ["get"]
    resources:
      - group: "" # core
        resources: ["nodes"]
  - level: None
    users:
      - system:kube-controller-manager
      - system:kube-scheduler
      - system:serviceaccount:kube-system:endpoint-controller
    verbs: ["get", "update"]
    namespaces: ["kube-system"]
    resources:
      - group: "" # core
        resources: ["endpoints"]
  - level: None
    users: ["system:apiserver"]
    verbs: ["get"]
    resources:
      - group: "" # core
        resources: ["namespaces"]
  # Не логировать обращения к read-only URLs:
  - level: None
    nonResourceURLs:
      - /healthz*
      - /version
      - /swagger*
  # Не логировать сообщения, относящиеся к типу ресурсов “события”:
  - level: None
    resources:
      - group: "" # core
        resources: ["events"]
  # Ресурсы типа Secret, ConfigMap и TokenReview могут содержать  секретные данные,
  # поэтому логируем только метаданные связанных с ними запросов
  - level: Metadata
    resources:
      - group: "" # core
        resources: ["secrets", "configmaps"]
      - group: authentication.k8s.io
        resources: ["tokenreviews"]
  # Действия типа get, list и watch могут быть ресурсоёмкими; не логируем их
  - level: Request
    verbs: ["get", "list", "watch"]
    resources:
      - group: "" # core
      - group: "admissionregistration.k8s.io"
      - group: "apps"
      - group: "authentication.k8s.io"
      - group: "authorization.k8s.io"
      - group: "autoscaling"
      - group: "batch"
      - group: "certificates.k8s.io"
      - group: "extensions"
      - group: "networking.k8s.io"
      - group: "policy"
      - group: "rbac.authorization.k8s.io"
      - group: "settings.k8s.io"
      - group: "storage.k8s.io"
  # Уровень логирования по умолчанию для стандартных ресурсов API
  - level: RequestResponse
    resources:
      - group: "" # core
      - group: "admissionregistration.k8s.io"
      - group: "apps"
      - group: "authentication.k8s.io"
      - group: "authorization.k8s.io"
      - group: "autoscaling"
      - group: "batch"
      - group: "certificates.k8s.io"
      - group: "extensions"
      - group: "networking.k8s.io"
      - group: "policy"
      - group: "rbac.authorization.k8s.io"
      - group: "settings.k8s.io"
      - group: "storage.k8s.io"
  # Уровень логирования по умолчанию для всех остальных запросов
  - level: Metadata

Nimûneyek din a baş a siyaseta kontrolê ye profîla ku di GCE de tê bikar anîn.

Ji bo bersivdana bilez a bûyerên kontrolê, gengaz e webhook rave bike. Ev mijar di nav de ye belgeyên fermî, Ez ê li derveyî çarçoveya vê gotarê bihêlim.

Encam

Gotar nihêrînek li ser mekanîzmayên ewlehiyê yên bingehîn ên di komikên Kubernetes de peyda dike, ku dihêle hûn hesabên bikarhêner ên kesane biafirînin, mafên wan veqetînin, û kiryarên wan tomar bikin. Ez hêvî dikim ku ew ji bo kesên ku di teorî û pratîkî de bi pirsgirêkên weha re rû bi rû dimînin re kêrhatî be. Di heman demê de ez pêşniyar dikim ku hûn navnîşa materyalên din ên li ser mijara ewlehiyê li Kubernetes, ku di "PS" de hatî dayîn bixwînin - dibe ku di nav wan de hûn ê hûrguliyên pêwîst li ser pirsgirêkên ku ji we re têkildar in bibînin.

PS

Li ser bloga me jî bixwînin:

• «33+ Amûrên ewlehiyê yên Kubernetes»;
• «Destpêkek Polîtîkayên Tora Kubernetes ji bo Pisporên Ewlekariyê»;
• «Fêmkirina RBAC li Kubernetes»;
• «9 Pratîkên Baştirîn Ewlekariya Kubernetes»;
• «11 Awayên Ku (Ne) Bibin Qurbana Hackek Kubernetes".

Source: www.habr.com