OpenShift - การดูแลระบบ

ในบทนี้เราจะพูดถึงหัวข้อต่างๆเช่นวิธีจัดการโหนดกำหนดค่าบัญชีบริการเป็นต้น

การกำหนดค่าหลักและโหนด

ใน OpenShift เราจำเป็นต้องใช้คำสั่ง start พร้อมกับ OC เพื่อบูตเซิร์ฟเวอร์ใหม่ ในขณะที่เปิดตัวต้นแบบใหม่เราจำเป็นต้องใช้ต้นแบบพร้อมกับคำสั่ง 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 เรามียูทิลิตี้บรรทัดคำสั่ง 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>

รายการพ็อดบนโหนด

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

Configuration Authentication

ใน OpenShift master มีเซิร์ฟเวอร์ 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"

การรับรองความถูกต้องขั้นพื้นฐาน

ใช้เมื่อทำการตรวจสอบความถูกต้องของชื่อผู้ใช้และรหัสผ่านเทียบกับการรับรองความถูกต้องแบบเซิร์ฟเวอร์ต่อเซิร์ฟเวอร์ การพิสูจน์ตัวตนได้รับการป้องกันใน 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 Proxy

ในสภาพแวดล้อมการผลิตส่วนใหญ่การเข้าถึงอินเทอร์เน็ตโดยตรงจะถูก จำกัด พวกเขาไม่ได้สัมผัสกับอินเทอร์เน็ตหรือเปิดเผยผ่านพร็อกซี 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 / นักเทียบท่า

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 ที่มีอยู่

OpenShift Storage พร้อม NFS

ใน 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 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 <file name> เพื่อสร้างผู้ใช้

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

ผู้ใช้สำหรับการดูแลคลัสเตอร์

นี่เป็นหนึ่งในบทบาทที่ทรงพลังที่สุดที่ผู้ใช้มีความสามารถในการจัดการคลัสเตอร์ที่สมบูรณ์ตั้งแต่การสร้างจนถึงการลบคลัสเตอร์

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

ผู้ใช้ที่มีพลังสูงสุด

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