捕鱼机前级不工作

書名： OpenShift在企業中的實踐：PaaS DevOps微服務（第2版）
作者名：魏新宇郭躍軍
本章字數： 6941字
更新時間： 2021-11-05 10:17:19

3.2.4　OpenShift部署后的配置

本小節將介紹OCP4安裝后的配置步驟。需要注意幾點：

1.OCP4的監控組件是自動安裝的，但需要為ES配置一個PV（PVC自動創建、手工創建對應的PV后，PVC和PV會自動綁定），以便時間監控數據的持久化。

2.OCP4.6開始支持AlertManager規則的自定義和告警日志的郵件轉發。這部分內容請參考Repo中的“自定義Prometheus規則并觸發郵件告警”。

3.為了實現S2I構建鏡像的持久化，需要為Image Registry增加持久化存儲，這部分內容請參考Repo中的“Image Registry增加持久化存儲”。

1.OpenShift配置登錄認證

在OpenShift集群部署完畢后，默認提供兩種集群管理員權限身份驗證的方法：

·使用kubeconfig文件登錄，這個文件中包含一個永不過期的X.509 client certificate。

·使用被賦予了OAuth access token的kubeadmin虛擬用戶和密碼登錄。

kubeconfig文件是在安裝過程中創建的，它存儲在OpenShift安裝程序在安裝過程中創建的auth目錄中。該文件包含X.509證書。

我們需要設定kubeconfig文件的環境變量，然后就可以訪問集群，如圖3-24所示。

如果其他終端要通過kubeconfig文件訪問OpenShift集群，必須將kubeconfig文件復制到這個終端，并且這個終端需要有OC客戶端。通過kubeconfig文件只能執行命令行終端，無法登錄WebConsole界面。

圖3-24　設定kubeconfig文件的環境變量

OpenShift安裝完成后會自動創建kubeadmin用戶。kubeadmin被硬編碼為集群管理員（權限不能被修改）。kubeadmin password是由安裝程序動態生成的唯一的密碼，這個密碼會顯示在安裝日志中，通過這個用戶名和密碼可以登錄命令行終端（oc login）和OpenShift WebConsole界面，如圖3-25所示。

圖3-25　使用kubeadmin登錄OpenShift WebConsole界面

接下來，我們介紹如何配置Identity Provider。

（1）配置HTPasswd認證方式

在開發測試環境，我們可以配置HTPasswd認證方式。

創建一個admin用戶，密碼也指定為admin。

# htpasswd -cBb /root/users.htpasswd admin admin
Adding password for user admin

接下來創建OpenShift的secret，htpasswd_provider。

# oc create secret generic htpass-secret --from-file=htpasswd=/root/users.
    htpasswd -n openshift-config
secret/htpass-secret created

創建OAuth資源對象文件。

# cat << EOF > htpass.yaml
apiVersion: config.openshift.io/v1
kind: OAuth
metadata:
  name: cluster
spec:
  identityProviders:
  - name: my_htpasswd_provider
    mappingMethod: claim
    type: HTPasswd
    htpasswd:
      fileData:
        name: htpass-secret
EOF

應用到集群中。

# oc apply -f htpass.yaml
oauth.config.openshift.io/cluster configured

接下來，為admin用戶授權，例如賦予cluster-admin role。

# oc adm policy add-cluster-role-to-user cluster-admin admin
clusterrole.rbac.authorization.k8s.io/cluster-admin added: "admin"

然后，再度訪問OpenShift WebConsole，現在就可以選擇htpasswd provider的認證方式登錄了，如圖3-26所示。

圖3-26　查看OpenShift WebConsole增加的認證方式

OpenShift安裝后默認的kubeadmin用戶，生產環境建議將其刪除，但一定要在創建了有cluster-admin角色的用戶以后再刪除。

# oc delete secret kubeadmin -n kube-system

如果在使用集群管理員特權配置另一個用戶（如admin用戶）之前刪除kubeadmin，則管理集群的唯一方法是使用kubeconfig文件。如果沒有安裝過程生成的kubeconfig文件的副本，則無法恢復對集群的管理訪問，唯一的選擇是銷毀并重新安裝集群。

（2）增加和刪除HTPasswd認證用戶

如果我們想添加一個user1用戶，該怎么操作？

首先在HTPasswd用戶名密碼文件中增加新條目。

# htpasswd -b /root/users.htpasswd user1 passwd
Adding password for user user1

然后更新OpenShift中的secret。

# oc set data secret/htpass-secret --from-file htpasswd=/root/users.htpasswd -n 
    openshift-config
secret/htpass-secret data updated

觀察authentication Pod，會自動重新部署，如圖3-27所示。

# watch oc get pods -n openshift-authentication

圖3-27　authentication Pod重新部署

authentication Pod重新部署成功后，使用如下命令確認user1用戶可以成功登錄OpenShift集群。

