OpenShift - Quản trị

Trong chương này, chúng ta sẽ đề cập đến các chủ đề như cách quản lý một nút, cấu hình tài khoản dịch vụ, v.v.

Cấu hình chính và nút

Trong OpenShift, chúng ta cần sử dụng lệnh start cùng với OC để khởi động một máy chủ mới. Trong khi khởi chạy một cái chính mới, chúng ta cần sử dụng cái chính cùng với lệnh bắt đầu, trong khi khi khởi động nút mới, chúng ta cần sử dụng nút cùng với lệnh bắt đầu. Để làm được điều này, chúng ta cần tạo các tệp cấu hình cho cái chính cũng như cho các nút. Chúng ta có thể tạo tệp cấu hình cơ bản cho nút chính và nút bằng lệnh sau.

Đối với tệp cấu hình chính

$ openshift start master --write-config = /openshift.local.config/master

Đối với tệp cấu hình nút

$ oadm create-node-config --node-dir = /openshift.local.config/node-<node_hostname> --node = <node_hostname> --hostnames = <hostname>,<ip_address>

Khi chúng tôi chạy các lệnh sau, chúng tôi sẽ nhận được các tệp cấu hình cơ sở có thể được sử dụng làm điểm bắt đầu cho cấu hình. Sau đó, chúng ta có thể có cùng một tệp để khởi động các máy chủ mới.

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

Tệp cấu hình nút

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

Đây là cách các tệp cấu hình nút trông như thế nào. Khi chúng ta đã có các tệp cấu hình này, chúng ta có thể chạy lệnh sau để tạo máy chủ chính và máy chủ nút.

$ openshift start --master-config = /openshift.local.config/master/master-
config.yaml --node-config = /openshift.local.config/node-<node_hostname>/node-
config.yaml

Quản lý các nút

Trong OpenShift, chúng tôi có tiện ích dòng lệnh OC, tiện ích này chủ yếu được sử dụng để thực hiện tất cả các hoạt động trong OpenShift. Chúng ta có thể sử dụng các lệnh sau để quản lý các nút.

Để liệt kê một nút

$ 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

Mô tả chi tiết về một nút

$ oc describe node <node name>

Xóa một nút

$ oc delete node <node name>

Liệt kê các nhóm trên một nút

$ oadm manage-node <node1> <node2> --list-pods [--pod-selector=<pod_selector>] [-o json|yaml]

Đánh giá nhóm trên một nút

$ oadm manage-node <node1> <node2> --evacuate --dry-run [--pod-selector=<pod_selector>]

Xác thực cấu hình

Trong OpenShift master, có một máy chủ OAuth tích hợp, có thể được sử dụng để quản lý xác thực. Tất cả người dùng OpenShift đều nhận được mã thông báo từ máy chủ này, giúp họ giao tiếp với API OpenShift.

Có nhiều loại cấp độ xác thực khác nhau trong OpenShift, có thể được định cấu hình cùng với tệp cấu hình chính.

  • Chấp nhận tất cả
  • Phủ nhận tất cả
  • HTPasswd
  • LDAP
  • Xác thực cơ bản
  • Yêu cầu tiêu đề

Trong khi xác định cấu hình chính, chúng ta có thể xác định chính sách nhận dạng nơi chúng ta có thể xác định loại chính sách mà chúng ta muốn sử dụng.

Chấp nhận tất cả

Chấp nhận tất cả

oauthConfig:
   ...
   identityProviders:
   - name: Allow_Authontication
      challenge: true
      login: true
      provider:
         apiVersion: v1
         kind: AllowAllPasswordIdentityProvider

Phủ nhận tất cả

Điều này sẽ từ chối quyền truy cập vào tất cả tên người dùng và mật khẩu.

oauthConfig:
   ...
   identityProviders:
   - name: deny_Authontication
      challenge: true
      login: true
      provider:
         apiVersion: v1
         kind: DenyAllPasswordIdentityProvider

