- OpenShift 教程
- OpenShift - 首頁
- OpenShift - 概述
- OpenShift - 型別
- OpenShift - 架構
- OpenShift - 環境設定
- OpenShift - 基本概念
- OpenShift - 快速入門
- OpenShift - 自動構建
- OpenShift - 命令列介面 (CLI)
- OpenShift - CLI 操作
- OpenShift - 叢集
- OpenShift - 應用伸縮
- OpenShift - 管理
- OpenShift - Docker 和 Kubernetes
- OpenShift - 安全
- OpenShift 有用資源
- OpenShift - 快速指南
- OpenShift - 有用資源
- OpenShift - 討論
OpenShift - 管理
本章將涵蓋如何管理節點、配置服務帳戶等主題。
主節點和節點配置
在 OpenShift 中,我們需要使用 `start` 命令以及 `oc` 來啟動新的伺服器。啟動新的主節點時,需要使用 `master` 以及 `start` 命令,而啟動新的節點時,需要使用 `node` 以及 `start` 命令。為此,我們需要為主節點和節點建立配置檔案。我們可以使用以下命令建立主節點和節點的基本配置檔案。
主節點配置檔案
$ 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>
列出節點上的 Pod
$ oadm manage-node <node1> <node2> --list-pods [--pod-selector=<pod_selector>] [-o json|yaml]
評估節點上的 Pod
$ 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"
基本身份驗證
當對伺服器到伺服器身份驗證進行使用者名稱和密碼驗證時使用此方法。身份驗證受 base 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
配置服務帳戶
服務帳戶提供了一種靈活的方式來訪問 OpenShift API,公開使用者名稱和密碼以進行身份驗證。
啟用服務帳戶
服務帳戶使用公鑰和私鑰對進行身份驗證。對 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 環境中,此代理機器定義被設定為環境變數。
這可以透過在位於 `/etc/sysconfig` 下的主節點和節點檔案中新增代理定義來完成。這與我們對任何其他應用程式所做的類似。
主節點機器
/etc/sysconfig/openshift-master
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
節點機器
/etc/sysconfig/openshift-node
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 拉取
/etc/sysconfig/docker
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
為了使 Pod 在代理環境中執行,可以使用 -
containers:
- env:
- name: "HTTP_PROXY"
value: "http://USER:PASSWORD@:10.0.1.1:8080"
`oc env` 命令可用於更新現有環境變數。
使用 NFS 的 OpenShift 儲存
在 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 用於限制使用者訪問級別。它們用於限制叢集上的 Pod 和容器。
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>
叢集管理員使用者
這是最強大的角色之一,使用者能夠管理整個叢集,從建立到刪除叢集。
$ oadm policy add-role-to-user admin <user_name> -n <project_name>
擁有最終許可權的使用者
$ oadm policy add-cluster-role-to-user cluster-admin <user_name>