# oc login https://api.weixinyucluster.bluecat.ltd:6443 -u user1 -p passwd

接下來，我們展示如何刪除HTPasswd認證的用戶，以user1為例。

首先將user1從認證文件中刪除。

# htpasswd -D /root/users.htpasswd user1
Deleting password for user user1

更新OpenShift中的secret。

# oc set data secret/htpass-secret --from-file htpasswd=/root/users.htpasswd -n 
    openshift-config
secret/htpass-secret data updated

使用以下命令刪除用戶相關資源。

# oc delete user user1
user.user.openshift.io "user1" deleted
# oc delete identity my_htpasswd_provider:user1
identity.user.openshift.io "my_htpasswd_provider:user1" deleted

（3）獲取當前集群中的HTPasswd文件

如果我們原始創建的HTpasswd認證文件丟失了，該怎么處理呢？

我們可以通過OpenShift中的secret獲取該文件。首先確認secret的名稱，如圖3-28所示。

# oc get secret -n openshift-config

然后將secret的內容提取到本地文件。

# oc extract secret/htpass-secret -n openshift-config --to /root/users.htpasswd 
    –confirm

至此，我們獲取到了HTpasswd的密鑰文件。

2.配置持久化存儲StorageClass

OpenShift中有很多組件需要使用持久化存儲，這里我們使用NFS后端存儲。NFS Server的配置不再贅述。

圖3-28　獲取secret名稱

為了兼容集群中的其他StorageClass，尤其是集群中設置了默認的StorageClass，我們選擇配置靜態StorageClass來消費NFS類型的PV。如果集群中沒有設置默認StorageClass，也可以直接使用靜態PV。

通過下面的文件創建一個靜態的StorageClass。

# cat sc.yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass 
metadata:
   name: standard 
provisioner: kubernetes.io/no-provisioner 
volumeBindingMode: WaitForFirstConsumer

應用上述配置。

# oc apply -f sc.yaml

確認StorageClass創建成功，如圖3-29所示。

圖3-29　創建的靜態StorageClass

接下來，我們為靜態StorageClass創建PV，文件內容如下。

# cat static-storageclass-pv00001.yaml
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv00001
spec:
  storageClassName: standard
  capacity:
    storage: 5Gi
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Recycle
  nfs:
    server: <nfs_server>
    path: /exports/pv00001

我們可以通過腳本批量創建PV，示例腳本請參考Repo中“create_pv.sh”。

創建指定了storageClassName的PVC，文件內容如下。

# cat static-storageclass-pvc00001.yaml
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: task-pv-claim
spec:
  storageClassName: standard
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 3Gi

應用上述PV和PVC文件，等待綁定后，Pod就可以消費了。請讀者根據上述示例創建集群中需要的PV和PVC，在此我們不再一一列出。

3.關閉CoreOS配置更新后自動重啟

OpenShift對CoreOS操作系統節點的配置是通過Machine Config Operator（簡稱MCO）實現的。很多通過MCO對CoreOS操作系統進行修改的配置都需要CoreOS操作系統重啟后生效。OpenShift安裝完畢后，CoreOS配置變更后自動重啟功能默認是開啟的。

使用以下命令查看Master和Worker類型節點的自動重啟功能設置。

# oc get mcp master -o yaml |grep -i pause
  paused: false
# oc get mcp worker -o yaml |grep -i pause
  paused: false

可以通過以下命令，根據節點類型（master、worker或infra）將自動重啟功能關閉。

# oc patch --type=merge --patch='{"spec":{"paused":true}}' machineconfigpool/master
# oc patch --type=merge --patch='{"spec":{"paused":true}}' machineconfigpool/worker
# oc patch --type=merge --patch='{"spec":{"paused":true}}' machineconfigpool/infra

在關閉CoreOS配置更新后自動重啟后，需要關注OCP證書的輪換問題，詳見5.5節的內容。

4.在OpenShift中啟動Image Registry

OpenShift安裝時的平臺如果不提供共享的對象存儲，OpenShift Image Registry Operator將會被標識成Removed狀態。也就是說，默認安裝完OpenShift后，Image Registry容器沒有啟動。

安裝后，我們需要修改Image Registry Operator的配置，將ManagementState從Removed修改為Managed。

# oc edit configs.imageregistry.operator.openshift.io cluster

將managementState:Removed修改為managementState:Managed，然后保存退出。

如果此時在OpenShift中有可用的PV，Registry Pod將被自動創建。

等Pod正常運行后，我們為Registry創建路由，以便外部可以訪問。

# oc patch configs.imageregistry.operator.openshift.io/cluster --type merge -p 
    '{"spec":{"defaultRoute":true}}'
config.imageregistry.operator.openshift.io/cluster patched

獲取Registry訪問地址。

# oc get route
NAME        HOST/PORT         PATH   SERVICES     PORT    TERMINATION   WILDCARD
default-route   default-route-openshift-image-registry.apps.weixinyucluster.
bluecat.ltd          image-registry   <all>   reencrypt     None

