- 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:[email protected]:8080/ HTTPS_PROXY=https://USERNAME:[email protected]:8080/ NO_PROXY=master.vklnld908.int.example.com
节点机器
/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
完成后,我们需要重新启动主节点和节点机器。
对于 Docker 拉取
/etc/sysconfig/docker
HTTP_PROXY = http://USERNAME:[email protected]:8080/ HTTPS_PROXY = https://USERNAME:[email protected]: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>