OpenShift - Administration
In diesem Kapitel werden Themen wie das Verwalten eines Knotens, das Konfigurieren eines Dienstkontos usw. behandelt.
Master- und Knotenkonfiguration
In OpenShift müssen wir den Befehl start zusammen mit OC verwenden, um einen neuen Server zu starten. Beim Starten eines neuen Masters müssen wir den Master zusammen mit dem Startbefehl verwenden, während wir beim Starten des neuen Knotens den Knoten zusammen mit dem Startbefehl verwenden müssen. Dazu müssen wir Konfigurationsdateien sowohl für den Master als auch für die Knoten erstellen. Mit dem folgenden Befehl können wir eine grundlegende Konfigurationsdatei für den Master und den Knoten erstellen.
Für die Master-Konfigurationsdatei
$ openshift start master --write-config = /openshift.local.config/master
Für die Knotenkonfigurationsdatei
$ oadm create-node-config --node-dir = /openshift.local.config/node-<node_hostname> --node = <node_hostname> --hostnames = <hostname>,<ip_address>
Sobald wir die folgenden Befehle ausführen, erhalten wir die Basiskonfigurationsdateien, die als Ausgangspunkt für die Konfiguration verwendet werden können. Später können wir dieselbe Datei haben, um die neuen Server zu starten.
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
Knotenkonfigurationsdateien
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
So sehen die Knotenkonfigurationsdateien aus. Sobald wir diese Konfigurationsdateien eingerichtet haben, können wir den folgenden Befehl ausführen, um einen Master- und einen Knotenserver zu erstellen.
$ openshift start --master-config = /openshift.local.config/master/master-
config.yaml --node-config = /openshift.local.config/node-<node_hostname>/node-
config.yaml
Knoten verwalten
In OpenShift haben wir das OC-Befehlszeilenprogramm, das hauptsächlich zum Ausführen aller Vorgänge in OpenShift verwendet wird. Wir können die folgenden Befehle verwenden, um die Knoten zu verwalten.
Zum Auflisten eines Knotens
$ 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
Beschreiben von Details zu einem Knoten
$ oc describe node <node name>
Knoten löschen
$ oc delete node <node name>
Auflisten von Pods auf einem Knoten
$ oadm manage-node <node1> <node2> --list-pods [--pod-selector=<pod_selector>] [-o json|yaml]
Pods auf einem Knoten auswerten
$ oadm manage-node <node1> <node2> --evacuate --dry-run [--pod-selector=<pod_selector>]
Konfigurationsauthentifizierung
In OpenShift Master gibt es einen integrierten OAuth-Server, der zum Verwalten der Authentifizierung verwendet werden kann. Alle OpenShift-Benutzer erhalten das Token von diesem Server, wodurch sie mit der OpenShift-API kommunizieren können.
In OpenShift gibt es verschiedene Arten von Authentifizierungsstufen, die zusammen mit der Hauptkonfigurationsdatei konfiguriert werden können.
- Alles erlauben
- Leugne alles
- HTPasswd
- LDAP
- Grundlegende Authentifizierung
- Header anfordern
Während wir die Hauptkonfiguration definieren, können wir die Identifikationsrichtlinie definieren, in der wir den Richtlinientyp definieren können, den wir verwenden möchten.
Alles erlauben
Alles erlauben
oauthConfig:
...
identityProviders:
- name: Allow_Authontication
challenge: true
login: true
provider:
apiVersion: v1
kind: AllowAllPasswordIdentityProvider
Alles verweigern
Dadurch wird der Zugriff auf alle Benutzernamen und Kennwörter verweigert.
oauthConfig:
...
identityProviders:
- name: deny_Authontication
challenge: true
login: true
provider:
apiVersion: v1
kind: DenyAllPasswordIdentityProvider
HTPasswd
HTPasswd wird verwendet, um den Benutzernamen und das Kennwort anhand eines verschlüsselten Dateikennworts zu überprüfen.
Befolgen Sie zum Generieren einer verschlüsselten Datei den folgenden Befehl.
$ htpasswd </path/to/users.htpasswd> <user_name>
Verwenden der verschlüsselten Datei.
oauthConfig:
...
identityProviders:
- name: htpasswd_authontication
challenge: true
login: true
provider:
apiVersion: v1
kind: HTPasswdPasswordIdentityProvider
file: /path/to/users.htpasswd
LDAP-Identitätsanbieter
Dies wird für die LDAP-Authentifizierung verwendet, bei der der LDAP-Server eine Schlüsselrolle bei der Authentifizierung spielt.
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"
Grundlegende Authentifizierung
Dies wird verwendet, wenn die Überprüfung von Benutzername und Kennwort anhand einer Server-zu-Server-Authentifizierung erfolgt. Die Authentifizierung ist in der Basis-URL geschützt und wird im JSON-Format angezeigt.
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
Konfigurieren eines Dienstkontos
Dienstkonten bieten eine flexible Möglichkeit, auf die OpenShift-API zuzugreifen und den Benutzernamen und das Kennwort für die Authentifizierung offenzulegen.
Aktivieren eines Dienstkontos
Das Dienstkonto verwendet ein Schlüsselpaar aus öffentlichem und privatem Schlüssel zur Authentifizierung. Die Authentifizierung bei der API erfolgt mithilfe eines privaten Schlüssels und dessen Validierung anhand eines öffentlichen Schlüssels.
ServiceAccountConfig:
...
masterCA: ca.crt
privateKeyFile: serviceaccounts.private.key
publicKeyFiles:
- serviceaccounts.public.key
- ...
Erstellen eines Dienstkontos
Verwenden Sie den folgenden Befehl, um ein Dienstkonto zu erstellen
$ Openshift cli create service account <name of server account>
Arbeiten mit HTTP-Proxy
In den meisten Produktionsumgebungen ist der direkte Zugriff auf das Internet eingeschränkt. Sie sind entweder nicht dem Internet ausgesetzt oder sie werden über einen HTTP- oder HTTPS-Proxy verfügbar gemacht. In einer OpenShift-Umgebung wird diese Proxy-Maschinendefinition als Umgebungsvariable festgelegt.
Dies kann durch Hinzufügen einer Proxy-Definition zu den Master- und Knotendateien unter erfolgen /etc/sysconfig. Dies ist ähnlich wie bei jeder anderen Anwendung.
Master Machine
/ etc / sysconfig / openshift-master
HTTP_PROXY=http://USERNAME:[email protected]:8080/
HTTPS_PROXY=https://USERNAME:[email protected]:8080/
NO_PROXY=master.vklnld908.int.example.com
Knotenmaschine
/ etc / sysconfig / openshift-node
HTTP_PROXY=http://USERNAME:[email protected]:8080/
HTTPS_PROXY=https://USERNAME:[email protected]:8080/
NO_PROXY=master.vklnld908.int.example.com
Sobald dies erledigt ist, müssen wir die Master- und Knotenmaschinen neu starten.
Für Docker Pull
/ etc / sysconfig / docker
HTTP_PROXY = http://USERNAME:[email protected]:8080/
HTTPS_PROXY = https://USERNAME:[email protected]:8080/
NO_PROXY = master.vklnld1446.int.example.com
Um einen Pod in einer Proxy-Umgebung auszuführen, können Sie Folgendes verwenden:
containers:
- env:
- name: "HTTP_PROXY"
value: "http://USER:PASSWORD@:10.0.1.1:8080"
Der OC-Umgebungsbefehl kann verwendet werden, um die vorhandene Umgebung zu aktualisieren.
OpenShift Storage mit NFS
In OpenShift bildet das Konzept des persistenten Volumens und der Ansprüche auf persistente Volumes einen persistenten Speicher. Dies ist eines der Schlüsselkonzepte, bei denen zuerst ein beständiges Volume erstellt wird und später dasselbe Volume beansprucht wird. Dazu benötigen wir genügend Kapazität und Speicherplatz auf der zugrunde liegenden Hardware.
apiVersion: v1
kind: PersistentVolume
metadata:
name: storage-unit1
spec:
capacity:
storage: 10Gi
accessModes:
- ReadWriteOnce
nfs:
path: /opt
server: 10.12.2.2
persistentVolumeReclaimPolicy: Recycle
Als Nächstes erstellen Sie mit dem Befehl OC create Persistent Volume.
$ oc create -f storage-unit1.yaml
persistentvolume " storage-unit1 " created
Das erstellte Volume beanspruchen.
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: Storage-clame1
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 5Gi
Erstellen Sie den Anspruch.
$ oc create -f Storage-claim1.yaml
persistentvolume " Storage-clame1 " created
Benutzer- und Rollenverwaltung
Die Benutzer- und Rollenverwaltung wird verwendet, um Benutzer, deren Zugriff und Steuerelemente für verschiedene Projekte zu verwalten.
Benutzer erstellen
Mit vordefinierten Vorlagen können neue Benutzer in OpenShift erstellt werden.
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}"
Verwenden Sie oc create –f <Dateiname>, um Benutzer zu erstellen.
$ oc create –f vipin.yaml
Verwenden Sie den folgenden Befehl, um einen Benutzer in OpenShift zu löschen.
$ oc delete user <user name>
Benutzerzugriff einschränken
ResourceQuotas und LimitRanges werden zum Begrenzen der Benutzerzugriffsebenen verwendet. Sie werden zum Begrenzen der Pods und Container im Cluster verwendet.
apiVersion: v1
kind: ResourceQuota
metadata:
name: resources-utilization
spec:
hard:
pods: "10"
Erstellen des Angebots mit der obigen Konfiguration
$ oc create -f resource-quota.yaml –n –Openshift-sample
Beschreiben des Ressourcenangebots
$ oc describe quota resource-quota -n Openshift-sample
Name: resource-quota
Namespace: Openshift-sample
Resource Used Hard
-------- ---- ----
pods 3 10
Das Definieren der Containerlimits kann zum Begrenzen der Ressourcen verwendet werden, die von bereitgestellten Containern verwendet werden sollen. Sie werden verwendet, um die maximalen und minimalen Einschränkungen bestimmter Objekte zu definieren.
Einschränkungen des Benutzerprojekts
Dies wird im Wesentlichen für die Anzahl der Projekte verwendet, die ein Benutzer zu einem beliebigen Zeitpunkt haben kann. Sie werden im Wesentlichen durch Definieren der Benutzerebenen in den Kategorien Bronze, Silber und Gold durchgeführt.
Wir müssen zuerst ein Objekt definieren, das den Wert der Anzahl der Projekte enthält, die eine Bronze-, Silber- und Goldkategorie haben kann. Diese müssen in der Datei master-confif.yaml erfolgen.
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
Starten Sie den Master-Server neu.
Zuweisen eines Benutzers zu einer bestimmten Ebene.
$ oc label user vipin level = gold
Entfernen Sie den Benutzer bei Bedarf aus dem Etikett.
$ oc label user <user_name> level-
Hinzufügen von Rollen zu einem Benutzer.
$ oadm policy add-role-to-user <user_name>
Entfernen der Rolle von einem Benutzer.
$ oadm policy remove-role-from-user <user_name>
Hinzufügen einer Clusterrolle zu einem Benutzer.
$ oadm policy add-cluster-role-to-user <user_name>
Entfernen einer Clusterrolle von einem Benutzer.
$ oadm policy remove-cluster-role-from-user <user_name>
Hinzufügen einer Rolle zu einer Gruppe.
$ oadm policy add-role-to-user <user_name>
Entfernen einer Rolle aus einer Gruppe.
$ oadm policy remove-cluster-role-from-user <user_name>
Hinzufügen einer Clusterrolle zu einer Gruppe.
$ oadm policy add-cluster-role-to-group <groupname>
Entfernen einer Clusterrolle aus einer Gruppe.
$ oadm policy remove-cluster-role-from-group <role> <groupname>
Benutzer für die Clusterverwaltung
Dies ist eine der leistungsstärksten Rollen, in denen der Benutzer einen vollständigen Cluster von der Erstellung bis zum Löschen eines Clusters verwalten kann.
$ oadm policy add-role-to-user admin <user_name> -n <project_name>
Benutzer mit ultimativer Leistung
$ oadm policy add-cluster-role-to-user cluster-admin <user_name>