驗證倉庫登錄。

# podman login -u admin -p $(oc whoami -t) --tls-verify=false default-route-
    openshift-image-registry.apps.weixinyucluster.bluecat.ltd
Login Succeeded!

接下來我們將一個本地的鏡像推入內部Registry中。

# podman images | grep -i tomcat
docker.io/library/tomcat
# oc new-project image-push
# podman tag docker.io/library/tomcat:latest default-route-openshift-image- 
    registry.apps.weixinyucluster.bluecat.ltd/image-push/tomcat:latest
# podman push default-route-openshift-image-registry.apps.weixinyucluster. 
    bluecat.ltd/image-push/tomcat --tls-verify=false

5.離線環境修復openshift-samples Operator

在前文我們提到，openshift-samples Operator的主要作用是提供安裝和更新Image Streams與Template功能。雖然在OpenShift中我們可以通過OperatorHub對大量的有狀態應用進行全生命周期管理，但Image Streams和Template依然會被大量使用。在本小節中，我們介紹離線安裝OpenShift后修復openshift-samples Operator的方法。

使用離線方式安裝OpenShift后，如果Image Streams沒有正確導入，openshift-samples Operator會處于Degraded狀態。

首先查看離線安裝OpenShift后openshift-samples Operator的狀態，發現顯示為Degraded，Image Streams未成功導入（FailedImageImports）。

# oc get co openshift-samples -o yaml
apiVersion: config.openshift.io/v1
kind: ClusterOperator
[...]
  - lastTransitionTime: "2020-04-27T13:05:07Z"
    message: 'Samples installation in error at 4.3.0: FailedImageImports'
    status: "True"
    type: Progressing
 - lastTransitionTime: "2020-04-30T08:29:34Z"
    message: 'Samples installed at 4.3.0, with image import failures for these 
        imagestreams:
    postgresql mysql rhdm74-decisioncentral-openshift jboss-processserver64-
        openshift
    jboss-webserver30-tomcat7-openshift dotnet-runtime java jboss-eap64-openshift
[...]
    reason: FailedImageImports
    status: "True"
    type: Degraded

使用如下命令獲取需要手動處理的整個Image Streams列表，如圖3-30所示（只列出部分內容）。

# for i in `oc get is -n openshift --no-headers | awk '{print $1}'`; do oc get 
    is $i -n openshift -o json | jq .spec.tags[].from.name | grep registry.
    redhat.io | sed -e 's/"http://g' | cut -d"/" -f2-; done | tee imagelist.txt

圖3-30　獲取的Image Streams列表

我們可以對上面生成的imagelist.txt文件進行裁剪，刪除我們用不到的Image Stream。如果無特殊情況，不建議刪減。接下來，將imagelist.txt文件中列出的鏡像緩存到Mirror Registry（離線安裝OpenShift使用的Mirror Registry）中。執行命令時必須要指定pull secret（含有登錄Mirror Registry和registry.redhat.io的Secret）。

# for i in `cat imagelist.txt`; do oc image mirror -a ~/pullsecret_config.json 
    registry.redhat.io/$i repo.apps.weixinyucluster.bluecat.ltd:5000/$i; done

命令執行過程如圖3-31所示（部分內容）。

圖3-31　查看命令執行過程

導入成功后，在Operator中修改samplesRegistry的spec，以指向Mirror Registry并觸發鏡像重新導入過程。

# oc patch configs.samples.operator.openshift.io/cluster --patch '{"spec":
    {"samplesRegistry": "repo.apps.weixinyucluster.bluecat.ltd:5000" }}' --type=merge

執行上面的命令后，正常會觸發imagestream的重新導入，如果沒有觸發，使用如下命令手動觸發。

# oc patch configs.samples.operator.openshift.io/cluster --patch '{"spec":
    {"managementState": "Removed" }}' --type merge

等待10秒后（讓狀態變化被OpenShift集群探測到）。

# oc patch configs.samples.operator.openshift.io/cluster --patch '{"spec":
    {"managementState": "Managed" }}' --type merge

再用命令行查看，samples operator的狀態已經正常。

# oc describe co openshift-samples

實際上，上述操作不僅導入了Images Streams，也將Images Stream對應的鏡像同步到了離線鏡像倉庫中。通過命令行查看Mirror Registry中包含的應用基礎鏡像（部分內容），執行結果如圖3-32所示。

# curl -u davidwei:davidwei -k https://repo.apps.weixinyucluster.bluecat.ltd:
    5000/v2/_catalog

圖3-32　查看Mirror Registry中包含的應用基礎鏡像

然后查看導入成功的Image Stream，鏡像指向到Mirror Registry的地址，如圖3-33所示。

圖3-33　查看導入成功的Image Stream

6.日志系統的介紹與安裝