HTPasswd

HTPasswd được sử dụng để xác thực tên người dùng và mật khẩu so với mật khẩu tệp được mã hóa.

Để tạo một tệp được mã hóa, sau đây là lệnh.

$ htpasswd </path/to/users.htpasswd> <user_name>

Sử dụng tệp được mã hóa.

oauthConfig:
   ...
   identityProviders:
   - name: htpasswd_authontication
      challenge: true
      login: true
      provider:
         apiVersion: v1
         kind: HTPasswdPasswordIdentityProvider
         file: /path/to/users.htpasswd

Nhà cung cấp danh tính LDAP

Điều này được sử dụng để xác thực LDAP trong đó máy chủ LDAP đóng một vai trò quan trọng trong xác thực.

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"

Xác thực cơ bản

Điều này được sử dụng khi xác thực tên người dùng và mật khẩu được thực hiện dựa trên xác thực từ máy chủ đến máy chủ. Xác thực được bảo vệ trong URL cơ sở và được trình bày ở định dạng 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

Định cấu hình tài khoản dịch vụ

Tài khoản dịch vụ cung cấp một cách linh hoạt để truy cập API OpenShift, làm lộ tên người dùng và mật khẩu để xác thực.

Kích hoạt tài khoản dịch vụ

Tài khoản dịch vụ sử dụng một cặp khóa công khai và khóa riêng tư để xác thực. Xác thực đối với API được thực hiện bằng cách sử dụng khóa riêng tư và xác thực nó dựa trên khóa công khai.

ServiceAccountConfig:
   ...
   masterCA: ca.crt
   privateKeyFile: serviceaccounts.private.key
   publicKeyFiles:
   - serviceaccounts.public.key
   - ...

Tạo tài khoản dịch vụ

Sử dụng lệnh sau để tạo tài khoản dịch vụ

$ Openshift cli create service account <name of server account>

Làm việc với HTTP Proxy

Trong hầu hết các môi trường sản xuất, truy cập trực tiếp vào Internet bị hạn chế. Chúng không được tiếp xúc với Internet hoặc chúng được hiển thị qua proxy HTTP hoặc HTTPS. Trong môi trường OpenShift, định nghĩa máy proxy này được đặt làm biến môi trường.

Điều này có thể được thực hiện bằng cách thêm định nghĩa proxy trên tệp chính và tệp nút nằm dưới /etc/sysconfig. Điều này tương tự như chúng tôi làm cho bất kỳ ứng dụng nào khác.

Máy chủ

/ 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

Máy nút

/ 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

Sau khi thực hiện xong, chúng ta cần khởi động lại máy chủ và máy nút.

Đối với 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

Để làm cho một nhóm chạy trong môi trường proxy, nó có thể được thực hiện bằng cách sử dụng:

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

Lệnh môi trường OC có thể được sử dụng để cập nhật env hiện có.

OpenShift Storage với NFS

Trong OpenShift, khái niệm khối lượng liên tục và yêu cầu khối lượng liên tục tạo thành bộ nhớ liên tục. Đây là một trong những khái niệm quan trọng trong đó tập liên tục đầu tiên được tạo ra và sau đó, tập tương tự được xác nhận. Đối với điều này, chúng ta cần có đủ dung lượng và không gian đĩa trên phần cứng bên dưới.

apiVersion: v1
kind: PersistentVolume
metadata:
   name: storage-unit1
spec:
   capacity:
      storage: 10Gi
   accessModes:
   - ReadWriteOnce
   nfs:
      path: /opt
      server: 10.12.2.2
   persistentVolumeReclaimPolicy: Recycle

Tiếp theo, sử dụng lệnh OC create tạo Ổ đĩa liên tục.

$ oc create -f storage-unit1.yaml

persistentvolume " storage-unit1 " created

