Kubernetes-ისთვის ოპერატორის დაწერა გოლანგში

Შენიშვნა. თარგმნა: ოპერატორები არის დამხმარე პროგრამული უზრუნველყოფა Kubernetes-ისთვის, შექმნილია კლასტერულ ობიექტებზე რუტინული მოქმედებების შესრულების ავტომატიზაციისთვის, როდესაც ხდება გარკვეული მოვლენები. ჩვენ უკვე დავწერეთ ოპერატორების შესახებ ეს მუხლი, სადაც ისაუბრეს თავიანთი მუშაობის ფუნდამენტურ იდეებსა და პრინციპებზე. მაგრამ თუ ეს მასალა უფრო მეტად ჩანდა Kubernetes-ისთვის მზა კომპონენტების ფუნქციონირების მხრივ, მაშინ ახლა შემოთავაზებული ახალი სტატიის თარგმანი უკვე არის დეველოპერი/DevOps ინჟინრის ხედვა, რომელიც გაკვირვებულია ახალი ოპერატორის განხორციელებით.

გადავწყვიტე დამეწერა ეს პოსტი რეალური მაგალითით მას შემდეგ, რაც მცდელობა მეპოვა Kubernetes-ისთვის ოპერატორის შექმნის შესახებ დოკუმენტაცია, რომელიც გაიარა კოდის შესწავლაზე.

მაგალითი, რომელიც იქნება აღწერილი ასეთია: ჩვენს Kubernetes კლასტერში, თითოეული Namespace წარმოადგენს გუნდის სავარჯიშო გარემოს და გვინდოდა შეგვეზღუდა მათზე წვდომა ისე, რომ გუნდებს შეეძლოთ თამაში მხოლოდ საკუთარ სავარჯიშოში.

თქვენ შეგიძლიათ მიაღწიოთ იმას, რაც გსურთ, მომხმარებლისთვის ჯგუფის მინიჭებით RoleBinding კონკრეტული Namespace и ClusterRole რედაქტირების უფლებებით. YAML წარმომადგენლობა ასე გამოიყურება:

---
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  name: kubernetes-team-1
  namespace: team-1
subjects:
- kind: Group
  name: kubernetes-team-1
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: edit
apiGroup: rbac.authorization.k8s.io

(როლის შეკვრა.yamlIn ნედლეული)

შექმენით ერთი RoleBinding თქვენ შეგიძლიათ ამის გაკეთება ხელით, მაგრამ ასი სახელების ნიშნის გადაკვეთის შემდეგ, ეს ხდება დამღლელი ამოცანა. სწორედ აქ გამოდგება Kubernetes-ის ოპერატორები - ისინი საშუალებას გაძლევთ ავტომატიზირდეთ Kubernetes რესურსების შექმნა რესურსებში ცვლილებების საფუძველზე. ჩვენს შემთხვევაში ჩვენ გვინდა შევქმნათ RoleBinding შექმნისას Namespace.

პირველ რიგში განვსაზღვროთ ფუნქცია mainრომელიც აკეთებს საჭირო კონფიგურაციას განცხადების გასაშვებად და შემდეგ უწოდებს განცხადების მოქმედებას:

(Შენიშვნა. თარგმნა: აქ და ქვემოთ კოდის კომენტარები თარგმნილია რუსულად. გარდა ამისა, ჩაღრმავება შესწორებულია ინტერვალით, ნაცვლად [რეკომენდებულია Go] ჩანართების ნაცვლად, მხოლოდ Habr განლაგების უკეთ წაკითხვის მიზნით. ყოველი ჩამონათვალის შემდეგ არის ორიგინალის ბმულები GitHub-ზე, სადაც ინახება ინგლისურენოვანი კომენტარები და ჩანართები.)

func main() {
  // Устанавливаем вывод логов в консольный STDOUT
  log.SetOutput(os.Stdout)

  sigs := make(chan os.Signal, 1) // Создаем канал для получения сигналов ОС
  stop := make(chan struct{})     // Создаем канал для получения стоп-сигнала

  // Регистрируем получение SIGTERM в канале sigs
  signal.Notify(sigs, os.Interrupt, syscall.SIGTERM, syscall.SIGINT) 

  // Goroutines могут сами добавлять себя в WaitGroup,
 // чтобы завершения их выполнения дожидались
  wg := &sync.WaitGroup{} 

  runOutsideCluster := flag.Bool("run-outside-cluster", false, "Set this flag when running outside of the cluster.")
  flag.Parse()
  // Создаем clientset для взаимодействия с кластером Kubernetes
  clientset, err := newClientSet(*runOutsideCluster)

  if err != nil {
    panic(err.Error())
  }

  controller.NewNamespaceController(clientset).Run(stop, wg)

  <-sigs // Ждем сигналов (до получения сигнала более ничего не происходит)
  log.Printf("Shutting down...")

  close(stop) // Говорим goroutines остановиться
  wg.Wait()   // Ожидаем, что все остановлено
}

(მთავარი.წადიIn ნედლეული)

ჩვენ ვაკეთებთ შემდეგს:

1. ჩვენ ვაკონფიგურირებთ დამმუშავებელს კონკრეტული ოპერაციული სისტემის სიგნალებისთვის, რათა გამოიწვიოს ოპერატორის მოხდენილი შეწყვეტა.
2. Ჩვენ ვიყენებთ WaitGroupმოხდენილად შეაჩერონ ყველა გორუტინი განაცხადის შეწყვეტამდე.
3. ჩვენ ვაძლევთ წვდომას კლასტერზე შექმნით clientset.
4. გაშვება NamespaceController, რომელშიც განთავსდება მთელი ჩვენი ლოგიკა.