OpenShift日志系統由以下五個組件組成，其完整的組件如圖3-34所示。

圖3-34　OpenShift日志系統組件

·LogStore：這是將存儲日志的組件。當前的實現是Elasticsearch。

·Collection：這是從節點收集日志，對其進行格式化并將其存儲在LogStore中的組件。當前的實現是Fluentd。

·Visualization：這是用于查看日志、圖形、圖表等的可視化組件。當前的實現是Kibana。

·Curation：這是按日期清理日志的組件。當前的實現是Curator。

·Event Routing：這是將事件轉發到集群日志記錄的組件。當前的實現是Event Router。

OpenShift使用Fluentd收集有關集群的數據。日志收集器在OpenShift容器平臺中作為DaemonSet部署。日志記錄是系統日志源，提供來自操作系統/容器運行時和OpenShift容器平臺的日志消息。OpenShift使用Elasticsearch（ES）將Fluentd的日志數據組織到數據存儲或索引中。Elasticsearch將每個索引細分為多個碎片，并將它們分散在Elasticsearch集群中的一組節點上。高度可用的Elasticsearch環境需要至少三個Elasticsearch節點，每個節點都在不同的主機上，如圖3-35所示。

圖3-35　OpenShift日志系統工作模式

OpenShift容器平臺使用Kibana顯示由Fluentd收集并由Elasticsearch索引的日志數據。Kibana是基于瀏覽器的控制臺界面，可通過直方圖、折線圖、餅圖、熱圖、內置地理空間支持和其他可視化查詢，發現和可視化Elasticsearch數據。

為了防止日志大量增長把磁盤撐滿，每個Elasticsearch集群部署一個Curator Pod即可，如圖3-36所示。

圖3-36　Curator Pod的作用

Curator基于配置，每天對日志系統進行檢查。我們可以通過編輯openshift-logging項目中的Curator Configmap對其進行配置更改。在Configmap中編輯文件config.yaml，然后為Curator創建cronjob作業以強制清理。

在介紹了OpenShift日志系統的架構后，接下來介紹安裝日志系統的步驟，需要指出的是，不同版本的日志系統的安裝步驟可能略有差別，本步驟以OpenShift 4.4為例說明。其他版本可以參考紅帽官網https://access.redhat.com/products/red-hat-openshift-container-platform。

OpenShift的日志系統安裝可以采用半圖形化和純命令行兩種安裝方式，為了方便讀者深入理解步驟和書寫部署日志系統的腳本，我們介紹純命令行的安裝方式。

需要安裝Elasticsearch Operator和Cluster Logging兩個Operator。我們首先創建安裝Operator的兩個Namespace。編寫創建openshift-operators-redhat namespace的yaml文件（啟用cluster-monitoring），并應用配置。

# cat eo-namespace.yaml
apiVersion: v1
kind: Namespace
metadata:
  name: openshift-operators-redhat 
  annotations:
    openshift.io/node-selector: ""
  labels:
    openshift.io/cluster-monitoring: "true" 
# oc apply -f eo-namespace.yaml

編寫創建openshift-logging namespace的yaml文件（啟用cluster-monitoring），并應用配置。

# cat clo-namespace.yaml
apiVersion: v1
kind: Namespace
metadata:
  name: openshift-logging
  annotations:
    openshift.io/node-selector: ""
  labels:
    openshift.io/cluster-monitoring: "true"
# oc apply -f clo-namespace.yaml

安裝Elasticsearch Operator。

# cat operator_group.yaml
apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: openshift-operators-redhat
  namespace: openshift-operators-redhat
spec: {}
# oc apply -f operator_group.yaml

創建Elasticsearch Operator訂閱文件。

# cat eo-sub.yaml
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: "elasticsearch-operator"
  namespace: "openshift-operators-redhat" 
spec:
  channel: "4.4" 
  installPlanApproval: "Automatic"
  source: "redhat-operators" 
  sourceNamespace: "openshift-marketplace"
  name: "elasticsearch-operator" 
# oc apply -f eo-sub.yaml

安裝Cluster Logging Operator。

# cat clo-og.yaml
apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: cluster-logging
  namespace: openshift-logging 
spec:
  targetNamespaces:
  - openshift-logging
# oc create -f clo-og.yaml

創建Cluster Logging Operator訂閱文件。

# cat clo-sub.yaml
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: cluster-logging
  namespace: openshift-logging
spec:
  channel: "4.4"
  name: cluster-logging
  source: redhat-operators
  sourceNamespace: openshift-marketplace
# oc create -f clo-sub.yaml

創建基于角色的訪問控制（RBAC）對象文件（例如eo-rbac.yaml），以授予Prometheus訪問openshift-operators-redhat命名空間的權限。

# cat rbac.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: prometheus-k8s
  namespace: openshift-operators-redhat
