Ի՞նչ մեխանիզմներով է իրականացվում անհատական ռեսուրսների հասանելիությունը։

Կաշկանդված ռեսուրսների (Custom Resources, CR) մուտքը Kubernetes-ում իրականացվում է նույն մեխանիզմների միջոցով, ինչ և ներքին ռեսուրսների դեպքում, բայց հաշվի առնելով դրանց առանձնահատկությունները:

Հիմնական մեխանիզմներ՝

1. Kubernetes API Server: Հիմնական մեխանիզմը։ API Server-ը տրամադրում է RESTful API՝ բոլոր ռեսուրսների կառավարման համար, ներառյալ CR-երը։

   • API Server-ի միջոցով կարող եք ստեղծել, կարդալ, թարմացնել և ջնջել CR-երը (CRUD գործողություններ)։
   • API Server-ի մուտքը վերահսկվում է աութենտիկացիայի, թույլտվության և մուտքի վերահսկման (Admission Controllers) միջոցով։

2. kubectl: Կոմանդայի տողային գործիք՝ Kubernetes կլաստի հետ փոխազդելու համար։

   • Օգտագործում է Kubernetes API Server-ը՝ հրամանների կատարման համար։
   • Պատրաստ է CR-ների հետ աշխատել ինչպես ստանդարտ ռեսուրսների, այնպես էլ՝ օրինակ՝՝

     # 'myresource' տիպի հատուկ ռեսուրսների ցանկը ստանալ
     kubectl get myresources
     # կոնկրետ հատուկ ռեսուրսի նկարագրությունը
     kubectl describe myresource my-instance-name
     # YAML ֆայլից հատուկ ռեսուրս ստեղծել
     kubectl create -f my-resource.yaml
     

   • Պահանջում է, որ կլաստում լինի համապատասխան CRD (CustomResourceDefinition)։

3. Clients (SDKs): Բազմաբնույթ ծրագրավորման լեզուներով՝ գրադարաններ՝ Kubernetes API-ի հետ աշխատելու համար։

   • Позволяют программно взаимодействовать с CR.
   • Чаще всего используются контроллеры (Operators)՝ CR-ների կյանքի ցիկլը կառավարելու համար։

   // Go լեզվով օրինակ՝ client-go օգտագործելով
   config, err := rest.InClusterConfig() // կամ clientcmd.BuildConfigFromFlags
   եթե err != nil {
       // ... սխալի մշակումը ...
   }
   
   // Դինամիկ հաճախորդ ստեղծել ցանկացած ռեսուրսի համար
   dynamicClient, err := dynamic.NewForConfig(config)
   եթե err != nil {
       // ... սխալի մշակումը ...
   }
   
   gvr := schema.GroupVersionResource{Group: "stable.example.com", Version: "v1", Resource: "myresources"}
   
   // Կառավարել հատուկ ռեսուրսների ցանկը
   unstructuredList, err := dynamicClient.Resource(gvr).Namespace("default").List(context.TODO(), metav1.ListOptions{})
   եթե err != nil {
       // ... սխալի մշակումը ...
   }
   
   // Ցիկլի հետ աշխատել
   

4. Operators (Operators): Ավտոմատացման մոդել՝ CR և վերահսկիչներ օգտագործելով՝ բարդ ծրագրեր կառավարելու համար։

   • Օպերատորները պարունակում են տրամաբանություն՝ CR-ների փոփոխություններին արձագանքելու և անհրաժեշտ գործողություններ կատարելու համար (օր., Pod, Service ստեղծել և այլն)։
   • Օգտագործում են հաճախորդային գրադարաններ (Clients)՝ CR-ների և այլ ռեսուրսների հետ փոխազդելու համար։

5. RBAC (Role-Based Access Control): Հասանելիության կառավարման համակարգ՝ Kubernetes-ում։

   • Գործառույթը վերահսկվում է դերերով և դերերի կապերով։
   • Պետք է հստակ տրամադրել թույլտվություններ (verbs՝ get, list, create, update, delete, watch)՝ որոշ խմբերի և ռեսուրսների համար (CRD կամ կոնկրետ CR)։

   # Դեմո դեր՝ 'myresources' հասանելիության համար
   apiVersion: rbac.authorization.k8s.io/v1
   kind: Role
   metadata:
     name: myresource-reader
     namespace: default
   rules:
   - apiGroups: ["stable.example.com"] # API խմբի անունը
     resources: ["myresources"]       # հատուկ ռեսուրսի անունը բազմահազար ձևով
     verbs: ["get", "list", "watch"]  # թույլատրված գործողություններ
   

Հասանելիությունը CR-ներին նույնն է, ինչ և ներքին ռեսուրսների, API մակարդակում, բայց պահանջում է համապատասխան CRD-ի առկայություն և ճիշտ RBAC կանոններ, որոնք բացահայտորեն ներառում են API խմբին և ռեսուրսի անվանը։