Понимание структуры логики Kubernetes API в Go

Question

В настоящее время я пытаюсь сосредоточиться на изучении Go, некоторых подробностях API-интерфейса kubernetes, который я не использовал ранее, и API-интерфейса kubernetes для Go одновременно, и буду признателен за помощь в понимании грамматики эта структура и почему люди все равно ее используют.

Честно говоря, я не уверен, зачем вообще использовать фреймворк, если он содержит ту же информацию, что и конечная точка REST. Разве не имеет смысла просто вызывать API напрямую через библиотеку http?

И вот один пример (взят из некоторого реального кода ):

pod, err := kubecli.CoreV1().Pods(namespace).Get(name, metav1.GetOptions{})

Что меня беспокоит, так это то, что мне нужно посмотреть все в документации API , а затем мне необходимо выяснить, что /v1/ переводится в CoreV1(). И я даже не уверен, где я мог бы это посмотреть. Также весь блок metav1.GetOptions{} кажется совершенно ненужным, или какая часть HTTP-запроса представлена ​​им?

Я надеюсь, что смогу прояснить, в чем путаница, и надеюсь на вашу помощь в ее устранении.

Edit:

Вот также пример, сгенерированный из новой структуры оператора, которая, к сожалению, не делает ее намного лучше:

 return &v1.Pod{
    TypeMeta: metav1.TypeMeta{
            Kind:       "Pod",
            APIVersion: "v1",
    },
    ObjectMeta: metav1.ObjectMeta{
            Name:      "busy-box",
            Namespace: cr.Namespace,
            OwnerReferences: []metav1.OwnerReference{
                    *metav1.NewControllerRef(cr, schema.GroupVersionKind{
                            Group:   v1alpha1.SchemeGroupVersion.Group,
                            Version: v1alpha1.SchemeGroupVersion.Version,
                            Kind:    "Memcached",
                    }),
            },
            Labels: labels,
    },
    Spec: v1.PodSpec{
            Containers: []v1.Container{
                    {
                            Name:    "busybox",
                            Image:   "busybox",
                            Command: []string{"sleep", "3600"},
                    },
            },
    },
 }

Документы API ничего не знают об этом TypeMeta объекте. И второй элемент называется ObjectMeta: вместо metadata. Я имею в виду, я не волшебник. Откуда мне это знать.

Answer 1

Я немного опоздал, но вот мои 2 цента.

Зачем использовать client-go вместо http библиотеки

Есть плюсы сервалов с client-go.

1. Ресурс Kubernetes определен как строго типизированный класс , что означает меньшее количество ошибок в отладке и простоту рефакторинга.

2. Когдамы манипулируем некоторыми ресурсами, он автоматически аутентифицируется с кластером ( doc ), ему нужен только действительный конфиг.И нам не нужно знать, как именно выполняется аутентификация.

3. Имеется несколько версий , совместимых с разными версиями Kubernetes.Это значительно упрощает выравнивание кода с заданной версией kubernetes, не зная всех деталей изменений API.

Как узнать, какой класс и метод следует вызывать

В Справочник по API , каждый ресурс имеет последний тег Group и Version.Например, Pod - это группа core, версия v1, вид Pod в v1.10.

GoDoc перечислил все свойства и ссылки на подробное объяснение для каждого класса, например Pod .

Таким образом, список модулей можно найти, вызвав CoreV1(), затем Pods(namespace string), затем List(opts meta_v1.ListOptions).

Answer 2

Добавление пары вещей к тому, что было упомянуто до сих пор:

Вы действительно могли бы просто сделать http-вызовы против apiserver, но client-go уже сделал всю тяжелую работу за вас! Возьмем, к примеру, эту конечную точку 'watch':

https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.10/#watch-202

Вы можете сами кодировать функциональность или использовать, например, SharedInformer интерфейс

https://github.com/kubernetes/client-go/blob/master/tools/cache/shared_informer.go#L34-L41

Код в client-go был протестирован и не должен содержать ошибок.

Если вы правильно настроите свой редактор для golang, он даст вам подсказки типов и доступные вызовы функций, когда вы начнете вводить вызовы API golang.

Сначала я выучил голанг, а затем попытался вздрогнуть client-go

Answer 3

Коллега предположил, что на самом деле есть автоматически сгенерированные документы под названием godoc . Хотя он не отвечает на все вопросы, он улучшает мою способность уже использовать библиотеки API.