rules:
- apiGroups:
  - ""
  resources:
  - services
  - endpoints
  - pods
  verbs:
  - get
  - list
  - watch
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: prometheus-k8s
  namespace: openshift-operators-redhat
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: prometheus-k8s
subjects:
- kind: ServiceAccount
  name: prometheus-k8s
  namespace: openshift-operators-redhat
# oc create -f rbac.yaml

創建Cluster Logging的CRD文件。創建CRD時需要指定StorageClass，然后點擊Create，如下所示。我們需要關注CRD的下面幾個配置：

·resources的limits和requests：需要讓設置的數值匹配到OpenShift集群的節點（如果太大，可能選擇不到節點；太小，則會影響運行性能）。

·nodeSelector：將EFK安裝到哪個角色的節點，在下面的配置中，我們將其部署到worker節點。這個設置要與OpenShift的實際環境匹配，否則選擇不上節點。

·storageClassName：OpenShift使用的持久化存儲。如果沒有設置默認的StorageClass，此處為空即可。但創建的PV需要一直匹配，也不指定StorageClass，否則PV和PVC會綁定不成功。

# cat clo-instance.yaml
apiVersion: logging.openshift.io/v1
kind: ClusterLogging
metadata:
  name: instance
  namespace: openshift-logging
spec:
  managementState: Managed
  logStore:
    type: elasticsearch
    elasticsearch:
      resources:
        limits:
          memory: 2Gi
        requests:
          memory: 2Gi
      nodeCount: 1
      nodeSelector:
        node-role.kubernetes.io/worker: ""
      redundancyPolicy: ZeroRedundancy
      storage:
        storageClassName: ""
        size: 50Gi
  visualization:
    type: kibana
    kibana:
      replicas: 1
      nodeSelector:
        node-role.kubernetes.io/worker: ""
  curation:
    type: curator
    curator:
      schedule: 30 3 * * *
      nodeSelector:
        node-role.kubernetes.io/worker: ""
  collection:
    logs:
      type: fluentd
      fluentd: {}
# oc create -f clo-instance.yaml

EFK的Pod開始創建，如圖3-37所示。

# oc get pods -n openshift-logging

圖3-37　查看Logging的pod

創建成功后，查看Kibana路由，通過瀏覽器可以登錄訪問，如圖3-38所示。

# oc get route
NAME     HOST/PORT       PATH   SERVICES   PORT    TERMINATION          WILDCARD
kibana   kibana-openshift-logging.apps.weixinyucluster.bluecat.ltd          
   kibana     <all>   reencrypt/Redirect   None

最后，我們配置Curator的Configmap實現如下需求：

·1周后清理所有項目日志。

·2周后清理所有以openshift開始的項目的日志。

·4周后清理所有操作日志。

# oc edit cm curator -n openshift-logging
.defaults:
   delete:
    days: 7
# Keep OpenShift logs for 2 weeks
.regex:
- pattern: 'openshift-$'
  delete:
    weeks: 2
# to keep ops logs for a different duration:
.operations:
   delete:
weeks: 4

然后創建計劃任務。

# oc create job --from=cronjob/curator cleanup -n openshift-logging

圖3-38　Kibana界面顯示

查看計劃任務，創建成功，如圖3-39所示。

關于Kibana索引的查看、創建等操作，請查看Repo中“Kibana安裝后的配置”。

圖3-39　查看計劃任務

7.Infra節點的配置

OpenShift 3的安裝是通過Ansible完成的，在Playbook的變量中可以指定某兩三個節點是Infra角色，同時在Playbook中設置Router、EFK、監控相應的資源部署到Infra節點上。這樣OpenShift部署完畢后Infra節點就自動配置好了。

而在OpenShift 4中無法在安裝時指定Infra角色（只有Master和Woker兩種節點角色）。那么在OpenShift 4中是否有必要配置Infra節點？

答案是肯定的。在開發測試環境，我們遇到過很多次由于沒有配置Infra節點，當OpenShift升級后Router Pod很可能會漂移到其他節點上，造成解析報錯，需要修改LB或HAproxy上的配置的情況。這種情況在開發測試或者POC環境中不會造成很大影響，但如果在生產環境，出現這種問題顯然是不應該的。

另外，集群的基礎組件最好與業務應用容器隔離，避免搶占資源導致基礎組件不穩定或性能下降。因此在OpenShift 4中也需要配置Infra節點。下面我們就介紹具體的操作步驟。

（1）配置Node Label

以我們的環境為例，OpenShift集群包含3個Master、4個Worker節點。

# oc get nodes
NAME       STATUS   ROLES    AGE   VERSION
master-0   Ready    master   26d   v1.17.1
master-1   Ready    master   26d   v1.17.1
master-2   Ready    master   26d   v1.17.1
worker-0   Ready    worker   26d   v1.17.1
worker-1   Ready    worker   26d   v1.17.1
worker-2   Ready    worker   26d   v1.17.1
worker-3   Ready    worker   26d   v1.17.1

