OpenShift - Administracja
W tym rozdziale zajmiemy się takimi tematami, jak zarządzanie węzłem, konfigurowanie konta usługi itp.
Konfiguracja nadrzędna i węzłowa
W OpenShift musimy użyć polecenia start wraz z OC, aby uruchomić nowy serwer. Podczas uruchamiania nowego mastera musimy użyć mastera wraz z poleceniem start, natomiast podczas uruchamiania nowego węzła musimy użyć node wraz z poleceniem start. Aby to zrobić, musimy utworzyć pliki konfiguracyjne zarówno dla mastera, jak i dla węzłów. Możemy utworzyć podstawowy plik konfiguracyjny dla mastera i węzła za pomocą następującego polecenia.
Dla głównego pliku konfiguracyjnego
$ openshift start master --write-config = /openshift.local.config/master
Plik konfiguracyjny węzła
$ oadm create-node-config --node-dir = /openshift.local.config/node-<node_hostname> --node = <node_hostname> --hostnames = <hostname>,<ip_address>
Po uruchomieniu następujących poleceń otrzymamy podstawowe pliki konfiguracyjne, których można użyć jako punktu wyjścia do konfiguracji. Później możemy mieć ten sam plik, aby uruchomić nowe serwery.
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
Pliki konfiguracyjne węzła
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
Tak wyglądają pliki konfiguracyjne węzła. Gdy mamy już te pliki konfiguracyjne, możemy uruchomić następujące polecenie, aby utworzyć serwer główny i węzłowy.
$ openshift start --master-config = /openshift.local.config/master/master-
config.yaml --node-config = /openshift.local.config/node-<node_hostname>/node-
config.yaml
Zarządzanie węzłami
W OpenShift mamy narzędzie wiersza poleceń OC, które jest najczęściej używane do wykonywania wszystkich operacji w OpenShift. Do zarządzania węzłami możemy użyć następujących poleceń.
Aby wyświetlić węzeł
$ 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
Opisywanie szczegółów dotyczących węzła
$ oc describe node <node name>
Usuwanie węzła
$ oc delete node <node name>
Wyświetlanie podów w węźle
$ oadm manage-node <node1> <node2> --list-pods [--pod-selector=<pod_selector>] [-o json|yaml]
Ocenianie podów w węźle
$ oadm manage-node <node1> <node2> --evacuate --dry-run [--pod-selector=<pod_selector>]
Uwierzytelnianie konfiguracji
W OpenShift master jest wbudowany serwer OAuth, który może służyć do zarządzania uwierzytelnianiem. Wszyscy użytkownicy OpenShift otrzymują token z tego serwera, który pomaga im komunikować się z OpenShift API.
W OpenShift istnieją różne rodzaje poziomów uwierzytelniania, które można skonfigurować wraz z głównym plikiem konfiguracyjnym.
- Pozwól wszystkim
- Zaprzeczać wszystkiemu
- HTPasswd
- LDAP
- Uwierzytelnianie podstawowe
- Żądanie nagłówka
Definiując konfigurację nadrzędną, możemy zdefiniować politykę identyfikacji, w której możemy zdefiniować typ polityki, której chcemy używać.
Pozwól wszystkim
Pozwól wszystkim
oauthConfig:
...
identityProviders:
- name: Allow_Authontication
challenge: true
login: true
provider:
apiVersion: v1
kind: AllowAllPasswordIdentityProvider
Zaprzeczać wszystkiemu
Spowoduje to odmowę dostępu do wszystkich nazw użytkowników i haseł.
oauthConfig:
...
identityProviders:
- name: deny_Authontication
challenge: true
login: true
provider:
apiVersion: v1
kind: DenyAllPasswordIdentityProvider
HTPasswd
HTPasswd służy do sprawdzania nazwy użytkownika i hasła w odniesieniu do zaszyfrowanego hasła do pliku.
Aby wygenerować zaszyfrowany plik, wykonaj następujące polecenie.
$ htpasswd </path/to/users.htpasswd> <user_name>
Korzystanie z zaszyfrowanego pliku.
oauthConfig:
...
identityProviders:
- name: htpasswd_authontication
challenge: true
login: true
provider:
apiVersion: v1
kind: HTPasswdPasswordIdentityProvider
file: /path/to/users.htpasswd
Dostawca tożsamości LDAP
Służy do uwierzytelniania LDAP, w którym serwer LDAP odgrywa kluczową rolę w uwierzytelnianiu.
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"
Uwierzytelnianie podstawowe
Jest to używane, gdy weryfikacja nazwy użytkownika i hasła jest wykonywana w odniesieniu do uwierzytelniania między serwerami. Uwierzytelnienie jest chronione w podstawowym adresie URL i prezentowane w formacie 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
Konfigurowanie konta usługi
Konta usług zapewniają elastyczny sposób uzyskiwania dostępu do interfejsu API OpenShift, ujawniając nazwę użytkownika i hasło w celu uwierzytelnienia.
Włączanie konta usługi
Konto usługi używa pary kluczy publicznego i prywatnego do uwierzytelniania. Uwierzytelnianie w interfejsie API odbywa się za pomocą klucza prywatnego i weryfikuje go z kluczem publicznym.
ServiceAccountConfig:
...
masterCA: ca.crt
privateKeyFile: serviceaccounts.private.key
publicKeyFiles:
- serviceaccounts.public.key
- ...
Tworzenie konta usługi
Użyj następującego polecenia, aby utworzyć konto usługi
$ Openshift cli create service account <name of server account>
Praca z proxy HTTP
W większości środowisk produkcyjnych bezpośredni dostęp do Internetu jest ograniczony. Nie są one ujawniane w Internecie lub przez serwer proxy HTTP lub HTTPS. W środowisku OpenShift ta definicja maszyny proxy jest ustawiana jako zmienna środowiskowa.
Można to zrobić, dodając definicję proxy do plików głównych i węzłów znajdujących się w /etc/sysconfig. Jest to podobne, jak w przypadku każdej innej aplikacji.
Mistrzowska maszyna
/ 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
Maszyna węzłowa
/ 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
Po zakończeniu musimy zrestartować maszyny główne i węzłowe.
Dla 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
Aby uruchomić kapsułę w środowisku proxy, można to zrobić za pomocą -
containers:
- env:
- name: "HTTP_PROXY"
value: "http://USER:PASSWORD@:10.0.1.1:8080"
Polecenie OC environment może być użyte do zaktualizowania istniejącego env.
Pamięć OpenShift z NFS
W OpenShift koncepcja trwałego woluminu i trwałego oświadczenia woluminu tworzy trwały magazyn. Jest to jedna z kluczowych koncepcji, w której tworzony jest pierwszy trwały wolumin, a później ten sam wolumin jest zajmowany. W tym celu musimy mieć wystarczającą pojemność i miejsce na dysku na podstawowym sprzęcie.
apiVersion: v1
kind: PersistentVolume
metadata:
name: storage-unit1
spec:
capacity:
storage: 10Gi
accessModes:
- ReadWriteOnce
nfs:
path: /opt
server: 10.12.2.2
persistentVolumeReclaimPolicy: Recycle
Następnie za pomocą polecenia OC create utwórz trwały wolumin.
$ oc create -f storage-unit1.yaml
persistentvolume " storage-unit1 " created
Odbieranie utworzonego wolumenu.
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: Storage-clame1
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 5Gi
Utwórz roszczenie.
$ oc create -f Storage-claim1.yaml
persistentvolume " Storage-clame1 " created
Zarządzanie użytkownikami i rolami
Administracja użytkownikami i rolami służy do zarządzania użytkownikami, ich dostępem i kontrolą w różnych projektach.
Tworzenie użytkownika
Do tworzenia nowych użytkowników w OpenShift można użyć predefiniowanych szablonów.
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}"
Użyj oc create –f <nazwa pliku>, aby utworzyć użytkowników.
$ oc create –f vipin.yaml
Użyj następującego polecenia, aby usunąć użytkownika w OpenShift.
$ oc delete user <user name>
Ograniczanie dostępu użytkowników
ResourceQuotas i LimitRanges służą do ograniczania poziomów dostępu użytkowników. Służą do ograniczania zasobników i kontenerów w klastrze.
apiVersion: v1
kind: ResourceQuota
metadata:
name: resources-utilization
spec:
hard:
pods: "10"
Tworzenie oferty przy użyciu powyższej konfiguracji
$ oc create -f resource-quota.yaml –n –Openshift-sample
Opisywanie oferty zasobów
$ oc describe quota resource-quota -n Openshift-sample
Name: resource-quota
Namespace: Openshift-sample
Resource Used Hard
-------- ---- ----
pods 3 10
Definiowanie limitów kontenerów może posłużyć do ograniczenia zasobów, które będą używane przez wdrożone kontenery. Służą do definiowania maksymalnych i minimalnych ograniczeń niektórych obiektów.
Ograniczenia projektu użytkownika
Jest to zasadniczo używane do liczby projektów, które użytkownik może mieć w dowolnym momencie. Zasadniczo odbywa się to poprzez zdefiniowanie poziomów użytkowników w kategoriach brązu, srebra i złota.
Najpierw musimy zdefiniować obiekt, który ma wartość tego, ile projektów może mieć kategoria brązowa, srebrna i złota. Należy to zrobić w pliku 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
Zrestartuj serwer główny.
Przypisanie użytkownika do określonego poziomu.
$ oc label user vipin level = gold
W razie potrzeby przeniesienie użytkownika z etykiety.
$ oc label user <user_name> level-
Dodawanie ról do użytkownika.
$ oadm policy add-role-to-user
<user_name>
Usunięcie roli użytkownika.
$ oadm policy remove-role-from-user
<user_name>
Dodanie roli klastra do użytkownika.
$ oadm policy add-cluster-role-to-user
<user_name>
Usuwanie roli klastra od użytkownika.
$ oadm policy remove-cluster-role-from-user
<user_name>
Dodawanie roli do grupy.
$ oadm policy add-role-to-user
<user_name>
Usuwanie roli z grupy.
$ oadm policy remove-cluster-role-from-user
<user_name>
Dodawanie roli klastra do grupy.
$ oadm policy add-cluster-role-to-group
<groupname>
Usuwanie roli klastra z grupy.
$ oadm policy remove-cluster-role-from-group <role> <groupname>
Użytkownik do administrowania klastrem
Jest to jedna z najpotężniejszych ról, w której użytkownik ma możliwość zarządzania całym klastrem, począwszy od utworzenia, aż do usunięcia klastra.
$ oadm policy add-role-to-user admin <user_name> -n <project_name>
Użytkownik z najwyższą mocą
$ oadm policy add-cluster-role-to-user cluster-admin <user_name>