Yêu cầu khối lượng đã tạo.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
   name: Storage-clame1
spec:
   accessModes:
      - ReadWriteOnce
   resources:
      requests:
         storage: 5Gi

Tạo xác nhận quyền sở hữu.

$ oc create -f Storage-claim1.yaml
persistentvolume " Storage-clame1 " created

Quản lý Người dùng và Vai trò

Quản trị người dùng và vai trò được sử dụng để quản lý người dùng, quyền truy cập và kiểm soát của họ trên các dự án khác nhau.

Tạo người dùng

Các mẫu được xác định trước có thể được sử dụng để tạo người dùng mới trong 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}"

Sử dụng oc create –f <tên tệp> để tạo người dùng.

$ oc create –f vipin.yaml

Sử dụng lệnh sau để xóa người dùng trong OpenShift.

$ oc delete user <user name>

Giới hạn quyền truy cập của người dùng

ResourceQuotas và LimitRanges được sử dụng để giới hạn mức độ truy cập của người dùng. Chúng được sử dụng để giới hạn các vỏ và thùng chứa trên cụm.

apiVersion: v1
kind: ResourceQuota
metadata:
   name: resources-utilization
spec:
   hard:
      pods: "10"

Tạo báo giá bằng cách sử dụng cấu hình trên

$ oc create -f resource-quota.yaml –n –Openshift-sample

Mô tả báo giá tài nguyên

$ oc describe quota resource-quota  -n  Openshift-sample
Name:              resource-quota
Namespace:                              Openshift-sample
Resource           Used                  Hard
--------           ----                  ----
pods                3                    10

Việc xác định giới hạn vùng chứa có thể được sử dụng để giới hạn tài nguyên sẽ được sử dụng bởi các vùng chứa đã triển khai. Chúng được sử dụng để xác định giới hạn tối đa và tối thiểu của các đối tượng nhất định.

Giới hạn dự án của người dùng

Điều này về cơ bản được sử dụng cho số lượng dự án mà người dùng có thể có tại bất kỳ thời điểm nào. Về cơ bản, chúng được thực hiện bằng cách xác định cấp độ người dùng trong các danh mục đồng, bạc và vàng.

Đầu tiên chúng ta cần xác định một đối tượng có giá trị bằng bao nhiêu dự án mà một loại đồng, bạc và vàng có thể có. Chúng cần được thực hiện trong tệp 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

Khởi động lại máy chủ chính.

Chỉ định người dùng cho một cấp cụ thể.

$ oc label user vipin level = gold

Di chuyển người dùng ra khỏi nhãn, nếu được yêu cầu.

$ oc label user <user_name> level-

Thêm vai trò cho người dùng.

$ oadm policy add-role-to-user 
      
        <user_name> 
      

Xóa vai trò khỏi người dùng.

$ oadm policy remove-role-from-user 
      
        <user_name> 
      

Thêm vai trò cụm cho người dùng.

$ oadm policy add-cluster-role-to-user 
      
        <user_name> 
      

Xóa vai trò cụm khỏi người dùng.

$ oadm policy remove-cluster-role-from-user 
      
        <user_name> 
      

Thêm một vai trò vào một nhóm.

$ oadm policy add-role-to-user 
      
        <user_name> 
      

Xóa vai trò khỏi nhóm.

$ oadm policy remove-cluster-role-from-user 
      
        <user_name> 
      

Thêm vai trò cụm vào nhóm.

$ oadm policy add-cluster-role-to-group 
      
        <groupname> 
      

Xóa vai trò cụm khỏi một nhóm.

$ oadm policy remove-cluster-role-from-group <role> <groupname>

Người dùng quản trị cụm

Đây là một trong những vai trò mạnh mẽ nhất mà người dùng có khả năng quản lý một cụm hoàn chỉnh bắt đầu từ khi tạo cho đến khi xóa một cụm.

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

Người dùng có sức mạnh tối thượng

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