默認情況下，4個Worker的角色是一樣的。為了說明過程，我們只將worker-3配置為Infra節點，在真實生產環境中，建議至少設置3個Infra節點。

首先將worker-3打標簽為Infra節點。

# oc label node worker-3 node-role.kubernetes.io/infra=""
node/worker-3 labeled

將其余三個節點配置為app節點。

# oc label node worker-0 node-role.kubernetes.io/app=""
node/worker-0 labeled
# oc label node worker-1 node-role.kubernetes.io/app=""
node/worker-1 labeled
# oc label node worker-2 node-role.kubernetes.io/app=""
node/worker-2 labeled

確認Node Label如下。

# oc get nodes
NAME       STATUS   ROLES          AGE   VERSION
master-0   Ready    master         26d   v1.17.1
master-1   Ready    master         26d   v1.17.1
master-2   Ready    master         26d   v1.17.1
worker-0   Ready    app,worker     26d   v1.17.1
worker-1   Ready    app,worker     26d   v1.17.1
worker-2   Ready    app,worker     26d   v1.17.1
worker-3   Ready    infra,worker   26d   v1.17.1

（2）配置Default Selector

創建一個默認的Node Selector，也就是為沒有設置nodeSelector的Pod分配部署的節點子集，例如，默認情況下部署在app標簽的節點上。

編輯Scheduler Operator Custom Resource以添加defaultNodeSelector（下面內容中的加粗部分）。

# oc edit scheduler cluster
spec:
  defaultNodeSelector: node-role.kubernetes.io/app=
  mastersSchedulable: false
  policy:
    name: ""
status: {}

需要注意的是，配置保存退出后，API Server的Pod會重啟，因此會有短暫的APIServer不可用（30s以內）。在Infra節點配置完成后，我們需要將已經運行的基礎組件遷移到Infra節點上。

（3）遷移Router

遷移之前，兩個Router分別運行在app標簽的兩個節點上，如圖3-40所示。

圖3-40　查看兩個Router Pod所在的節點

修改openshift-ingress-operator的配置，如下所示。

# oc edit ingresscontroller default -n openshift-ingress-operator -o yaml
spec:
  nodePlacement:
    nodeSelector:
      matchLabels:
        node-role.kubernetes.io/infra: ""
  replicas: 2

保存退出后，我們看到之前運行在worker-0和worker-1上的Pod會被終止，然后在Infra節點上重啟，如圖3-41所示。

# oc get pod -n openshift-ingress -o wide

過一會兒我們再次查看，有一個Router已經運行了，另外一個Router處于Pending狀態。原因是一個Infra節點上只能運行一個Router，而我們現在只有一個Infra節點，如圖3-42所示。

圖3-41　Router在Infra節點啟動

圖3-42　一個Router處于Pending狀態

在生產環境，我們建議設置三個節點為Infra節點。OpenShift默認安裝后Router有兩個副本，可以用如下命令查看。

# oc get -n openshift-ingress-operator ingresscontrollers/default -o 
    jsonpath='{$.status.availableReplicas}'
2

通過如下方法可以將Router的副本數設置為3。

# oc patch -n openshift-ingress-operator ingresscontroller/default --patch '{"spec":
    {"replicas": 3}}' --type=merge
ingresscontroller.operator.openshift.io/default patched

（4）遷移Image Registry

遷移之前，Registry運行在worker-1上，配置imageregistry.operator.openshift.io/v1的MachineSets。

# oc edit config/cluster

增加如下內容。

spec:
  nodeSelector:
    node-role.kubernetes.io/infra: ""

保存配置后，Register在Infra節點重啟，如圖3-43所示。

圖3-43　Register在Infra節點重啟

（5）遷移監控系統

默認情況下，OpenShift集群監控套件包含Prometheus、Grafana和AlertManager。它由Cluster Monitor Operator（CMO）管理。要將其組件移動到其他節點，我們需要創建并應用自定義ConfigMap。

# cat cluster-monitoring-configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: cluster-monitoring-config
  namespace: openshift-monitoring
data:
  config.yaml: |+
    alertmanagerMain:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    prometheusK8s:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    prometheusOperator:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    grafana:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    k8sPrometheusAdapter:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    kubeStateMetrics:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    telemeterClient:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    openshiftStateMetrics:
      nodeSelector:
        node-role.kubernetes.io/infra: ""

應用配置前，我們看到Pod任意分布。應用上述配置。

# oc create -f cluster-monitoring-configmap.yaml

應用配置后，監控相關的Pod在Infra節點重啟。

（6）遷移日志系統

我們修改日志ClusterLogging實例如下。

# oc edit ClusterLogging instance -n openshift-logging

