Интересный вопрос, вот некоторые идеи и примеры использования на практике.
Есть еще много примеров на практике.Например, вы можете проверить ClusterRoles по умолчанию, просматривая kubectl describe clusterroles.И чтобы увидеть, какие API-запросы kubectl делает изнутри, вы можете увеличить детализацию журнала, например, kubectl get pods -w -v 10.
get , но не list
Вы хотите, чтобы кто-то мог прочитать ресурсы, которые он знает по имени, но не узнать, какие существуют другие ресурсы.Например, позволяет делать kubectl get mypod, но не kubectl get pods.
Примеры:
-
system:node ClusterRole имеет get , но не list разрешения для конечных точек, PV и PVC. system:coredns ClusterRole имеет get , но не list разрешения для узлов. system:controller:expand-controller ClusterRole имеет получить , но не список разрешений для конечных точек, секретов и служб.
список , ноnot get
Позволяет, например, kubectl get pods, но не kubectl get pod mypod.Это не имеет особого смысла, потому что вся информация, которую вы можете получить с помощью get , также включена в list .Тем не менее, есть некоторые способы использования этого на практике.
Примеры:
-
system:kube-dns ClusterRole имеет разрешения list и watch для конечных точек и служб, но не get. system:controller:daemon-set-controller ClusterRoel имеет разрешения list и watch для узлов, но не get . system:coredns ClusterRole имеет разрешения list и watch для конечных точек, пространств имен, модулей и служб, но не get .
получить и список , но не смотреть
На практике в большинстве случаев, когда есть список , естьтакже часы .Вы можете лишить кого-то watch , чтобы уменьшить количество наблюдателей на etcd.Пользователи могут выполнять kubectl get pods и kubectl get pods mypod, но не использовать опцию -w.
Имеет смысл также, если API не поддерживает операции watch , как, например,необязательные метрические API.
Примеры:
-
system:controller:persistent-volume-binder ClusterRole имеет get и список разрешений для узлов, но не смотреть
смотреть , но не получить и список
Что касается варианта использования,в этом нет особого смысла, потому что вся информация, которую вы можете получить с помощью get и list , также включена в watch .Я не знаю ни одного конкретного использования этого на практике.
Однако, технически, это возможно.Например, если у вас есть разрешения смотреть для модулей, но не получить и список , вы можете сделать:
✅ kubectl get --raw="/api/v1/watch/namespaces/default/pods"
✅ kubectl get --raw="/api/v1/watch/namespaces/default/pods/mypod"
И этоработает.Однако эти watch конечные точки устарели, и вместо них следует использовать list endpoint с параметром watch.Но это также работает:
✅ kubectl get --raw="/api/v1/namespaces/default/pods?watch=true"
Тем не менее, вы не можете смотреть ни одного Pod, как это, потому что конечная точка get не имеет параметра watch.Итак, следующее недопустимо:
❌ kubectl get --raw="/api/v1/namespaces/default/pods/mypod?watch=true"
И вы не можете смотреть ресурсы с kubectl вообще.Сбой следующего:
❌ kubectl get pods -w
❌ kubectl get pods mypod -w
Поскольку kubectl делает запрос list и get , соответственно, перед запросом watch , скорее всего,получите resourceVersion ресурсов, которые затем будут включены в последующий запрос watch .
Примечание: это означает, что если у вас есть list и смотреть , затем kubectl get pods -w работает, но kubectl get pods mypod -w нет, а если у вас есть get и смотреть , то kubectl get pods mypod -w работает, но kubectl get pods -w не работаетт.