Если вы спец в OpenShift, то этот пост вряд ли откроет вам много нового. Но если вы только начинаете его осваивать, то он сэкономит вам массу времени и нервов. Мы попросили Хорхе Тудела Гонсалеса де Рианчо, облачного консультанта в испанском офисе Red Hat, написать несколько лайфхаков для утилиты oc.
Это крутая команда, она здорово продумана, она мощная, она гибкая, и у нее, как вы увидите, есть много скрытых возможностей, которые стоит попробовать.
Когда я не знаю, что происходит, или получаю непонятное сообщение об ошибке, я всегда использую флаг --loglevell, который включает запись лога в stderr. В зависимости от значения этого флага можно увидеть curl-вызовы API Rest, содержание ответов API Rest или даже более детализированную информацию.
Например, loglevel 9 очень удобен, когда вы патчите OCP-объект, поскольку позволяет увидеть сам патч (содержание API-запроса).
Если, допустим, патч меняет метку сервиса на «app: hello-jorge», то это будет выглядеть так:
Примечание. В моменты отчаяния вместо одной девятки можно вбивать сразу несколько. Вывод команды oc от этого не изменится, но, возможно, вам полегчает.
Да, вы правильно поняли. Команду oc можно запустить от имени другого пользователя, или, говоря на языке OCP, использовать имперсонацию. Разумеется, при наличии соответствующих прав. И для этого достаточно всего лишь использовать флаг --as.
Например:
Имперсонация работает не только для пользователей, но и для групп:
Имперсонация пригодится в самых разных случаях. Например, когда надо проверить, сможет ли пользователь выполнить то или иное действие, или посмотреть, что ему выдаст команда oc. Еще имперсонация очень помогает при неразберихе с ролями и разрешениями.
Команда oc whoami знакома, наверное, всем. Особенно флаг -t, позволяющий получить токен носителя для текущего пользователя/сеанса. Но что делать, если у вас есть токен, но вы не его владелец?
В этом случае можно войти в OpenShift с помощью этого токена, а затем выполнить команду oc whoami. Хотя, подождите, можно же сразу узнать имя владельца, просто передав токен команде oc whoami третьим аргументом без всяких флагов.
Смотрите:
Как известно, shell можно запустить прямо в работающем pod'е. Иногда бывает полезно сделать полную копию конфигурации запущенного pod'а и устранять неполадки через shell. Это так называемый метод по умолчанию.
А теперь взгляните, что позволяют сделать опции oc debug: можно запустить контейнер от имени root или любого другого пользователя; можно запустить его на выбранном узле или можно запустить в нем не shell, а другую команду.
При этом надо указывать верный dc, например:
В объектах OpenShift/Kubernetes иногда бывает огромное множество полей. В поисках примеров определений таких объектов часто приходится обращаться к документации по OCP или другим первоисточникам. Однако с тем же успехом можно использовать команду oc explain.
Эта команда выводит документацию по ресурсам и их полям, что бывает очень полезно при декларировании новых объектов OCP или в тех случаях, когда у вас нет доступа к официальной документации OCP.
Например, вот как можно получить документацию по pod’ам и описание affinity-полей:
Еще одна крутая фишка команды oc – это встроенные функции форматирования вывода. Про опции -o json или -o yaml знают все, но у флага -o есть и множество других опций.
Самые мощные, возможно, – это go-template и jsonpath:
Скажем, вы хотите узнать, какой сервис, предоставляется определенным маршрутом (маршрутом docker-реестра):
Или, допустим, нужно узнать стратегию развертывания маршрутизатора router dc:
Как видите, oc – это удивительная команда. С ней определенно стоит поиграться, поскольку это одна из самых крутых вещей в OpenShift.
Если вы хотите узнать больше про интересные возможности OpenShift, рекомендуем заглянуть в наш блог Red Hat Developer – здесь вас ждут не только статьи от наших разработчиков практически на любую тему, но и огромный каталог бесплатной литературы. А еще можно освежить в памяти наш пост о том, как развернуть Minishift на своем ноутбуке и начать жить.
Это крутая команда, она здорово продумана, она мощная, она гибкая, и у нее, как вы увидите, есть много скрытых возможностей, которые стоит попробовать.
1. Перво-наперво: отладка
Когда я не знаю, что происходит, или получаю непонятное сообщение об ошибке, я всегда использую флаг --loglevell, который включает запись лога в stderr. В зависимости от значения этого флага можно увидеть curl-вызовы API Rest, содержание ответов API Rest или даже более детализированную информацию.
$ oc --loglevel 7 get pod
...
I0216 21:24:12.027793 973 cached_discovery.go:72] returning cached discovery info from /home/jtudelag/.kube/192.168.42.77_8443/v1/serverresources.json
I0216 21:24:12.028046 973 round_trippers.go:383] GET https://192.168.42.77:8443/api/v1/namespaces/myproject/pods
I0216 21:24:12.028052 973 round_trippers.go:390] Request Headers:
I0216 21:24:12.028057 973 round_trippers.go:393] Accept: application/json
I0216 21:24:12.028061 973 round_trippers.go:393] User-Agent: oc/v1.7.6+a08f5eeb62 (linux/amd64) kubernetes/c84beff
I0216 21:24:12.053230 973 round_trippers.go:408] Response Status: 200 OK in 25 milliseconds
I0216 21:24:12.055143 973 cached_discovery.go:119] returning cached discovery info from /home/jtudelag/.kube/192.168.42.77_8443/servergroups.json
I0216 21:24:12.055228 973 cached_discovery.go:72] returning cached discovery info from /home/jtudelag/.kube/192.168.42.77_8443/authentication.k8s.io/v1/serverresources.json
I0216 21:24:12.055288 973 cached_discovery.go:72]
...
Например, loglevel 9 очень удобен, когда вы патчите OCP-объект, поскольку позволяет увидеть сам патч (содержание API-запроса).
Если, допустим, патч меняет метку сервиса на «app: hello-jorge», то это будет выглядеть так:
$ oc --loglevel 9 edit svc hello-openshift
...
I0216 21:33:15.786463 1389 request.go:994] Request Body: {"metadata":{"labels":{"app":"hello-jorge"}}}
I0216 21:33:15.786590 1389 round_trippers.go:386] curl -k -v -XPATCH -H "Accept: application/json" -H "Content-Type: application/strategic-merge-patch+json" -H "User-Agent: oc/v1.7.6+a08f5eeb62 (linux/amd64) kubernetes/c84beff" https://192.168.42.77:8443/api/v1/namespaces/myproject/services/hello-openshift
I0216 21:33:15.797185 1389 round_trippers.go:405] PATCH https://192.168.42.77:8443/api/v1/namespaces/myproject/services/hello-openshift 200 OK in 10 milliseconds
...
Примечание. В моменты отчаяния вместо одной девятки можно вбивать сразу несколько. Вывод команды oc от этого не изменится, но, возможно, вам полегчает.
$ oc --loglevel 9999 get pod
2. su –
Да, вы правильно поняли. Команду oc можно запустить от имени другого пользователя, или, говоря на языке OCP, использовать имперсонацию. Разумеется, при наличии соответствующих прав. И для этого достаточно всего лишь использовать флаг --as.
Например:
# запускаем от имени пользователя jorge
$ oc --as=jorge get pods
Имперсонация работает не только для пользователей, но и для групп:
# запускаем от имени группы developers
$ oc --as-group=developers get pods
Имперсонация пригодится в самых разных случаях. Например, когда надо проверить, сможет ли пользователь выполнить то или иное действие, или посмотреть, что ему выдаст команда oc. Еще имперсонация очень помогает при неразберихе с ролями и разрешениями.
3. Whoami
Команда oc whoami знакома, наверное, всем. Особенно флаг -t, позволяющий получить токен носителя для текущего пользователя/сеанса. Но что делать, если у вас есть токен, но вы не его владелец?
В этом случае можно войти в OpenShift с помощью этого токена, а затем выполнить команду oc whoami. Хотя, подождите, можно же сразу узнать имя владельца, просто передав токен команде oc whoami третьим аргументом без всяких флагов.
Смотрите:
# сохраняем токен
$ token=$(oc whoami -t)
# получаем имя владельца токена
$ oc whoami $token
jorge
4. oc debug
Как известно, shell можно запустить прямо в работающем pod'е. Иногда бывает полезно сделать полную копию конфигурации запущенного pod'а и устранять неполадки через shell. Это так называемый метод по умолчанию.
А теперь взгляните, что позволяют сделать опции oc debug: можно запустить контейнер от имени root или любого другого пользователя; можно запустить его на выбранном узле или можно запустить в нем не shell, а другую команду.
При этом надо указывать верный dc, например:
# получаем shell внутри pod’а dc/jorge
$ oc debug dc/jorge
# то же самое, но как root
$ oc debug --as-root=true dc/jorge
5. oc explain
В объектах OpenShift/Kubernetes иногда бывает огромное множество полей. В поисках примеров определений таких объектов часто приходится обращаться к документации по OCP или другим первоисточникам. Однако с тем же успехом можно использовать команду oc explain.
Эта команда выводит документацию по ресурсам и их полям, что бывает очень полезно при декларировании новых объектов OCP или в тех случаях, когда у вас нет доступа к официальной документации OCP.
Например, вот как можно получить документацию по pod’ам и описание affinity-полей:
# получаем справку по pod’у
$ oc explain pod
DESCRIPTION:
Pod is a collection of containers that can run on a host. This resource is created by clients and scheduled onto hosts.
FIELDS:
metadata <Object>
Standard object's metadata. More info:
http://releases.k8s.io/HEAD/docs/devel/api-conventions.md#metadata
spec <Object>
Specification of the desired behavior of the pod. More info:
http://releases.k8s.io/HEAD/docs/devel/api-conventions.md#spec-and-status
status <Object>
Most recently observed status of the pod. This data may not be up to date.
Populated by the system. Read-only. More info:
http://releases.k8s.io/HEAD/docs/devel/api-conventions.md#spec-and-status
apiVersion <string>
APIVersion defines the versioned schema of this representation of an
object. Servers should convert recognized schemas to the latest internal
value, and may reject unrecognized values. More info:
http://releases.k8s.io/HEAD/docs/devel/api-conventions.md#resources
kind <string>
Kind is a string value representing the REST resource this object
represents. Servers may infer this from the endpoint the client submits
requests to. Cannot be updated. In CamelCase. More info:
http://releases.k8s.io/HEAD/docs/devel/api-conventions.md#types-kinds
# получаем описание полей affinity
$ oc explain pod.spec.affinity
RESOURCE: affinity <Object>
DESCRIPTION:
If specified, the pod's scheduling constraints
Affinity is a group of affinity scheduling rules.
FIELDS:
nodeAffinity <Object>
Describes node affinity scheduling rules for the pod.
podAffinity <Object>
Describes pod affinity scheduling rules (e.g. co-locate this pod in the
same node, zone, etc. as some other pod(s)).
podAntiAffinity <Object>
Describes pod anti-affinity scheduling rules (e.g. avoid putting this pod
in the same node, zone, etc. as some other pod(s)).
6. Забудьте про grep, awk, cut и т. п.
Еще одна крутая фишка команды oc – это встроенные функции форматирования вывода. Про опции -o json или -o yaml знают все, но у флага -o есть и множество других опций.
Самые мощные, возможно, – это go-template и jsonpath:
json|yaml|wide|name|custom-columns=...|custom-columns-file=...|go-template=...|go-template-file=...|jsonpath=...|jsonpath-file=...
Скажем, вы хотите узнать, какой сервис, предоставляется определенным маршрутом (маршрутом docker-реестра):
# запросим сервисы, предоставляемые маршрутами, но только для узла с именем my-docker-registry.example.com
$ oc get routes -o=go-template='{{range .items}}{{if eq .spec.host "my-docker-registry.example.com"}}{{.metadata.name}}{{end}}{{end}}'
docker-registry
Или, допустим, нужно узнать стратегию развертывания маршрутизатора router dc:
# запросим стратегию развертывания маршрутизатора
$ oc get dc router -o=go-template='{{ .spec.strategy.type }}'
Rolling
Как видите, oc – это удивительная команда. С ней определенно стоит поиграться, поскольку это одна из самых крутых вещей в OpenShift.
Если вы хотите узнать больше про интересные возможности OpenShift, рекомендуем заглянуть в наш блог Red Hat Developer – здесь вас ждут не только статьи от наших разработчиков практически на любую тему, но и огромный каталог бесплатной литературы. А еще можно освежить в памяти наш пост о том, как развернуть Minishift на своем ноутбуке и начать жить.
