Upgrade to PRO for Only $50/Year—Limited-Time Offer! 🔥

OpenShift.Run-2022-makaizo

orimanabu
January 21, 2022

 OpenShift.Run-2022-makaizo

あけおめ OpenShift.Run 2022 (#14) 「OpenShift完全解体!〜K8sと比べてどう拡張されてきたか紐解きます〜」のスライド

orimanabu

January 21, 2022
Tweet

More Decks by orimanabu

Other Decks in Technology

Transcript

  1. 2 自己紹介 ▸ 名前: 織 学 (@orimanabu) ▸ 所属: Red

    Hat ▸ 仕事: コンサルタント ・ OpenStackとかOpenShiftとかAnsibleとか
  2. 3 今日のお話 ▸ OpenShiftとは... ・ Red HatのKubernetesディストリビューション ・ UpstreamのKubernetesにいろいろ機能を追加しています ▸

    町の噂: OpenShiftは「Red HatがKubernetesを魔改造した何か」らしい ・ 「Red Hatがロックインしている!フォーク🍴している!コミュニティを分断している!」 ▸ その噂の真相を解明するため、我々はアマゾンの奥地へと向かった...
  3. 4 OpenShiftとは 「OpenShift は多数の Operator の集合体」と言うことができま す。Operator とは Kubernetes を拡張する手法の

    1 つであり、 運用を自律化するためのカスタムコントローラーと CustomResourceDefinition( CRD )を指します(詳細は 7.1 節 で解説します)。また OpenShift は、クラスタアップグレードを はじめ、モニタリングやロギング、その他クラスタを構成する Operator 群、高機能 GUI のOperatorHubから導入可能な サービスメッシュや CI/CD、ストレージクラスタなど、もともとの Kubernetes にはない機能が多数追加され、ありとあらゆる要 素が Operator によってインストールでき、自律的に運用でき るというコンセプトを持っています。 https://www.shoeisha.co.jp/book/detail/9784798172552
  4. 5 OpenShiftとは 「OpenShift は多数の Operator の集合体」と言うことができま す。Operator とは Kubernetes を拡張する手法の

    1 つであり、 運用を自律化するためのカスタムコントローラーと CustomResourceDefinition( CRD )を指します(詳細は 7.1 節 で解説します)。また OpenShift は、クラスタアップグレードを はじめ、モニタリングやロギング、その他クラスタを構成する Operator 群、高機能 GUI のOperatorHubから導入可能な サービスメッシュや CI/CD、ストレージクラスタなど、もともとの Kubernetes にはない機能が多数追加され、ありとあらゆる要 素が Operator によってインストールでき、自律的に運用でき るというコンセプトを持っています。 https://www.shoeisha.co.jp/book/detail/9784798172552 • 全648ページ! ◦ ネットワーク: 96ページ ◦ Day 2 オペレーション: 78ページ • GPUノードの作り方も! • アプリのビルド、デプロイ、CI/CD等の話 題も充実!
  5. 6 OpenShiftとは ▸ Kubernetesにいろいろ追加しています ・ コンテナ実行環境を堅牢化する、運用を自動化する、本番環境で使えるようにする AUTOMATED OPERATIONS CLUSTER SERVICES

    APPLICATION SERVICES DEVELOPER SERVICES Middleware, Service Mesh Functions, ISV Monitoring, Chargeback Registry, Logging Automated Builds, CI/CD, IDE Any Infrastructure どの環境でも、迅速かつ 信頼性の高いOS どの環境でも、同様の手 順でアプリケーションを稼 働 どの環境でも、自動化さ れた運用プロセスを実現 Virtual Private cloud Bare metal Public cloud Edge
  6. 7 命題: 「OpenShiftはKubernetesを魔改造した何か」なのか ▸ 魔改造の定義や範囲は人それぞれかもしれませんが、ここでは以下と仮定します ・ upstreamのコードそのままではなく、何かしら大きな改変を加えて製品化している ・ 「え、そんな変更していいの?」的な変更 ▸

    魔改造の定義にもよりますが...答えは ・ 昔はYes、今はNo ・ (個人の見解です) ▸ というわけで。 ・ 昔はどう魔改造していたのか ・ 今はどうなっているのか といった辺りのお話をしたいと思います
  7. 10 魔改造事例 - RHEL7 ▸ RHELのカーネルはわりと普段から魔改造してます ・ RHEL7カーネルのベースバージョンは3.10 RHEL7.1 perfを3.14にrebase

    KVMを3.16にrebase RHEL7.2 TCP/IPスタックを3.18にrebase KVMを4.0にrebase RHEL7.3 KVMを4.3にrebase perfを4.6にrebase RHEL7.4 KVMを4.10にrebase perfを4.9にrebase RHEL7.5 perfを4.12にrebase RHEL7.6 perfを4.14にrebase RHEL7.7 perfを4.16にrebase 155個のパッチシリーズ
  8. 11 魔改造事例 - RHEL5のMeltdown/Spectre対応 ▸ 2018年1月、Meltdown/Spectreで大変でしたね ・ CVE-2017-5754, CVE-2017-5715, CVE-2017-5753

    ▸ 当時、RHEL5は通常サポートが終了し、延長サポート(ELS)フェーズに入っていました ・ ELS (Extended Lifecycle Support): 限られたパッケージを対象に、重大な不具合、深刻な脆弱性の修 正のみ対応するアドオンサブスクリプション ・ RHEL5のカーネルに対しても、頑張ってPage Table Isolationの機能をバックポートしました ・ バックポート対象は10年以上前のバージョン、仮想メモリ周りの実装はほとんど別物 ・ 「これまでで最も困難なバックポートだった」 2007-03 RHEL5 GA 2017-03 RHEL5 通常サポート終了 2020-11 RHEL5 延長サポート終了 2006-09 Linux Kernel v2.6.18 GA 2018-01 Linux Kernel v4.15 GA Meltdown, Spectre RHEL5カーネ ルのベース バージョン PTIがマージされ たバージョン 10年
  9. 14 OpenShift v3の魔改造 ▸ (以下明記しない限り、便宜上v3.7をベースにした内容になっています) ・ https://github.com/openshift/origin/tree/release-3.7 ▸ OpenShiftのソースツリーにKubernetesをvendoring ▸

    主にpkg以下の必要な機能をライブラリ的にimportしつつ、必要な機能を実装 ▸ kube-api-server, kube-scheduler, kube-controller-manager, kube-proxy, kubelet等、全部を1バイナリに結 合 ▸ 多くのコンポーネントはsystemdのservice unitとして起動 ・ masterノード ・ atomic-openshift-master-api ・ atomic-openshift-controller-managers ・ etcd ・ atomic-openshift-node ・ workerノード ・ atomic-openshift-node
  10. 15 OpenShift v3のコンポーネント atomic-openshift-master -api atomic-openshift-master -controllers atomic-openshift-node /usr/bin/openshift kube-apiserver

    kube-controller- manager kube-scheduler kube-dns etcd kube-proxy kubelet etcd /usr/bin/etcd OpenShift v3 Systemd service unit Binary Kubernetes component 全てのコードを1バイナ リに押しつけるという、 男気あふれる実装 (373MB) /usr/bin/openshift start master api /usr/bin/openshift start master controllers /usr/bin/openshift start node OpenShift APIs OpenShift OAuth OpenShift DNS OpenShift Controllers OpenShift SDN OpenShift DNS
  11. 16 Pod少なっ $ oc get pod --all-namespaces NAMESPACE NAME READY

    STATUS RESTARTS AGE default docker-registry-1-r6wlj 1/1 Running 0 1d default registry-console-1-jrrnq 1/1 Running 0 1d default router-1-2w86j 1/1 Running 0 1d $ oc get pod --all-namespaces NAMESPACE NAME READY STATUS RESTARTS AGE default docker-registry-1-6l4ps 1/1 Running 0 15h default registry-console-1-ln5d5 1/1 Running 0 15h default router-1-4qh2s 1/1 Running 0 15h kube-system master-api-ocp3-master1.osetest.local 1/1 Running 0 15h kube-system master-controllers-ocp3-master1.osetest.local 1/1 Running 0 15h kube-system master-etcd-ocp3-master1.osetest.local 1/1 Running 0 15h openshift-console console-557bc98fd6-sc2gx 1/1 Running 0 15h openshift-node sync-45fcw 1/1 Running 0 15h openshift-node sync-hq7qz 1/1 Running 0 15h openshift-node sync-jxxvl 1/1 Running 0 15h openshift-node sync-mvc2f 1/1 Running 0 15h openshift-sdn ovs-5b7dx 1/1 Running 0 15h openshift-sdn ovs-8stgx 1/1 Running 0 15h openshift-sdn ovs-gk44z 1/1 Running 0 15h openshift-sdn ovs-lzvjz 1/1 Running 0 15h openshift-sdn sdn-4x6nc 1/1 Running 0 15h openshift-sdn sdn-5bwqr 1/1 Running 0 15h openshift-sdn sdn-bdvz4 1/1 Running 0 15h openshift-sdn sdn-ncqbc 1/1 Running 0 15h openshift-web-console webconsole-85494cdb8c-g4zt8 1/1 Running 0 15h OpenShift 3.7インストール直後 OpenShift 3.11インストール直後 (ご参考)
  12. 17 DNS周り ▸ 各ノード ・ 127.0.0.1:53 → atomic-openshift-node ・ in-addr.arpa

    ・ cluster.local ・ ノードのIPアドレス:53 → dnsmasq ・ それ以外 (外部のキャッシュサーバに聞きにいく) ▸ atomic-openshift-node内にSkyDNSの実装が入っている ・ atomic-openshift-master-apiのSkyDNSと8053で通信 $ sudo lsof -nP -i4:53 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME dnsmasq 1206 nobody 4u IPv4 27043 0t0 UDP 172.16.19.41:53 dnsmasq 1206 nobody 5u IPv4 27045 0t0 TCP 172.16.19.41:53 (LISTEN) dnsmasq 1206 nobody 13u IPv4 34064 0t0 UDP 10.128.0.1:53 dnsmasq 1206 nobody 14u IPv4 34065 0t0 TCP 10.128.0.1:53 (LISTEN) dnsmasq 1206 nobody 15u IPv4 30501 0t0 UDP 172.17.0.1:53 dnsmasq 1206 nobody 16u IPv4 30502 0t0 TCP 172.17.0.1:53 (LISTEN) openshift 1801 root 27u IPv4 34709 0t0 UDP 127.0.0.1:53 openshift 1801 root 30u IPv4 34710 0t0 TCP 127.0.0.1:53 (LISTEN) $ sudo cat /etc/dnsmasq.d/node-dnsmasq.conf server=/in-addr.arpa/127.0.0.1 server=/cluster.local/127.0.0.1
  13. 18 例: Controller Manager Startup NewCommandStartMaster() @pkg/cmd/server/start/start_master.go MasterOptions.StartMaster() @pkg/cmd/server/start/start_master.go MasterOptions.RunMaster()

    @pkg/cmd/server/start/start_master.go Master.Start() @pkg/cmd/server/start/start_master.go startControllers() @pkg/cmd/server/start/start_master.go runEmbeddedKubeControllerManager() @pkg/cmd/server/start/start_kube_controller_manager.go goroutine OpenshiftControllerConfig.GetControllerInitializers() @pkg/cmd/server/origin/controller/config.go Run() @vendor/k8s.io/kubernetes/cmd/kube-controller-manager/ app/controllermanager.go NewControllerInitializers() @vendor/k8s.io/kubernetes/cmd/kube-controller-manager/ app/controllermanager.go openshift start master controllers (OpenShift) kube-controller-manager (Kubernetes)
  14. 19 例: Controller Manager Startup NewCommandStartMaster() @pkg/cmd/server/start/start_master.go MasterOptions.StartMaster() @pkg/cmd/server/start/start_master.go MasterOptions.RunMaster()

    @pkg/cmd/server/start/start_master.go Master.Start() @pkg/cmd/server/start/start_master.go startControllers() @pkg/cmd/server/start/start_master.go runEmbeddedKubeControllerManager() @pkg/cmd/server/start/start_kube_controller_manager.go goroutine OpenshiftControllerConfig.GetControllerInitializers() @pkg/cmd/server/origin/controller/config.go Run() @vendor/k8s.io/kubernetes/cmd/kube-controller-manager/ app/controllermanager.go NewControllerInitializers() @vendor/k8s.io/kubernetes/cmd/kube-controller-manager/ app/controllermanager.go openshift start master controllers (OpenShift) kube-controller-manager (Kubernetes)
  15. 21 OpenShift v4の魔改造...? ▸ OpenShiftの拡張部分は、Kubernetesの拡張機構を使って再実装 ・ Admission Webhook ・ API

    Aggregation ・ Operator ▸ 結果として、Kubernetesのコアコンポーネント(api server, controller manager, scheduler等)はほとんどコード 変更せずにコンテナとして起動 How and Why We’re Changing Deployment Topology in OpenShift 4 https://cloud.redhat.com/blog/how-and-why-were-changing-deployment-topology-in-openshift-4-0
  16. 22 Kubernetesが持つ3つの拡張パターン ▸ Controller ・ 特定のリソースをWatchし、Reconciliation Loopを実行する ▸ Webhook ・

    HTTPSでリクエストを受け付ける ▸ Binary Plugin ・ 特定のバイナリを実行する https://kubernetes.io/ja/docs/concepts/extend-kubernetes/
  17. 23 Kubernetesの機能拡張できる場所 ▸ kubectl plugin ▸ API Flow Extensions ・

    Authentication / Authorization ・ Mutating / Validating Admission Webhooks ▸ Kubernetes API Extensions ・ Operator pattern: Custom Resource Definition + Custom Controller ・ API Aggregation ▸ Scheduler Extensions ・ Multiple Schedulers ・ Scheduler Extenders ▸ Infrastructure Extensions ・ CSI plugin ・ CNI plugin ・ Device plugin ご参考: 先日のOCHaCafe Season5 #1「Kubernetes Operator 超入門」の資料がと てもわかりやすいです https://speakerdeck.com/oracle4engineer/kubernetes-operator-introduction
  18. 24 API処理の流れ kube-aggregator kube resources (pods, services, ...) apiextensions- apiserver

    (CRDs) 404 Requests etcd API Aggregation Operator pattern API HTTP handler Authentication Authorization Mutating Admission Object Schema Validation Validating Admission Persisted to etcd Mutating Webhook Validating Webhook Authn/Authz Webhook
  19. 25 Authentication Webhook $ oc -n openshift-kube-apiserver get cm/config -o

    json | \ jq -r '.data."config.yaml"' | \ jq '.apiServerArguments."authentication-token-webhook-config-file"' [ "/etc/kubernetes/static-pod-resources/secrets/webhook-authenticator/kubeConfig" ] $ oc -n openshift-kube-apiserver exec -c kube-apiserver kube-apiserver-master-0 -- \ cat /etc/kubernetes/static-pod-resources/secrets/webhook-authenticator/kubeConfig apiVersion: v1 clusters: - name: local-cluster cluster: certificate-authority-data: LS0tLS1CRUdJTiBDRVJU... server: https://172.30.218.106:443/apis/oauth.openshift.io/v1/tokenreviews tls-server-name: api.openshift-oauth-apiserver.svc contexts: - name: local-context context: cluster: local-cluster user: openshift-authenticator current-context: local-context kind: Config users: - name: openshift-authenticator user: client-certificate-data: LS0tLS1CRUdJTiBDRVJU... client-key-data: LS0tLS1CRUdJTiBFQyBQ... $ oc -n openshift-oauth-apiserver get svc NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE api ClusterIP 172.30.218.106 <none> 443/TCP 70d
  20. 26 Dynamic Admission Controllers ▸ Validating Webhook ・ リソース操作の正当性を確認 ▸

    OpenShift v4.9で設定されているValidating Webhook $ oc get ValidatingWebhookConfiguration NAME WEBHOOKS AGE autoscaling.openshift.io 2 70d cluster-baremetal-validating-webhook-configuration 1 70d multus.openshift.io 1 70d prometheusrules.openshift.io 1 70d snapshot.storage.k8s.io 1 70d vwb.performance.openshift.io-bx5xd 1 10d ▸ 例として “autoscaling.openshift.io” を見てみましょう
  21. 27 Dynamic Admission Controllers $ oc -n openshift-machine-api get ValidatingWebhookConfiguration/autoscaling.openshift.io

    -o yaml apiVersion: admissionregistration.k8s.io/v1 kind: ValidatingWebhookConfiguration metadata: ... labels: k8s-app: cluster-autoscaler-operator name: autoscaling.openshift.io ... webhooks: - admissionReviewVersions: - v1 clientConfig: caBundle: LS0tLS1CRUdJTiBDRVJU... service: name: cluster-autoscaler-operator namespace: openshift-machine-api path: /validate-clusterautoscalers port: 443 failurePolicy: Ignore matchPolicy: Equivalent name: clusterautoscalers.autoscaling.openshift.io namespaceSelector: {} objectSelector: {} rules: - apiGroups: - autoscaling.openshift.io apiVersions: - v1 operations: - CREATE $ oc -n openshift-machine-api get svc cluster-autoscaler-operator -o yaml apiVersion: v1 kind: Service metadata: ... name: cluster-autoscaler-operator namespace: openshift-machine-api ... spec: clusterIP: 172.30.54.30 clusterIPs: - 172.30.54.30 internalTrafficPolicy: Cluster ipFamilies: - IPv4 ipFamilyPolicy: SingleStack ports: - name: https port: 443 protocol: TCP targetPort: 8443 - name: metrics port: 9192 protocol: TCP targetPort: metrics selector: k8s-app: cluster-autoscaler-operator sessionAffinity: None type: ClusterIP ...
  22. 28 Dynamic Admission Controllers $ oc -n openshift-machine-api get pod

    -l k8s-app=cluster-autoscaler-operator NAME READY STATUS RESTARTS AGE cluster-autoscaler-operator-5d66d7697d-qmkmp 2/2 Running 10 70d $ oc -n openshift-machine-api exec cluster-autoscaler-operator-5d66d7697d-qmkmp -c cluster-autoscaler-operator -- ls /root/buildinfo Dockerfile-openshift-base-rhel8-v4.9.0-202111041612.p0.git.f17f552.assembly.stream Dockerfile-openshift-ose-base-v4.9.0-202111041612.p0.git.f93eca8.assembly.stream Dockerfile-openshift-ose-cluster-autoscaler-operator-v4.9.0-202111041612.p0.git.4a691 54.assembly.stream Dockerfile-ubi8-8.4-213 content_manifests
  23. 29 Dynamic Admission Controllers $ oc -n openshift-machine-api exec cluster-autoscaler-operator-5d66d7697d-qmkmp

    -c cluster-autoscaler-operator -- cat /root/buildinfo/Dockerfile-openshift-ose-cluster-autoscaler-operator-v4.9.0-202111041612.p0.git.4a69154.assembly.stream FROM sha256:ae68fcc9729f22bb6ad640bd7c8bbd88b9235d1b3c83c4e0ef2ea1783a727a5e AS builder ... SOURCE_GIT_COMMIT=4a6915434916fce27514541bf762bd7ea15a959c SOURCE_GIT_TAG=v0.0.0-370-g4a691543 SOURCE_GIT_URL=https://github.com/openshift/cluster-autoscaler-operator WORKDIR /go/src/github.com/openshift/cluster-autoscaler-operator COPY . . ENV NO_DOCKER=1 ENV BUILD_DEST=/go/bin/cluster-autoscaler-operator RUN unset VERSION && make build FROM sha256:071ca39744ebc14e20977fc4ba4b03c0ea3844f6e39533ad7114df6874d7b478 ... COPY --from=builder /go/bin/cluster-autoscaler-operator /usr/bin/ COPY --from=builder /go/src/github.com/openshift/cluster-autoscaler-operator/install /manifests CMD ["/usr/bin/cluster-autoscaler-operator"] ...
  24. 30 Custom Resource Definition + Custom Controller ▸ CRD: Custom

    Resource Definition ・ 独自のAPIリソースを追加する仕組み ・ CRDを追加することで、そのカスタムリソースを操作するためのREST APIエンドポイントがAPIサーバに 追加される ▸ Custom Controller ・ 追加したカスタムリソースをwatchし、current stateがdesired stateと異なるときはdesired stateになるよ うに働くコントローラ ・ Reconciliation Loop ▸ Operator ・ CRD + Custom Controllerをさらに発展させたもの ・ ソフトウェアの運用を自動化するためのロジックを組み込む ・ Operator Framework ・ Build: Operator SDK ・ Manage: Operator Lifecycle Manager ・ Discover: OperatorHub
  25. 31 Operator ▸ OpenShift v4はOperatorの固まり ・ 初期インストールやバージョンアップもOperatorの仕組みを使う ・ Cluster Version

    Operator ・ あらゆるパラメータはカスタムリソースとして設定する ・ 無理矢理手動で変更しても、Reconciliation Loopで戻される ・ ホストOS (RHCOS: Red Hat Enterprize Linux CoreOS) もOperatorで管理する ・ OSの設定変更もOperatorで管理する ・ OpenShiftのバージョンアップ処理の中で、OSのバージョンアップもOperatorから行う $ oc get ns | grep -E '^(openshift|kube-|default)' | wc -l 66 $ oc get pod -A | grep Running | grep ^openshift | wc -l 198
  26. 32 $ oc get clusteroperator NAME VERSION AVAILABLE PROGRESSING DEGRADED

    SINCE MESSAGE authentication 4.9.7 True False False 49d baremetal 4.9.7 True False False 70d cloud-controller-manager 4.9.7 True False False 70d cloud-credential 4.9.7 True False False 70d cluster-autoscaler 4.9.7 True False False 70d config-operator 4.9.7 True False False 70d console 4.9.7 True False False 49d csi-snapshot-controller 4.9.7 True False False 70d dns 4.9.7 True False False 55d etcd 4.9.7 True False False 70d image-registry 4.9.7 True False False 70d ingress 4.9.7 True False False 48d insights 4.9.7 True False False 70d kube-apiserver 4.9.7 True False False 70d kube-controller-manager 4.9.7 True False False 70d kube-scheduler 4.9.7 True False False 70d kube-storage-version-migrator 4.9.7 True False False 49d machine-api 4.9.7 True False False 70d machine-approver 4.9.7 True False False 70d machine-config 4.9.7 True False False 49d marketplace 4.9.7 True False False 70d monitoring 4.9.7 True False False 70d network 4.9.7 True False False 70d node-tuning 4.9.7 True False False 48d openshift-apiserver 4.9.7 True False False 44d openshift-controller-manager 4.9.7 True False False 10d openshift-samples 4.9.7 True False False 70d operator-lifecycle-manager 4.9.7 True False False 70d operator-lifecycle-manager-catalog 4.9.7 True False False 70d operator-lifecycle-manager-packageserver 4.9.7 True False False 70d service-ca 4.9.7 True False False 70d storage 4.9.7 True False False 70d Operator
  27. 33 API Aggregation ▸ CRDと同様、独自のAPIリソースを追加する仕組み ▸ CRDとの違い: kube-apiserverとは異なるAPIサーバで追加リソースを処理する ・ 追加リソースに対するREST

    APIが来ると、kube-apiserverはそのリクエストを追加APIサーバに転送す る ・ CRDよりも自由度が高い ・ CRDよりも実装が大変 $ oc get APIService | grep -v Local NAME SERVICE AVAILABLE AGE v1.apps.openshift.io openshift-apiserver/api True 70d v1.authorization.openshift.io openshift-apiserver/api True 70d v1.build.openshift.io openshift-apiserver/api True 70d v1.image.openshift.io openshift-apiserver/api True 70d v1.oauth.openshift.io openshift-oauth-apiserver/api True 70d v1.packages.operators.coreos.com openshift-operator-lifecycle-manager/packageserver-service True 70d v1.project.openshift.io openshift-apiserver/api True 70d v1.quota.openshift.io openshift-apiserver/api True 70d v1.route.openshift.io openshift-apiserver/api True 70d v1.security.openshift.io openshift-apiserver/api True 70d v1.template.openshift.io openshift-apiserver/api True 70d v1.user.openshift.io openshift-oauth-apiserver/api True 70d v1beta1.metrics.k8s.io openshift-monitoring/prometheus-adapter True 70d
  28. 34 API Aggregation $ oc get APIService v1.project.openshift.io -o yaml

    apiVersion: apiregistration.k8s.io/v1 kind: APIService metadata: annotations: service.alpha.openshift.io/inject-cabundle: "true" creationTimestamp: "2021-11-11T08:10:34Z" name: v1.project.openshift.io resourceVersion: "4888657" uid: 9548010a-d518-4f3a-b01b-c15f3fcbe76e spec: caBundle: LS0tLS1CRUdJTiBDRVJU... group: project.openshift.io groupPriorityMinimum: 9900 service: name: api namespace: openshift-apiserver port: 443 version: v1 versionPriority: 15 status: conditions: - lastTransitionTime: "2021-11-27T14:59:27Z" message: all checks passed reason: Passed status: "True" type: Available $ oc -n openshift-apiserver get svc/api -o json | jq -r '.spec.selector' { "apiserver": "true" } $ oc -n openshift-apiserver get pod -l apiserver=true NAME READY STATUS RESTARTS AGE apiserver-567667549c-dmbzs 2/2 Running 10 70d apiserver-567667549c-p78fx 2/2 Running 11 70d apiserver-567667549c-tp7tq 2/2 Running 2 49d
  29. 35 でもちょっと魔改造している例 (1) ▸ OpenShift v4のDNSの仕組み ・ 各ノードにDaemonSetでCoreDNSをデプロイし、それらへのsvc作成 (openshift-dns/dns-default) ・

    Podのresolv.confにはそのsvcのIPアドレスを設定 ▸ 問題 ・ ノード障害時、たまたまそのノードのCoreDNSにロードバランスされるとタイムアウト待ちになる! ・ https://bugzilla.redhat.com/show_bug.cgi?id=1919737 ▸ 修正 ・ https://github.com/openshift/sdn/pull/254/files#diff-d551a630b497a167d17ed8239bf8c4e74c8e 9f4e26d691bf97024f18f4becf67
  30. 37 でもちょっと魔改造している例 (2) ▸ Integrated OpenShift Registry: OpenShift上で稼動する内部コンテナレジストリ ・ ビルドしたコンテナイメージを格納する

    ・ upstream: https://docs.docker.com/registry/ ・ 一部サポートしないAPIがある (manifest list、image delete等) ・ image pruning等、追加ルートあり ・ イメージURLのパス構成要素は2個のみ (<namespace>/<imagestream>) ・ OpenShiftのOAuthサーバと連携 ・ Image pruning ・ イメージのGarbage Collection ・ upstreamはストレージ上のみ、内部レジストリはetcdの情報も掃除する必要がある ・ Image proxying / mirroring ・ イメージを持っていない場合、外部のレジストリから取ってきてキャッシュする機能 ・ upstreamは、Docker Hubからのみ可能、内部レジストリは、Docker Hub以外からもキャッシュでき るよう拡張
  31. 38 どれくらい魔改造しているか ▸ Docker Registryのコード ・ “Middleware” という仕組みで拡張可能になっている ・ https://github.com/distribution/distribution/blob/main/docs/configuration.md#middleware

    ・ HTTPハンドラをラップするとき等に使う、いわゆるミドルウェアパターンを意識している? ・ https://github.com/distribution/distribution/pull/235#issuecomment-77467710 ・ https://github.com/distribution/distribution/pull/244 ・ OpenShiftの内部レジストリはMiddlewareの仕組みを使って大幅に動きを変えている ・ 設定はこの辺り ・ https://github.com/openshift/image-registry/blob/release-4.9/images/dockerregistry/co nfig.yml#L15-L56 ブランチ .goファイル数 .goファイルの行数 (空行、コメント行は除く ) Docker Registry main 1362 433698 OpenShift内部レジストリ release-4.9 3796 958067
  32. 39 例: BlobStoreの拡張 (1) ▸ Docker Registryにおけるイメージレイヤーのデータ: ・ linkedBlobStore struct

    ▸ OpenShift内部レジストリではそれを拡張して... ・ quotaRestrictedBlobStore ・ Quota制限をかける ・ pullthroughBlobStore ・ Pullthroughできるようにする ・ pendingErrorsBlobStore ・ Authz + エラー確認 ・ auditBlogStore ・ Auditログ
  33. 43 ▸ Red Hatがいつも大切に思っていること: upstream first ・ 修正はまずupstreamに入れてから製品 (downstream) にバックポートする

    ▸ OpenShiftにおいても、Kubernetesに入れるべき機能に関してはupstream firstで頑張っています ・ 引き続きupstreamでKEP書いたり議論に参加したりコード書いたりしています いつも心にuptream firstを https://www.redhat.com/en/blog/what-open-source-upstream
  34. 44 Upstreamへの貢献 Operators Framework | ClusterRole Aggregation | RBAC Authorization

    | StatefulSets | Init Containers | Rolling Update Status | Pod Security Policy Limits | Memory based Pod Eviction | Quota Controlled Services | 1,000+ Nodes | Dynamic PV Provisioning | Multiple Schedulers | SECCOMP | Audit | Job Scheduler | Access Review API | Whitelisting Sysctls | Secure Cluster Policy | Evict Pods Disk IO | Storage Classes | Azure Data Disk | etcdv3 | RBAC API | Auth to kubelet API | Pod-level cGroups QoS | Kublet Eviction Model | RBAC | Storage Class | CustomResourceDefinitions | API Aggregation | Encrypted secrets in etcd | Limit Node Access | HPA Status Conditions | Network Policy | CRI Validation Test Suite | Local Persistent Storage | Audit Logging |
  35. 45 Red Hatが貢献した機能 (抜粋) 2016-07 1.3 RBAC authorization API group,

    PetSets, Init Containers, Rolling update status, Disk attach controllers on master, PSP limits, pod eviction based on memory, quota controlled loadBalancer services, quota controlled nodePorts, 1,000 Nodes, Dynamic Provision of PV, Multiple Schedulers in Parallel, Seccomp support 2016-09 1.4 Audit, Job Scheduler, Access Review API, Whitelisting sysctls, Default Secure Cluster Policy, Evict pods based on disk IO, Storage Classes, Azure Data Disk, etcd3, Init Containers 2016-12 1.5 StateFulSet, oc apply with a --prune will delete orphan resources, Deployment will say when they are blocked, RBAC API and default cluster roles, Authenticated/Authorized access to kubelet API, kublet honors user namspace mapping to the node , Pod level cgroups based on QoS of service tier, Responsiness of kublet eviction module 2017-03 1.6 RBAC with default enforced roles, StorageClass 2017-06 1.7 Kubernetes should be able to easily integrate external policy control, CustomResourceDefinitions, née ThirdPartyResources, API Aggregation, StatefulSets should support a burst mode for faster scale up / down ..., Encrypt secrets in etcd, Limit node access to API, HPA Status Conditions, NetworkPolicy, CRI validation test suite, Local Persistent Storage Support, Audit Logging for k8s
  36. 46 Red Hatが貢献した機能 (抜粋) 2017-09 1.8 Failure policy for Jobs,

    kubectl binary plugins, Further differentiate performance characteristics associated with pod level QoS, Priority/preemption, Add support for resizing PVs, Mount namespace propagation, CustomResourceDefinitions, née Third Party Resources, CronJob to beta, Arbitrary/Custom Metrics in the Horizontal Pod Autoscaler, Metrics Server & Master Metrics API, ReclaimPolicy in StorageClass, HPA Status Conditions, Monitoring Pipeline Metrics HPA API, Allow API to return large lists in chunks to improve responsiveness, Rules review API, RBAC v1, Add support for high level volume operation metrics, Support Volume Mount Options 2017-12 1.9 Support paged LIST queries from the Kubernetes API, CustomResourceDefinitions, née ThirdPartyResources, CronJobs (previously ScheduledJobs), ClusterRole aggregation, Add support for resizing PVs, Containerized mounts, Prevent deletion of Persistent Volume Claims that are used by a pod , Raw block device using persistent volume source 2018-03 1.10 API Aggregation, CronJobs (previously ScheduledJobs), Limit node access to API, Pod Security Policy , Support configurable pod resolv.conf, Kubelet's ComponentConfig API, Prevent deletion of Persistent Volume that is bound to a Persistent Volume Claim , Prevent deletion of Persistent Volume Claims that are used by a pod , Mount namespace propagation, Container Storage Interface, CRD subresources and categories, kubectl get and describe should work well with extensions 2018-06 1.11 Limit node access to API, Add support for resizing PVs, Add sysctl support, StorageObjectInUseProtection (was Persistent Volume Claim Protection), StorageObjectInUseProtection (was Persistent Volume Protection), ClusterRole Aggregation, Dynamic Maximum volume count, Add pod priority and preemption