Openshift-administration

提供：Dev Guides
移動先:案内、検索

OpenShift-管理

この章では、ノードの管理方法、サービスアカウントの構成方法などのトピックを扱います。

マスターとノードの構成

OpenShiftでは、OCとともにstartコマンドを使用して新しいサーバーを起動する必要があります。 新しいマスターを起動するときは、startコマンドとともにマスターを使用する必要がありますが、新しいノードを起動するときには、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には、主にOpenShiftのすべての操作を実行するために使用されるOCコマンドラインユーティリティがあります。 次のコマンドを使用して、ノードを管理できます。

ノードをリストするため

$ 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 IDプロバイダー

これは、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

サービスアカウントの構成

サービスアカウントは、認証用のユーザー名とパスワードを公開する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 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

プロキシ環境でポッドを実行するために、それを使用して行うことができます- 

containers:
- env:
   - name: "HTTP_PROXY"
      value: "http://USER:PASSWORD@:10.0.1.1:8080"

OC環境コマンドを使用して、既存のenvを更新できます。

NFSを使用したOpenShift Storage

OpenShiftでは、永続ボリュームと永続ボリュームクレームの概念が永続ストレージを形成します。 これは、最初の永続ボリュームが作成され、後で同じボリュームが要求される重要な概念の1つです。 そのためには、基盤となるハードウェアに十分な容量とディスク容量が必要です。 

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コマンドcreate Persistent Volumeを使用します。 

$ 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>

クラスター管理のユーザー

これは、ユーザーがクラスターの作成から削除までの完全なクラスターを管理できる最も強力な役割の1つです。 

$ oadm policy add-role-to-user admin <user_name> -n <project_name>

究極のパワーを持つユーザー

$ oadm policy add-cluster-role-to-user cluster-admin <user_name>
「https://www.finddevguides.com/index.php?title=Openshift-administration&oldid=25953」から取得
Powered by MediaWiki