В этой главе мы рассмотрим такие темы, как управление узлом, настройка учетной записи службы и т. Д.
Конфигурация мастера и узла
В OpenShift нам нужно использовать команду start вместе с OC для загрузки нового сервера. При запуске нового мастера нам нужно использовать мастер вместе с командой запуска, тогда как при запуске нового узла нам нужно использовать узел вместе с командой запуска. Чтобы сделать это, нам нужно создать файлы конфигурации для мастера, а также для узлов. Мы можем создать базовый файл конфигурации для мастера и узла, используя следующую команду.
Для главного файла конфигурации
$ openshift start master --write-config = /openshift.local.config/master
Для файла конфигурации узла
$ oadm create-node-config --node-dir = /openshift.local.config/node-<node_hostname> --node = <node_hostname> --hostnames = <hostname>,<ip_address>
Выполнив следующие команды, мы получим базовые файлы конфигурации, которые можно использовать в качестве отправной точки для конфигурации. Позже мы можем иметь тот же файл для загрузки новых серверов.
apiLevels:
- v1beta3
- v1
apiVersion: v1
assetConfig:
logoutURL: ""
masterPublicURL: https://172.10.12.1:7449
publicURL: https://172.10.2.2:7449/console/
servingInfo:
bindAddress: 0.0.0.0:7449
certFile: master.server.crt
clientCA: ""
keyFile: master.server.key
maxRequestsInFlight: 0
requestTimeoutSeconds: 0
controllers: '*'
corsAllowedOrigins:
- 172.10.2.2:7449
- 127.0.0.1
- localhost
dnsConfig:
bindAddress: 0.0.0.0:53
etcdClientInfo:
ca: ca.crt
certFile: master.etcd-client.crt
keyFile: master.etcd-client.key
urls:
- https://10.0.2.15:4001
etcdConfig:
address: 10.0.2.15:4001
peerAddress: 10.0.2.15:7001
peerServingInfo:
bindAddress: 0.0.0.0:7001
certFile: etcd.server.crt
clientCA: ca.crt
keyFile: etcd.server.key
servingInfo:
bindAddress: 0.0.0.0:4001
certFile: etcd.server.crt
clientCA: ca.crt
keyFile: etcd.server.key
storageDirectory: /root/openshift.local.etcd
etcdStorageConfig:
kubernetesStoragePrefix: kubernetes.io
kubernetesStorageVersion: v1
openShiftStoragePrefix: openshift.io
openShiftStorageVersion: v1
imageConfig:
format: openshift/origin-${component}:${version}
latest: false
kind: MasterConfig
kubeletClientInfo:
ca: ca.crt
certFile: master.kubelet-client.crt
keyFile: master.kubelet-client.key
port: 10250
kubernetesMasterConfig:
apiLevels:
- v1beta3
- v1
apiServerArguments: null
controllerArguments: null
masterCount: 1
masterIP: 10.0.2.15
podEvictionTimeout: 5m
schedulerConfigFile: ""
servicesNodePortRange: 30000-32767
servicesSubnet: 172.30.0.0/16
staticNodeNames: []
masterClients:
externalKubernetesKubeConfig: ""
openshiftLoopbackKubeConfig: openshift-master.kubeconfig
masterPublicURL: https://172.10.2.2:7449
networkConfig:
clusterNetworkCIDR: 10.1.0.0/16
hostSubnetLength: 8
networkPluginName: ""
serviceNetworkCIDR: 172.30.0.0/16
oauthConfig:
assetPublicURL: https://172.10.2.2:7449/console/
grantConfig:
method: auto
identityProviders:
- challenge: true
login: true
name: anypassword
provider:
apiVersion: v1
kind: AllowAllPasswordIdentityProvider
masterPublicURL: https://172.10.2.2:7449/
masterURL: https://172.10.2.2:7449/
sessionConfig:
sessionMaxAgeSeconds: 300
sessionName: ssn
sessionSecretsFile: ""
tokenConfig:
accessTokenMaxAgeSeconds: 86400
authorizeTokenMaxAgeSeconds: 300
policyConfig:
bootstrapPolicyFile: policy.json
openshiftInfrastructureNamespace: openshift-infra
openshiftSharedResourcesNamespace: openshift
projectConfig:
defaultNodeSelector: ""
projectRequestMessage: ""
projectRequestTemplate: ""
securityAllocator:
mcsAllocatorRange: s0:/2
mcsLabelsPerProject: 5
uidAllocatorRange: 1000000000-1999999999/10000
routingConfig:
subdomain: router.default.svc.cluster.local
serviceAccountConfig:
managedNames:
- default
- builder
- deployer
masterCA: ca.crt
privateKeyFile: serviceaccounts.private.key
privateKeyFile: serviceaccounts.private.key
publicKeyFiles:
- serviceaccounts.public.key
servingInfo:
bindAddress: 0.0.0.0:8443
certFile: master.server.crt
clientCA: ca.crt
keyFile: master.server.key
maxRequestsInFlight: 0
requestTimeoutSeconds: 3600
Файлы конфигурации узла
allowDisabledDocker: true
apiVersion: v1
dnsDomain: cluster.local
dnsIP: 172.10.2.2
dockerConfig:
execHandlerName: native
imageConfig:
format: openshift/origin-${component}:${version}
latest: false
kind: NodeConfig
masterKubeConfig: node.kubeconfig
networkConfig:
mtu: 1450
networkPluginName: ""
nodeIP: ""
nodeName: node1.example.com
podManifestConfig:
path: "/path/to/pod-manifest-file"
fileCheckIntervalSeconds: 30
servingInfo:
bindAddress: 0.0.0.0:10250
certFile: server.crt
clientCA: node-client-ca.crt
keyFile: server.key
volumeDirectory: /root/openshift.local.volumes
Вот так выглядят файлы конфигурации узла. Как только у нас есть эти файлы конфигурации, мы можем запустить следующую команду для создания главного сервера и сервера узлов.
$ openshift start --master-config = /openshift.local.config/master/master- config.yaml --node-config = /openshift.local.config/node-<node_hostname>/node- config.yaml
Управляющие узлы
В OpenShift у нас есть утилита командной строки OC, которая в основном используется для выполнения всех операций в OpenShift. Мы можем использовать следующие команды для управления узлами.
Для перечисления узла
$ oc get nodes NAME LABELS node1.example.com kubernetes.io/hostname = vklnld1446.int.example.com node2.example.com kubernetes.io/hostname = vklnld1447.int.example.com
Описание деталей об узле
$ oc describe node <node name>
Удаление узла
$ oc delete node <node name>
Список модулей на узле
$ oadm manage-node <node1> <node2> --list-pods [--pod-selector=<pod_selector>] [-o json|yaml]
Оценка стручков на узле
$ oadm manage-node <node1> <node2> --evacuate --dry-run [--pod-selector=<pod_selector>]
Аутентификация конфигурации
В мастере OpenShift есть встроенный сервер OAuth, который можно использовать для управления аутентификацией. Все пользователи OpenShift получают токен с этого сервера, который помогает им общаться с OpenShift API.
В OpenShift есть разные уровни аутентификации, которые можно настроить вместе с основным файлом конфигурации.
- Позволять все
- Запретить все
- Htpasswd
- LDAP
- Базовая аутентификация
- Заголовок запроса
Определяя основную конфигурацию, мы можем определить политику идентификации, где мы можем определить тип политики, которую мы хотим использовать.
Позволять все
Позволять все
oauthConfig:
...
identityProviders:
- name: Allow_Authontication
challenge: true
login: true
provider:
apiVersion: v1
kind: AllowAllPasswordIdentityProvider
Запретить все
Это запретит доступ ко всем именам пользователей и паролям.
oauthConfig:
...
identityProviders:
- name: deny_Authontication
challenge: true
login: true
provider:
apiVersion: v1
kind: DenyAllPasswordIdentityProvider
Htpasswd
HTPasswd используется для проверки имени пользователя и пароля по отношению к зашифрованному файлу пароля.
Для создания зашифрованного файла, следующая команда.
$ htpasswd </path/to/users.htpasswd> <user_name>
Использование зашифрованного файла.
oauthConfig:
...
identityProviders:
- name: htpasswd_authontication
challenge: true
login: true
provider:
apiVersion: v1
kind: HTPasswdPasswordIdentityProvider
file: /path/to/users.htpasswd
Поставщик удостоверений LDAP
Это используется для аутентификации LDAP, где сервер LDAP играет ключевую роль в аутентификации.
oauthConfig:
...
identityProviders:
- name: "ldap_authontication"
challenge: true
login: true
provider:
apiVersion: v1
kind: LDAPPasswordIdentityProvider
attributes:
id:
- dn
email:
- mail
name:
- cn
preferredUsername:
- uid
bindDN: ""
bindPassword: ""
ca: my-ldap-ca-bundle.crt
insecure: false
url: "ldap://ldap.example.com/ou=users,dc=acme,dc=com?uid"
Базовая аутентификация
Это используется, когда проверка имени пользователя и пароля выполняется на основе межсерверной аутентификации. Аутентификация защищена в базовом URL и представлена в формате JSON.
oauthConfig:
...
identityProviders:
- name: my_remote_basic_auth_provider
challenge: true
login: true
provider:
apiVersion: v1
kind: BasicAuthPasswordIdentityProvider
url: https://www.vklnld908.int.example.com/remote-idp
ca: /path/to/ca.file
certFile: /path/to/client.crt
keyFile: /path/to/client.key
Настройка учетной записи службы
Учетные записи служб предоставляют гибкий способ доступа к API OpenShift, предоставляя имя пользователя и пароль для аутентификации.
Включение учетной записи службы
Сервисная учетная запись использует пару ключей открытого и закрытого ключей для аутентификации. Аутентификация в API выполняется с использованием закрытого ключа и проверки его по открытому ключу.
ServiceAccountConfig: ... masterCA: ca.crt privateKeyFile: serviceaccounts.private.key publicKeyFiles: - serviceaccounts.public.key - ...
Создание учетной записи службы
Используйте следующую команду для создания учетной записи службы
$ Openshift cli create service account <name of server account>
Работа с HTTP прокси
В большинстве производственных сред прямой доступ к Интернету ограничен. Они либо не подключены к Интернету, либо через HTTP или HTTPS-прокси. В среде OpenShift это определение прокси-машины устанавливается как переменная среды.
Это можно сделать, добавив определение прокси-сервера в файлы master и node, расположенные в / etc / sysconfig . Это похоже на то, что мы делаем для любого другого приложения.
Мастер Машина
/ И т.д. / sysconfig / OpenShift-мастер
HTTP_PROXY=http://USERNAME:PASSWORD@172.10.10.1:8080/ HTTPS_PROXY=https://USERNAME:PASSWORD@172.10.10.1:8080/ NO_PROXY=master.vklnld908.int.example.com
Узел Машина
/ И т.д. / sysconfig / OpenShift-узел
HTTP_PROXY=http://USERNAME:PASSWORD@172.10.10.1:8080/ HTTPS_PROXY=https://USERNAME:PASSWORD@172.10.10.1:8080/ NO_PROXY=master.vklnld908.int.example.com
После этого нам нужно перезапустить главный и узловой компьютеры.
Для Docker Pull
/ И т.д. / sysconfig / Докер
HTTP_PROXY = http://USERNAME:PASSWORD@172.10.10.1:8080/ HTTPS_PROXY = https://USERNAME:PASSWORD@172.10.10.1:8080/ NO_PROXY = master.vklnld1446.int.example.com
Чтобы запустить модуль в прокси-среде, это можно сделать с помощью —
containers:
- env:
- name: "HTTP_PROXY"
value: "http://USER:PASSWORD@:10.0.1.1:8080"
Команда среды OC может использоваться для обновления существующего окружения.
OpenShift Storage с NFS
В OpenShift концепция постоянных томов и утверждений о постоянных томах образует постоянное хранилище. Это одна из ключевых концепций, при которой сначала создается постоянный том, а затем утверждается тот же том. Для этого нам необходимо иметь достаточно емкости и дискового пространства на базовом оборудовании.
apiVersion: v1
kind: PersistentVolume
metadata:
name: storage-unit1
spec:
capacity:
storage: 10Gi
accessModes:
- ReadWriteOnce
nfs:
path: /opt
server: 10.12.2.2
persistentVolumeReclaimPolicy: Recycle
Далее с помощью команды OC create создайте постоянный том.
$ oc create -f storage-unit1.yaml persistentvolume " storage-unit1 " created
Утверждение созданного объема.
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: Storage-clame1
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 5Gi
Создайте заявку.
$ oc create -f Storage-claim1.yaml persistentvolume " Storage-clame1 " created
Управление пользователями и ролями
Администрирование пользователей и ролей используется для управления пользователями, их доступом и контроля над различными проектами.
Создание пользователя
Предопределенные шаблоны могут использоваться для создания новых пользователей в OpenShift.
kind: "Template"
apiVersion: "v1"
parameters:
- name: vipin
required: true
objects:
- kind: "User"
apiVersion: "v1"
metadata:
name: "${email}"
- kind: "Identity"
apiVersion: "v1"
metadata:
name: "vipin:${email}"
providerName: "SAML"
providerUserName: "${email}"
- kind: "UserIdentityMapping"
apiVersion: "v1"
identity:
name: "vipin:${email}"
user:
name: "${email}"
Используйте oc create –f <имя файла> для создания пользователей.
$ oc create –f vipin.yaml
Используйте следующую команду, чтобы удалить пользователя в OpenShift.
$ oc delete user <user name>
Ограничение доступа пользователя
ResourceQuotas и LimitRanges используются для ограничения уровней доступа пользователей. Они используются для ограничения стручков и контейнеров в кластере.
apiVersion: v1
kind: ResourceQuota
metadata:
name: resources-utilization
spec:
hard:
pods: "10"
Создание цитаты с использованием вышеуказанной конфигурации
$ oc create -f resource-quota.yaml –n –Openshift-sample
Описание ресурса цитата
$ oc describe quota resource-quota -n Openshift-sample Name: resource-quota Namespace: Openshift-sample Resource Used Hard -------- ---- ---- pods 3 10
Определение ограничений контейнера может использоваться для ограничения ресурсов, которые будут использоваться развернутыми контейнерами. Они используются для определения максимальных и минимальных ограничений определенных объектов.
Пользовательские ограничения проекта
Это в основном используется для количества проектов, которые пользователь может иметь в любой момент времени. Они в основном сделаны путем определения пользовательских уровней в категориях бронза, серебро и золото.
Сначала нам нужно определить объект, который содержит значение того, сколько проектов может иметь бронзовая, серебряная и золотая категории. Это нужно сделать в файле master-confif.yaml.
admissionConfig:
pluginConfig:
ProjectRequestLimit:
configuration:
apiVersion: v1
kind: ProjectRequestLimitConfig
limits:
- selector:
level: platinum
- selector:
level: gold
maxProjects: 15
- selector:
level: silver
maxProjects: 10
- selector:
level: bronze
maxProjects: 5
Перезагрузите главный сервер.
Назначение пользователя определенному уровню.
$ oc label user vipin level = gold
Перемещение пользователя из метки, если требуется.
$ oc label user <user_name> level-
Добавление ролей пользователю.
$ oadm policy add-role-to-user<user_name>
Удаление роли от пользователя.
$ oadm policy remove-role-from-user<user_name>
Добавление роли кластера для пользователя.
$ oadm policy add-cluster-role-to-user<user_name>
Удаление роли кластера от пользователя.
$ oadm policy remove-cluster-role-from-user<user_name>
Добавление роли в группу.
$ oadm policy add-role-to-user<user_name>
Удаление роли из группы.
$ oadm policy remove-cluster-role-from-user<user_name>
Добавление роли кластера в группу.
$ oadm policy add-cluster-role-to-group<groupname>
Удаление роли кластера из группы.
$ oadm policy remove-cluster-role-from-group <role> <groupname>
Пользователь для администрирования кластера
Это одна из самых мощных ролей, где пользователь имеет возможность управлять целым кластером, начиная с создания и до удаления кластера.