增加如下加粗部分內容。

    curator:
      nodeSelector: 
          node-role.kubernetes.io/infra: ''
      resources: null
      schedule: 30 3 * * *
    type: curator
  logStore:
    elasticsearch:
      nodeCount: 3
      nodeSelector: 
          node-role.kubernetes.io/infra: ''
      redundancyPolicy: SingleRedundancy
      resources:
        limits:
          cpu: 500m
          memory: 16Gi
        requests:
          cpu: 500m
          memory: 16Gi
      storage: {}
    type: elasticsearch
  managementState: Managed
  visualization:
    kibana:
      nodeSelector: 
          node-role.kubernetes.io/infra: ''

保存退出后，EFK相關的Pod會遷移到Infra節點。

8.離線環境導入OperatorHub

離線導入OperatorHub包含兩個層面的內容：

·OperatorHub自身鏡像資源：它負責支撐OperatorHub這個“殼”，也就是說，部署完畢后，OpenShift上可以看到OperatorHub，并且可以點擊部署具體Operator的向導。

·Operator的鏡像資源：我們在選擇部署某個類型、版本的Operator時，OpenShift會找具體的Operator容器鏡像（比如不同版本的ES Operator指向的容器鏡像是不同的）。

首先我們離線同步OperatorHub自身的鏡像資源，將OperatorHub的鏡像從紅帽官網鏡像同步到管理機的本地鏡像倉庫，命令執行結果如圖3-44所示。

# oc image mirror registry.redhat.io/openshift4/ose-operator-registry:v4.4 repo.
    apps.weixinyucluster.bluecat.ltd:5000/openshift4/ose-operator-registry -a ~/
    pullsecret_config.json

注意：-a指定的認證要能同時訪問registry.redhat.io和管理機鏡像倉庫repo.apps.weixinyucluster.bluecat.ltd:5000。

通過下面的命令構建本地的CatalogSource鏡像，命令執行結果如圖3-45所示。

# oc adm catalog build --appregistry-org redhat-operators --from=repo.apps.
    weixinyucluster.bluecat.ltd:5000/openshift4/ose-operator-registry:v4.4 --to=
    repo.apps.weixinyucluster.bluecat.ltd:5000/olm/redhat-operators:v1 -a ~/
    pullsecret_config.json

圖3-44　命令執行結果

圖3-45　形成本地的CatalogSource鏡像

命令中指定redhat-operators表示我們只構建redhat-operator CatalogSource。

獲取要下載的具體Operator鏡像的列表文件。

# oc adm catalog mirror --manifests-only repo.apps.weixinyucluster.bluecat.
    ltd:5000/olm/redhat-operators:v1  repo.apps.weixinyucluster.bluecat.ltd:5000 
    ~/pullsecret_config.json

上面的命令執行后，會生成redhat-operators-manifests目錄，我們查看目錄結構。

# tree redhat-operators-manifests/
redhat-operators-manifests/
├── imageContentSourcePolicy.yaml
└── mapping.txt

mapping.txt中包含CatalogSource為redhat-operator中所有鏡像的映射關系，由于文件較長，我們查看其中elasticsearch operator的內容。

# cat mapping.txt |grep -i ose-elasticsearch-operator
registry.redhat.io/openshift4/ose-elasticsearch-operator@sha256:13e233ff2dd419
    67c55194724ba148868ed878232789ab616ea3a6f9a9219c97=repo.apps.weixinyucluster.
    bluecat.ltd:5000/openshift4/ose-elasticsearch-operator
registry.redhat.io/openshift4/ose-elasticsearch-operator@sha256:06cc3bb2877403
    60e4c0071dab8ea4254baa02a67205424241cfbfe8b2b8f375=repo.apps.weixinyucluster.
    bluecat.ltd:5000/openshift4/ose-elasticsearch-operator
registry.redhat.io/openshift4/ose-elasticsearch-operator@sha256:e6c6a271910ba2
    fbacc1f4b15cd538df588c1fbc32644ee984ae94bdaea56a23=repo.apps.weixinyucluster.
    bluecat.ltd:5000/openshift4/ose-elasticsearch-operator
registry.redhat.io/openshift4/ose-elasticsearch-operator@sha256:9603cef2ceb515
    0e7bf2b878a64cab30b3fa525e2a0dd3de93412c9baa3da2d5=repo.apps.weixinyucluster.
    bluecat.ltd:5000/openshift4/ose-elasticsearch-operator
registry.redhat.io/openshift4/ose-elasticsearch-operator@sha256:aa0c7b11a65545
    4c5ac6cbc772bc16e51ca5004eedccf03c52971e8228832370=repo.apps.weixinyucluster.
    bluecat.ltd:5000/openshift4/ose-elasticsearch-operator

我們看到在mapping.txt中一共有5行elasticsearch operator的內容，這是因為edhat-operator CatalogSource中有5個版本的elasticsearch operator。

很多時候，我們并不需要將mapping.txt中的鏡像全部下載下來，只需要下載我們需要的種類和版本即可。為了方便操作，我們使用一個Shell腳本下載，這個腳本調用Skopeo命令行同步鏡像（避免sha256發生變化）。