ახლა ჩვენ გვჭირდება ლოგიკის საფუძველი და ჩვენს შემთხვევაში ეს არის ნახსენები NamespaceController:

// NamespaceController следит через Kubernetes API за изменениями
// в пространствах имен и создает RoleBinding для конкретного namespace.
type NamespaceController struct {
  namespaceInformer cache.SharedIndexInformer
  kclient           *kubernetes.Clientset
}

// NewNamespaceController создает новый NewNamespaceController
func NewNamespaceController(kclient *kubernetes.Clientset) *NamespaceController {
  namespaceWatcher := &NamespaceController{}

  // Создаем информер для слежения за Namespaces
  namespaceInformer := cache.NewSharedIndexInformer(
    &cache.ListWatch{
      ListFunc: func(options metav1.ListOptions) (runtime.Object, error) {
        return kclient.Core().Namespaces().List(options)
      },
      WatchFunc: func(options metav1.ListOptions) (watch.Interface, error) {
        return kclient.Core().Namespaces().Watch(options)
      },
    },
    &v1.Namespace{},
    3*time.Minute,
    cache.Indexers{cache.NamespaceIndex: cache.MetaNamespaceIndexFunc},
  )

  namespaceInformer.AddEventHandler(cache.ResourceEventHandlerFuncs{
    AddFunc: namespaceWatcher.createRoleBinding,
  })

  namespaceWatcher.kclient = kclient
  namespaceWatcher.namespaceInformer = namespaceInformer

  return namespaceWatcher
}

(კონტროლერი.წადიIn ნედლეული)

აქ ჩვენ ვაკონფიგურირებთ SharedIndexInformer, რომელიც ეფექტურად (ქეშის გამოყენებით) დაელოდება ცვლილებებს სახელთა სივრცეებში (დაწვრილებით ინფორმატორების შესახებ სტატიაში ”როგორ მუშაობს კუბერნეტის გრაფიკი რეალურად?"- დაახლ. თარგმანი). ამის შემდეგ ჩვენ ვუკავშირდებით EventHandler ინფორმატორისთვის, რათა სახელთა სივრცის დამატებისას (Namespace) ფუნქცია გამოძახებულია createRoleBinding.

შემდეგი ნაბიჯი არის ამ ფუნქციის განსაზღვრა createRoleBinding:

func (c *NamespaceController) createRoleBinding(obj interface{}) {
  namespaceObj := obj.(*v1.Namespace)
  namespaceName := namespaceObj.Name

  roleBinding := &v1beta1.RoleBinding{
    TypeMeta: metav1.TypeMeta{
      Kind:       "RoleBinding",
      APIVersion: "rbac.authorization.k8s.io/v1beta1",
    },
    ObjectMeta: metav1.ObjectMeta{
      Name:      fmt.Sprintf("ad-kubernetes-%s", namespaceName),
      Namespace: namespaceName,
    },
    Subjects: []v1beta1.Subject{
      v1beta1.Subject{
        Kind: "Group",
        Name: fmt.Sprintf("ad-kubernetes-%s", namespaceName),
      },
    },
    RoleRef: v1beta1.RoleRef{
      APIGroup: "rbac.authorization.k8s.io",
        Kind:     "ClusterRole",
        Name:     "edit",
    },
  }

  _, err := c.kclient.Rbac().RoleBindings(namespaceName).Create(roleBinding)

  if err != nil {
    log.Println(fmt.Sprintf("Failed to create Role Binding: %s", err.Error()))
  } else {
    log.Println(fmt.Sprintf("Created AD RoleBinding for Namespace: %s", roleBinding.Name))
  }
}

(კონტროლერი.წადიIn ნედლეული)

ჩვენ ვიღებთ სახელთა სივრცეს როგორც obj და გადაიყვანეთ ობიექტად Namespace. შემდეგ განვსაზღვრავთ RoleBinding, დასაწყისში ნახსენები YAML ფაილის საფუძველზე, მოწოდებული ობიექტის გამოყენებით Namespace და შექმნა RoleBinding. და ბოლოს, ჩვენ დავრეგისტრირდით, იყო თუ არა შექმნა წარმატებული.

ბოლო ფუნქცია, რომელიც უნდა განისაზღვროს არის Run:

// Run запускает процесс ожидания изменений в пространствах имён
// и действия в соответствии с этими изменениями.
func (c *NamespaceController) Run(stopCh <-chan struct{}, wg *sync.WaitGroup) {
  // Когда эта функция завершена, пометим как выполненную
  defer wg.Done()

  // Инкрементируем wait group, т.к. собираемся вызвать goroutine
  wg.Add(1)

  // Вызываем goroutine
  go c.namespaceInformer.Run(stopCh)

  // Ожидаем получения стоп-сигнала
  <-stopCh
}

(კონტროლერი.წადიIn ნედლეული)

აქ ვსაუბრობთ WaitGroupრომ გავუშვათ გორუტინი და მერე დავურეკოთ namespaceInformer, რომელიც ადრე იყო განსაზღვრული. როდესაც გაჩერების სიგნალი მოვა, ის დაასრულებს ფუნქციას, აცნობეთ WaitGroup, რომელიც აღარ არის შესრულებული და ეს ფუნქცია გამოვა.

ინფორმაცია ამ განცხადების შექმნისა და გაშვების შესახებ Kubernetes კლასტერზე შეგიძლიათ იხილოთ აქ საცავი GitHub-ზე.

ეს არის ის ოპერატორისთვის, რომელიც ქმნის RoleBinding როდესაც Namespace კუბერნეტის კლასტერში, მზადაა.

წყარო: www.habr.com