腳本如下所示：

# cat batchmirror.sh
#!/bin/bash
i=0
while IFS= read -r line
do
  i=$((i + 1))
  echo $i;
  source=$(echo $line | cut -d'=' -f 1)
  echo $source
  target=$(echo $line | cut -d'=' -f 2)
  echo $target
  skopeo copy --all docker://$source docker://$target
  sleep 20
done < es.txt

我們將從mapping中grep出來的elasticsearch operator五行內容貼到同目錄es.txt中。

然后使用docker login分別登錄registry.redhat.io和repo.apps.weixinyucluster.bluecat.ltd:5000，然后執行腳本。

# sh batchmirror.sh

執行成功后，會有5個elasticsearch operator的鏡像被同步到repo.apps.weixinyucluster.bluecat.ltd:5000。

截至目前，我們已經有了OperatorHub“殼”的鏡像，也有了redhat-operator CatalogSource中的elasticsearch Operator“瓤”（一共五個elasticsearch operator鏡像）。

接下來形成離線的Operatorhub Catalog。OpenShift默認的OperatorHub的CatalogSource指向外網，我們需要將默認CatalogSource關閉，如下所示。

# oc patch OperatorHub cluster --type json \
>     -p '[{"op": "add", "path": "/spec/disableAllDefaultSources", "value": true}]'

然后建立一個文件catalogsource.yaml，用于啟動離線的CatalogSource，如下所示。

# export CHANNEL=redhat
# oc apply -f - <<EOF
apiVersion: operators.coreos.com/v1alpha1
kind: CatalogSource
metadata:
  name: ${CHANNEL}-operators-internal
  namespace: openshift-marketplace
  labels:
    olm-visibility: hidden
    openshift-marketplace: "true"
    opsrc-datastore: "true"
   opsrc-owner-name: ${CHANNEL}-operators
    opsrc-owner-namespace: openshift-marketplace
    opsrc-provider: ${CHANNEL}
spec:
  sourceType: grpc
   image: repo.apps.weixinyucluster.bluecat.ltd:5000/olm/redhat-operators:v1
   displayName: ${CHANNEL}-operators-internal
   publisher: Red Hat
 EOF
catalogsource.operators.coreos.com/redhat-operators-internal created

建立完成后檢查OperatorHub界面是否可以訪問，可以看到redhat-operator CatalogSource（Provider Type為Red Hat，與上面的指定步驟匹配），如圖3-46所示：

我們查看承載OperatorHub這個“殼”的資源。

# oc get pods -n openshift-marketplace
NAME      READY   STATUS    RESTARTS   AGE
redhat-operators-internal-nvprb      1/1     Running   0          28s

# oc get catalogsource -n openshift-marketplace
NAME         DISPLAY                     TYPE   PUBLISHER   AGE
redhat-operators-internal   redhat-operators-internal   grpc   Red Hat     33m

圖3-46　查看OperatorHub界面

由于是離線環境，默認Operator的鏡像地址指向外網，官方文檔使用的是應用imageContentSourcePolicy.yaml文件，該方法要求所有的鏡像使用sha256對鏡像進行標記，但我們發現半數以上的鏡像仍然采用Tag，這將導致Mirror失效，所以我們這里不采用imageContentSourcePolicy.yaml的方案，而采用通過MachineConfig為每個Node覆蓋registries.conf配置的方法，設置mirror-by-digest-only=false，實現無論是使用sha256還是使用tag的鏡像均可離線拉取。

首先書寫sample-registres.conf文件，用于覆蓋每個OpenShift的RHCOS節點/etc/containers/registries.conf，具體內容參考Repo中“sample-registres.conf”。

隨后將sample-registres.conf通過base64加密，如下所示。

# export REG_CONF_BASE64=$(cat sample-registres.conf | base64 -w 0)

然后編寫分別覆蓋Master、Infra、App節點的配置的文件，如Repo中“3Xcontainer-registries”所示。

# oc apply -f 99-master-container-registries.yaml
# oc apply -f 99-worker-container-registries.yaml
# oc apply -f 99-infra-container-registries.yaml

應用配置文件后，應用配置的節點會發生重啟，等待相應的服務器重啟。

接下來，通過OpenShift OperatorHub選擇elasticsearch operator，如圖3-47所示。

圖3-47　搜索Elasticsearch Operator

選擇Elasticsearch Operator點擊安裝，選擇如圖3-48所示的內容。

圖3-48　安裝Elasticsearch Operator

很快，Elasticsearch Operator部署成功，如圖3-49所示。

圖3-49　Elasticsearch Operator部署成功

官术网_书友最值得收藏!

OpenShift在企業中的實踐：PaaS DevOps微服務（第2版）

3.2.4 OpenShift部署后的配置

3.2.4　OpenShift部署后的配置