一 部署 kubelet

kubelet 運行在每個 worker 節點上，接收 kube-apiserver 發送的請求，管理 Pod 容器，執行交互式命令，如 exec、run、logs 等。

kubelet 啟動時自動向 kube-apiserver 註冊節點信息，內置的 cadvisor 統計和監控節點的資源使用情況。

為確保安全，部署時關閉了 kubelet 的非安全 http 端口，對請求進行認證和授權，拒絕未授權的訪問(如 apiserver、heapster 的請求)。

1.1 安裝kubelet

提示：k8smaster01節點已下載相應二進制，可直接分發至node節點。

1.2 分發kubelet

  1 [root@k8smaster01 ~]# cd /opt/k8s/work
  2 [root@k8smaster01 work]# source /opt/k8s/bin/environment.sh
  3 [root@k8smaster01 work]# for all_ip in ${ALL_IPS[@]}
  4   do
  5     echo ">>> ${all_ip}"
  6     scp kubernetes/server/bin/kubelet root@${all_ip}:/opt/k8s/bin/
  7     ssh root@${all_ip} "chmod +x /opt/k8s/bin/*"
  8   done

1.3 分發kubeconfig

  1 [root@k8smaster01 ~]# cd /opt/k8s/work
  2 [root@k8smaster01 work]# source /opt/k8s/bin/environment.sh
  3 [root@k8smaster01 work]# for all_name in ${ALL_NAMES[@]}
  4   do
  5     echo ">>> ${all_name}"
  6 
  7     # 創建 token
  8     export BOOTSTRAP_TOKEN=$(kubeadm token create \
  9       --description kubelet-bootstrap-token \
 10       --groups system:bootstrappers:${all_name} \
 11       --kubeconfig ~/.kube/config)
 12 
 13     # 設置集群參數
 14     kubectl config set-cluster kubernetes \
 15       --certificate-authority=/etc/kubernetes/cert/ca.pem \
 16       --embed-certs=true \
 17       --server=${KUBE_APISERVER} \
 18       --kubeconfig=kubelet-bootstrap-${all_name}.kubeconfig
 19 
 20     # 設置客戶端認證參數
 21     kubectl config set-credentials kubelet-bootstrap \
 22       --token=${BOOTSTRAP_TOKEN} \
 23       --kubeconfig=kubelet-bootstrap-${all_name}.kubeconfig
 24 
 25     # 設置上下文參數
 26     kubectl config set-context default \
 27       --cluster=kubernetes \
 28       --user=kubelet-bootstrap \
 29       --kubeconfig=kubelet-bootstrap-${all_name}.kubeconfig
 30 
 31     # 設置默認上下文
 32     kubectl config use-context default --kubeconfig=kubelet-bootstrap-${all_name}.kubeconfig
 33   done

解釋：

向 kubeconfig 寫入的是 token，bootstrap 結束后 kube-controller-manager 為 kubelet 創建 client 和 server 證書。

token 有效期為 1 天，超期后將不能再被用來 boostrap kubelet，且會被 kube-controller-manager 的 tokencleaner 清理；

kube-apiserver 接收 kubelet 的 bootstrap token 后，將請求的 user 設置為 system:bootstrap:<Token ID>，group 設置為 system:bootstrappers，後續將為這個 group 設置 ClusterRoleBinding。

  1 [root@k8smaster01 work]# kubeadm token list --kubeconfig ~/.kube/config		#查看 kubeadm 為各節點創建的 token
  2 [root@k8smaster01 work]# kubectl get secrets  -n kube-system|grep bootstrap-token	#查看各 token 關聯的 Secret

1.5 分發bootstrap kubeconfig

  1 [root@k8smaster01 ~]# cd /opt/k8s/work
  2 [root@k8smaster01 work]# source /opt/k8s/bin/environment.sh
  3 [root@k8smaster01 work]# for all_name in ${ALL_NAMES[@]}
  4   do
  5     echo ">>> ${all_name}"
  6     scp kubelet-bootstrap-${all_name}.kubeconfig root@${all_name}:/etc/kubernetes/kubelet-bootstrap.kubeconfig
  7   done

1.6 創建kubelet 參數配置文件

從 v1.10 開始，部分 kubelet 參數需在配置文件中配置，建議創建kubelet配置文件。

  1 [root@k8smaster01 ~]# cd /opt/k8s/work
  2 [root@k8smaster01 work]# source /opt/k8s/bin/environment.sh
  3 [root@k8smaster01 work]# cat > kubelet-config.yaml.template <<EOF
  4 kind: KubeletConfiguration
  5 apiVersion: kubelet.config.k8s.io/v1beta1
  6 address: "##ALL_IP##"
  7 staticPodPath: ""
  8 syncFrequency: 1m
  9 fileCheckFrequency: 20s
 10 httpCheckFrequency: 20s
 11 staticPodURL: ""
 12 port: 10250
 13 readOnlyPort: 0
 14 rotateCertificates: true
 15 serverTLSBootstrap: true
 16 authentication:
 17   anonymous:
 18     enabled: false
 19   webhook:
 20     enabled: true
 21   x509:
 22     clientCAFile: "/etc/kubernetes/cert/ca.pem"
 23 authorization:
 24   mode: Webhook
 25 registryPullQPS: 0
 26 registryBurst: 20
 27 eventRecordQPS: 0
 28 eventBurst: 20
 29 enableDebuggingHandlers: true
 30 enableContentionProfiling: true
 31 healthzPort: 10248
 32 healthzBindAddress: "##ALL_IP##"
 33 clusterDomain: "${CLUSTER_DNS_DOMAIN}"
 34 clusterDNS:
 35   - "${CLUSTER_DNS_SVC_IP}"
 36 nodeStatusUpdateFrequency: 10s
 37 nodeStatusReportFrequency: 1m
 38 imageMinimumGCAge: 2m
 39 imageGCHighThresholdPercent: 85
 40 imageGCLowThresholdPercent: 80
 41 volumeStatsAggPeriod: 1m
 42 kubeletCgroups: ""
 43 systemCgroups: ""
 44 cgroupRoot: ""
 45 cgroupsPerQOS: true
 46 cgroupDriver: cgroupfs
 47 runtimeRequestTimeout: 10m
 48 hairpinMode: promiscuous-bridge
 49 maxPods: 220
 50 podCIDR: "${CLUSTER_CIDR}"
 51 podPidsLimit: -1
 52 resolvConf: /etc/resolv.conf
 53 maxOpenFiles: 1000000
 54 kubeAPIQPS: 1000
 55 kubeAPIBurst: 2000
 56 serializeImagePulls: false
 57 evictionHard:
 58   memory.available:  "100Mi"
 59 nodefs.available:  "10%"
 60 nodefs.inodesFree: "5%"
 61 imagefs.available: "15%"
 62 evictionSoft: {}
 63 enableControllerAttachDetach: true
 64 failSwapOn: true
 65 containerLogMaxSize: 20Mi
 66 containerLogMaxFiles: 10
 67 systemReserved: {}
 68 kubeReserved: {}
 69 systemReservedCgroup: ""
 70 kubeReservedCgroup: ""
 71 enforceNodeAllocatable: ["pods"]
 72 EOF

1.7 分發kubelet 參數配置文件

  1 [root@k8smaster01 ~]# cd /opt/k8s/work
  2 [root@k8smaster01 work]# source /opt/k8s/bin/environment.sh
  3 [root@k8smaster01 work]# for all_ip in ${ALL_IPS[@]}
  4   do
  5     echo ">>> ${all_ip}"
  6     sed -e "s/##ALL_IP##/${all_ip}/" kubelet-config.yaml.template > kubelet-config-${all_ip}.yaml.template
  7     scp kubelet-config-${all_ip}.yaml.template root@${all_ip}:/etc/kubernetes/kubelet-config.yaml
  8   done

1.8 創建kubelet systemd

  1 [root@k8smaster01 ~]# cd /opt/k8s/work
  2 [root@k8smaster01 work]# source /opt/k8s/bin/environment.sh
  3 [root@k8smaster01 work]# cat > kubelet.service.template <<EOF
  4 [Unit]
  5 Description=Kubernetes Kubelet
  6 Documentation=https://github.com/GoogleCloudPlatform/kubernetes
  7 After=docker.service
  8 Requires=docker.service
  9 
 10 [Service]
 11 WorkingDirectory=${K8S_DIR}/kubelet
 12 ExecStart=/opt/k8s/bin/kubelet \\
 13   --allow-privileged=true \\
 14   --bootstrap-kubeconfig=/etc/kubernetes/kubelet-bootstrap.kubeconfig \\
 15   --cert-dir=/etc/kubernetes/cert \\
 16   --cni-conf-dir=/etc/cni/net.d \\
 17   --container-runtime=docker \\
 18   --container-runtime-endpoint=unix:///var/run/dockershim.sock \\
 19   --root-dir=${K8S_DIR}/kubelet \\
 20   --kubeconfig=/etc/kubernetes/kubelet.kubeconfig \\
 21   --config=/etc/kubernetes/kubelet-config.yaml \\
 22   --hostname-override=##ALL_NAME## \\
 23   --pod-infra-container-image=registry.cn-beijing.aliyuncs.com/k8s_images/pause-amd64:3.1 \\
 24   --image-pull-progress-deadline=15m \\
 25   --volume-plugin-dir=${K8S_DIR}/kubelet/kubelet-plugins/volume/exec/ \\
 26   --logtostderr=true \\
 27   --v=2
 28 Restart=always
 29 RestartSec=5
 30 StartLimitInterval=0
 31 
 32 [Install]
 33 WantedBy=multi-user.target
 34 EOF

解釋：

• 如果設置了 –hostname-override 選項，則 kube-proxy 也需要設置該選項，否則會出現找不到 Node 的情況；
• –bootstrap-kubeconfig：指向 bootstrap kubeconfig 文件，kubelet 使用該文件中的用戶名和 token 向 kube-apiserver 發送 TLS Bootstrapping 請求；
• K8S approve kubelet 的 csr 請求后，在 –cert-dir 目錄創建證書和私鑰文件，然後寫入 –kubeconfig 文件；
• –pod-infra-container-image 不使用 redhat 的 pod-infrastructure:latest 鏡像，它不能回收容器的殭屍。

1.9 分發kubelet systemd

  1 [root@k8smaster01 ~]# cd /opt/k8s/work
  2 [root@k8smaster01 work]# source /opt/k8s/bin/environment.sh
  3 [root@k8smaster01 work]# for all_name in ${ALL_NAMES[@]}
  4   do
  5     echo ">>> ${all_name}"
  6     sed -e "s/##ALL_NAME##/${all_name}/" kubelet.service.template > kubelet-${all_name}.service
  7     scp kubelet-${all_name}.service root@${all_name}:/etc/systemd/system/kubelet.service
  8   done

二 啟動驗證

2.1 授權

kubelet 啟動時查找 –kubeletconfig 參數對應的文件是否存在，如果不存在則使用 –bootstrap-kubeconfig 指定的 kubeconfig 文件向 kube-apiserver 發送證書籤名請求 (CSR)。

kube-apiserver 收到 CSR 請求后，對其中的 Token 進行認證，認證通過後將請求的 user 設置為 system:bootstrap:<Token ID>，group 設置為 system:bootstrappers，這一過程稱為 Bootstrap Token Auth。

默認情況下，這個 user 和 group 沒有創建 CSR 的權限，因此kubelet 會啟動失敗，可通過如下方式創建一個 clusterrolebinding，將 group system:bootstrappers 和 clusterrole system:node-bootstrapper 綁定。

  1 [root@k8smaster01 ~]#  kubectl create clusterrolebinding kubelet-bootstrap --clusterrole=system:node-bootstrapper --group=system:bootstrappers

2.2 啟動kubelet

  1 [root@k8smaster01 ~]# source /opt/k8s/bin/environment.sh
  2 [root@k8smaster01 ~]# for all_name in ${ALL_NAMES[@]}
  3   do
  4     echo ">>> ${all_name}"
  5     ssh root@${all_name} "mkdir -p ${K8S_DIR}/kubelet/kubelet-plugins/volume/exec/"
  6     ssh root@${all_name} "/usr/sbin/swapoff -a"
  7     ssh root@${all_name} "systemctl daemon-reload && systemctl enable kubelet && systemctl restart kubelet"
  8   done

kubelet 啟動后使用 –bootstrap-kubeconfig 向 kube-apiserver 發送 CSR 請求，當這個 CSR 被 approve 后，kube-controller-manager 為 kubelet 創建 TLS 客戶端證書、私鑰和 –kubeletconfig 文件。

注意：kube-controller-manager 需要配置 –cluster-signing-cert-file 和 –cluster-signing-key-file 參數，才會為 TLS Bootstrap 創建證書和私鑰。

提示：

啟動服務前必須先創建工作目錄；

關閉 swap 分區，否則 kubelet 會啟動失敗。

2.3 查看kubelet服務

  1 [root@k8smaster01 ~]# source /opt/k8s/bin/environment.sh
  2 [root@k8smaster01 ~]# for all_name in ${ALL_NAMES[@]}
  3   do
  4     echo ">>> ${all_name}"
  5     ssh root@${all_name} "systemctl status kubelet"
  6   done
  7 [root@k8snode01 ~]# kubectl get csr
  8 [root@k8snode01 ~]# kubectl get nodes

三 approve CSR 請求

3.1 自動 approve CSR 請求

創建三個 ClusterRoleBinding，分別用於自動 approve client、renew client、renew server 證書。

  1 [root@k8snode01 ~]# cd /opt/k8s/work
  2 [root@k8snode01 work]# cat > csr-crb.yaml <<EOF
  3  # Approve all CSRs for the group "system:bootstrappers"
  4  kind: ClusterRoleBinding
  5  apiVersion: rbac.authorization.k8s.io/v1
  6  metadata:
  7    name: auto-approve-csrs-for-group
  8  subjects:
  9  - kind: Group
 10    name: system:bootstrappers
 11    apiGroup: rbac.authorization.k8s.io
 12  roleRef:
 13    kind: ClusterRole
 14    name: system:certificates.k8s.io:certificatesigningrequests:nodeclient
 15    apiGroup: rbac.authorization.k8s.io
 16 ---
 17  # To let a node of the group "system:nodes" renew its own credentials
 18  kind: ClusterRoleBinding
 19  apiVersion: rbac.authorization.k8s.io/v1
 20  metadata:
 21    name: node-client-cert-renewal
 22  subjects:
 23  - kind: Group
 24    name: system:nodes
 25    apiGroup: rbac.authorization.k8s.io
 26  roleRef:
 27    kind: ClusterRole
 28    name: system:certificates.k8s.io:certificatesigningrequests:selfnodeclient
 29    apiGroup: rbac.authorization.k8s.io
 30 ---
 31 # A ClusterRole which instructs the CSR approver to approve a node requesting a
 32 # serving cert matching its client cert.
 33 kind: ClusterRole
 34 apiVersion: rbac.authorization.k8s.io/v1
 35 metadata:
 36   name: approve-node-server-renewal-csr
 37 rules:
 38 - apiGroups: ["certificates.k8s.io"]
 39   resources: ["certificatesigningrequests/selfnodeserver"]
 40   verbs: ["create"]
 41 ---
 42  # To let a node of the group "system:nodes" renew its own server credentials
 43  kind: ClusterRoleBinding
 44  apiVersion: rbac.authorization.k8s.io/v1
 45  metadata:
 46    name: node-server-cert-renewal
 47  subjects:
 48  - kind: Group
 49    name: system:nodes
 50    apiGroup: rbac.authorization.k8s.io
 51  roleRef:
 52    kind: ClusterRole
 53    name: approve-node-server-renewal-csr
 54    apiGroup: rbac.authorization.k8s.io
 55 EOF
 56 [root@k8snode01 work]# kubectl apply -f csr-crb.yaml

解釋：

auto-approve-csrs-for-group：自動 approve node 的第一次 CSR； 注意第一次 CSR 時，請求的 Group 為 system:bootstrappers；

node-client-cert-renewal：自動 approve node 後續過期的 client 證書，自動生成的證書 Group 為 system:nodes;

node-server-cert-renewal：自動 approve node 後續過期的 server 證書，自動生成的證書 Group 為 system:nodes。

3.2 查看 kubelet 的情況

  1 [root@k8snode01 ~]# kubectl get csr | grep boot		#等待一段時間(1-10 分鐘)，三個節點的 CSR 都被自動 approved
  2 [root@k8snode01 ~]# kubectl get nodes			#所有節點均 ready
  3 [root@k8snode01 ~]# ls -l /etc/kubernetes/kubelet.kubeconfig
  4 [root@k8snode01 ~]# ls -l /etc/kubernetes/cert/|grep kubelet

3.3 手動 approve server cert csr

基於安全性考慮，CSR approving controllers 不會自動 approve kubelet server 證書籤名請求，需要手動 approve。

  1 [root@k8smaster01 ~]# kubectl get csr
  2 [root@k8smaster01 ~]# kubectl certificate approve csr-2kmtj
  3 

  1 [root@k8smaster01 ~]# ls -l /etc/kubernetes/cert/kubelet-*

四 kubelet API 接口

4.1 kubelet 提供的 API 接口

  1 [root@k8smaster01 ~]# sudo netstat -lnpt|grep kubelet			#查看kubelet監聽端口

解釋：

• 10248: healthz http 服務；
• 10250: https 服務，訪問該端口時需要認證和授權（即使訪問 /healthz 也需要）；
• 未開啟只讀端口 10255；
• 從 K8S v1.10 開始，去除了 –cadvisor-port 參數（默認 4194 端口），不支持訪問 cAdvisor UI & API。

4.2 kubelet api 認證和授權

kubelet 配置了如下認證參數：

• authentication.anonymous.enabled：設置為 false，不允許匿名�訪問 10250 端口；
• authentication.x509.clientCAFile：指定簽名客戶端證書的 CA 證書，開啟 HTTPs 證書認證；
• authentication.webhook.enabled=true：開啟 HTTPs bearer token 認證。

同時配置了如下授權參數：

authroization.mode=Webhook：開啟 RBAC 授權。




kubelet 收到請求后，使用 clientCAFile 對證書籤名進行認證，或者查詢 bearer token 是否有效。如果兩者都沒通過，則拒絕請求，提示 Unauthorized。

  1 [root@k8smaster01 ~]# curl -s --cacert /etc/kubernetes/cert/ca.pem https://172.24.8.71:10250/metrics   
  2 Unauthorized[root@k8smaster01 ~]#
  3 [root@k8smaster01 ~]# curl -s --cacert /etc/kubernetes/cert/ca.pem -H "Authorization: Bearer 123456" https://172.24.8.71:10250/metrics   
  4 Unauthorized

若通過認證后，kubelet 使用 SubjectAccessReview API 向 kube-apiserver 發送請求，查詢證書或 token 對應的 user、group 是否有操作資源的權限(RBAC)。

4.3 證書認證和授權

  1 [root@k8smaster01 ~]# curl -s --cacert /etc/kubernetes/cert/ca.pem --cert /etc/kubernetes/cert/kube-controller-manager.pem --key /etc/kubernetes/cert/kube-controller-manager-key.pem https://172.24.8.71:10250/metrics	#默認權限不足
  2 Forbidden (user=system:kube-controller-manager, verb=get, resource=nodes, subresource=metrics)
  3 curl -s --cacert /etc/kubernetes/cert/ca.pem --cert /opt/k8s/work/admin.pem --key /opt/k8s/work/admin-key.pem https://172.24.8.71:10250/metrics|head				#使用最高權限的admin

解釋：

–cacert、–cert、–key 的參數值必須是文件路徑，如上面的 ./admin.pem 不能省略 ./，否則返回 401 Unauthorized。

4.4 創建bear token 認證和授權

  1 [root@k8smaster01 ~]# kubectl create sa kubelet-api-test
  2 [root@k8smaster01 ~]# kubectl create clusterrolebinding kubelet-api-test --clusterrole=system:kubelet-api-admin --serviceaccount=default:kubelet-api-test
  3 [root@k8smaster01 ~]# SECRET=$(kubectl get secrets | grep kubelet-api-test | awk '{print $1}')
  4 [root@k8smaster01 ~]# TOKEN=$(kubectl describe secret ${SECRET} | grep -E '^token' | awk '{print $2}')
  5 [root@k8smaster01 ~]# echo ${TOKEN}

  1 [root@k8smaster01 ~]# curl -s --cacert /etc/kubernetes/cert/ca.pem -H "Authorization: Bearer ${TOKEN}" https://172.24.8.71:10250/metrics|head

4.5 cadvisor 和 metrics

cadvisor 是內嵌在 kubelet 二進制中的，統計所在節點各容器的資源(CPU、內存、磁盤、網卡)使用情況的服務。

瀏覽器訪問 https://172.24.8.71:10250/metrics 和 https://172.24.8.71:10250/metrics/cadvisor 分別返回 kubelet 和 cadvisor 的 metrics。

注意：

kubelet.config.json 設置 authentication.anonymous.enabled 為 false，不允許匿名證書訪問 10250 的 https 服務；

參考https://github.com/opsnull/follow-me-install-kubernetes-cluster/blob/master/A.%E6%B5%8F%E8%A7%88%E5%99%A8%E8%AE%BF%E9%97%AEkube-apiserver%E5%AE%89%E5%85%A8%E7%AB%AF%E5%8F%A3.md，創建和導入相關證書，然後訪問上面的 10250 端口。本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理
【其他文章推薦】

※為什麼 USB CONNECTOR 是電子產業重要的元件?

※網頁設計一頭霧水??該從何著手呢? 找到專業技術的網頁設計公司，幫您輕鬆架站!

※想要讓你的商品成為最夯、最多人討論的話題?網頁設計公司讓你強力曝光

※想知道最厲害的台北網頁設計公司推薦、台中網頁設計公司推薦專業設計師”嚨底家”!!

※專營大陸快遞台灣服務

※台灣快遞大陸的貨運公司有哪些呢?

上一篇文章寫了一個簡易版的螞蟻莊園登山賽，有小夥伴留言說想要看星星球的，那麼就寫起來吧！

效果預覽

配置環境 cocos creator 3d 1.0.0

小球點擊

3d里節點無法用 cc.Node.EventType.TOUCH_START 監聽。最終在論壇上找到一個 raycast 解決方法。參考代碼如下。

start() {
    systemEvent.on(SystemEventType.TOUCH_START, this.onClickBall, this);
}
private _ray = new geometry.ray();
private onClickBall(touch: Touch, event: EventTouch) {
    const pos = touch.getLocation();
    this.camera.screenPointToRay(pos.x, pos.y, this._ray);
    const result: { node: Node }[] = this.node_ball_click.scene.renderScene['raycast'](this._ray);
    if (result.some((i) => {
        if (i.node === this.node_ball_click) {
            return true;
        }
    })) {
        //點擊到小球處理邏輯
    }
}

其中 result 返回的是一個包含node節點的結果數組。獲取后需要判斷一下是否為小球節點。

據說這個方案消耗性能比較大，後續應該會有更好的解決方案。

動畫系統

採用了編輯器的動畫編輯器，對需要部分增加動畫效果。由於我的資源是網上找的，那隻雞有些身體部分切割的不好，所以小雞的動畫比較差一些。

需要注意的是動畫編輯器里的rotation屬性，與節點里的屬性面板的rotation對應不上，而應該採用eulerAngles的屬性。

據說後續版本會處理？

小球軌跡

採用tween控制小球坐標數值，先移動到最高點，然後再移動到最低點。

在運動軌跡中加入一些隨機值，就可以達到不同位置的效果啦。

tweenUtil(this._node_balll_pos)
    .stop()
    .to(time, new math.Vec3((this.node_ball.position.x + BALL_INIT_X) / 2, BALL_MAX_Y * (0.8 + 0.2 * Math.random()), targetZ / 2))
    .to(time, new math.Vec3(BALL_GAMEOVER_X, BALL_MIN_Y, targetZ))
    .start();

小結

完成這個小功能主要遇到的問題是3d節點點擊事件，和動畫系統的rotation的問題。不過這些都在論壇里找到了相應的解決方法。

以上就是我最新的學習成果！如有問題或新的想法歡迎留言！我有了好想法會第一時間分享給大家的！

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理
【其他文章推薦】

※為什麼 USB CONNECTOR 是電子產業重要的元件?

※網頁設計一頭霧水??該從何著手呢? 找到專業技術的網頁設計公司，幫您輕鬆架站!

※想要讓你的商品成為最夯、最多人討論的話題?網頁設計公司讓你強力曝光

※想知道最厲害的台北網頁設計公司推薦、台中網頁設計公司推薦專業設計師”嚨底家”!!

※專營大陸快遞台灣服務

※台灣快遞大陸的貨運公司有哪些呢?

參考

https://git-scm.com/book/zh/v2/Git-%E5%B7%A5%E5%85%B7-%E9%87%8D%E7%BD%AE%E6%8F%AD%E5%AF%86

https://git-scm.com/book/en/v2/Git-Tools-Reset-Demystified

https://git-scm.com/docs/git-reset

https://www.liaoxuefeng.com/wiki/896043488029600/897013573512192

從歷史記錄中刪除 參考 https://www.cnblogs.com/studywithallofyou/p/11772684.html https://www.cnblogs.com/studywithallofyou/p/11772844.html

前言

在使用git的時候，我們一般提倡是不允許回滾。對於問題的追蹤和項目的發展歷程而言歷史記錄都是有用的。並且為了節省一點存儲空間而丟失寶貴的代碼信息是不值當的。但是我們開發中，肯定會遇到特殊情況需要回退。比如確實操作錯了一步歷史提交，導致倉庫混亂污染或是內容丟失，我們需要回退到乾淨的一次提交，重新操作。

在git等所有的版本管理軟件中，刪除操作，只是增加一次記錄，內容並不會被刪掉，我們可以大膽的操作，這也符合版本倉庫的邏輯。只有特殊情況才需要真正的刪除，做這種操作的時候需要特別注意，因為一旦失誤，無法挽回。

工作流程

要想理解git reset，那麼就要搞清楚git倉庫管理流程：

我們修改完內容后，這些記錄單單是保存在我們本地目錄下，也就是工作目錄。如果丟了，就是丟了，無法找回。與普通磁盤上的文件一樣，除非到回收站找回。

這時，如果運行了add，那麼內容就被記錄到本地的暫存倉庫，也就是index。這時如果刪除文件，在暫存區的內容還存在，並沒有丟失。

如下圖，我們創建了一個文件4，這時文件4在本地。我們add到暫存倉庫，然後刪掉文件4，我們發現又多了一條記錄刪除記錄，原來的4還存在，我們可以commit。原來的文件4並沒有丟失。

運行commit之後，修改的內容就被保存到了倉庫，修改了HEAD（HEAD就是指向當前倉庫在哪一個提交歷史，不特殊修改，都指向最新的一次提交）。這時運行git status發現目錄是乾淨的。git裏面需要提交倉庫，暫存倉庫和本地目錄內容都完全一致，才是乾淨的，任何一個不一致都會有不同的提示。

比如上面的圖，提交的倉庫中沒有文件4，暫存倉庫中增加了4，所以显示綠色的提示內容，add了文件但是還沒有commit。但是本次又刪除了文件，本地目錄中的內容與暫存倉庫也不一樣，所以提示紅色的內容，因為算是警告，沒有add的內容是會丟失的。

修改

add

commit

git reset的三個選擇

理解了上面的流程，就可以理解git reset了。git reset就是分別逆向操作，也就是把HEAD（提交的倉庫）回退到一個指定歷史，把HEAD、index（暫存倉庫）都回退到指定歷史，把HEAD、index和本地目錄的內容都回退到一個指定歷史。

git reset –soft就是把HEAD回退到指定歷史。運行后結果如下

也就相當於我們add了修改的文件，本地目錄和暫存倉庫都已經一致了，就等待commit。如果我們commit，可以再次填寫commit記錄，也就實現了git commit –amend的功能。

git reset –mixed就是把HEAD和index都回退到指定的歷史。這個也是運行git reset不加參數時的默認規則。運行結果如下

相當於我們僅僅修改了文件，還沒做任何處理。

git reset –hard這個是把HEAD、index和本地目錄的內容都回退到指定的歷史記錄。做這一步操作的時候一定要小心，最好把所有的內容都提交，並且push到遠程或是拷貝一份。因為這個操作會重置本地的內容到一個指定歷史。

我們先運行git log，看到有三個提交歷史

運行git reset –hard HEAD~

我們發現倉庫是乾淨的，並且原來的3文件沒了，運行git log參看

提交的歷史記錄也沒有了。

這次是真的回退到了指定歷史，所有的記錄都不見了，我們可以開心的（真的嗎？）在原來一個乾淨的分支上繼續寫代碼了。

git reset –hard的後悔葯

世上有沒有後悔葯我不知道，但是git作為一個先進的分佈式管理器，卻有無限可能。如果你一不小心，腦袋發熱，運行了git reset –hard，但是發現不是你想要的，原來的記錄也沒了。怎麼辦？大腦瞬間充血，一片空白。不要慌，首先冷靜下來，然後運行git reflog，這個命令是告訴你你的每一次對倉庫操作的歷史記錄，如下

看一下最上面的幾條，第一條告訴你當前在e86d948這個提交記錄，通過reset切換過來的。對照上面的git log，可以發現這個是第二個提交歷史，也就是我們git reset –hard HEAD~的時候回退的分支。第二條記錄告訴我們當前是fc9fbc6分支，通過reset回退到這個分支的，我們可以參考上面的git log記錄，這個就是我們想要回去的分支。好了，有了記錄的哈希值，我們只需再運行一次git reset –hard，如下

查看一下git log

回來了。

git不會刪除任何已經提交到版本庫的內容，除非你非要專門特殊這樣做，並且為了再給你一次機會，像git reset這樣，就算你明確說明不要了，它也不會立馬刪除，除非超過一定時間或是你主動運行git gc等操作，把無用的，沒有關聯的內容刪掉。不然，那條記錄還是在本地倉庫，只不過它沒有被載入歷史的長河中。

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理
【其他文章推薦】

※為什麼 USB CONNECTOR 是電子產業重要的元件?

※網頁設計一頭霧水??該從何著手呢? 找到專業技術的網頁設計公司，幫您輕鬆架站!

※想要讓你的商品成為最夯、最多人討論的話題?網頁設計公司讓你強力曝光

※想知道最厲害的台北網頁設計公司推薦、台中網頁設計公司推薦專業設計師”嚨底家”!!

※專營大陸快遞台灣服務

※台灣快遞大陸的貨運公司有哪些呢?

故事背景

最近在把自己的一個老項目從Framework遷移到.Net Core 3.0，數據訪問這塊選擇的是EFCore+Mysql。使用EF的話不可避免要和DbContext打交道，在Core中的常規用法一般是：創建一個XXXContext類繼承自DbContext，實現一個擁有DbContextOptions參數的構造器，在啟動類StartUp中的ConfigureServices方法里調用IServiceCollection的擴展方法AddDbContext，把上下文注入到DI容器中，然後在使用的地方通過構造函數的參數獲取實例。OK，沒任何毛病，官方示例也都是這麼來用的。但是，通過構造函數這種方式來獲取上下文實例其實很不方便，比如在Attribute或者靜態類中，又或者是系統啟動時初始化一些數據，更多的是如下一種場景：

    public class BaseController : Controller
    {
        public BloggingContext _dbContext;
        public BaseController(BloggingContext dbContext)
        {
            _dbContext = dbContext;
        }

        public bool BlogExist(int id)
        {
            return _dbContext.Blogs.Any(x => x.BlogId == id);
        }
    }

    public class BlogsController : BaseController
    {
        public BlogsController(BloggingContext dbContext) : base(dbContext) { }
    }

從上面的代碼可以看到，任何要繼承BaseController的類都要寫一個“多餘”的構造函數，如果參數再多幾個，這將是無法忍受的（就算只有一個參數我也忍受不了）。那麼怎樣才能更優雅的獲取數據庫上下文實例呢，我想到以下幾種辦法。

DbContext從哪來

1、  直接開溜new

回歸原始，既然要創建實例，沒有比直接new一個更好的辦法了，在Framework中沒有DI的時候也差不多都這麼干。但在EFCore中不同的是，DbContext不再提供無參構造函數，取而代之的是必須傳入一個DbContextOptions類型的參數，這個參數通常是做一些上下文選項配置例如使用什麼類型數據庫連接字符串是多少。

        public BloggingContext(DbContextOptions<BloggingContext> options) : base(options)
        {
        }

默認情況下，我們已經在StartUp中註冊上下文的時候做了配置，DI容器會自動幫我們把options傳進來。如果要手動new一個上下文，那豈不是每次都要自己傳？不行，這太痛苦了。那有沒有辦法不傳這個參數？肯定也是有的。我們可以去掉有參構造函數，然後重寫DbContext中的OnConfiguring方法，在這個方法中做數據庫配置： 

        protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
        {
            optionsBuilder.UseSqlite("Filename=./efcoredemo.db");
        }

即使是這樣，依然有不夠優雅的地方，那就是連接字符串被硬編碼在代碼中，不能做到從配置文件讀取。反正我忍受不了，只能再尋找其他方案。

2、  從DI容器手動獲取

既然前面已經在啟動類中註冊了上下文，那麼從DI容器中獲取實例肯定是沒問題的。於是我寫了這樣一句測試代碼用來驗證猜想：

　　　　var context = app.ApplicationServices.GetService<BloggingContext>();

不過很遺憾拋出了異常：

報錯信息說的很明確，不能從root provider中獲取這個服務。我從G站下載了DI框架的源碼（地址是），拿報錯信息進行反向追溯，發現異常來自於CallSiteValidator類的ValidateResolution方法：

        public void ValidateResolution(Type serviceType, IServiceScope scope, IServiceScope rootScope)
        {
            if (ReferenceEquals(scope, rootScope)
                && _scopedServices.TryGetValue(serviceType, out var scopedService))
            {
                if (serviceType == scopedService)
                {
                    throw new InvalidOperationException(
                        Resources.FormatDirectScopedResolvedFromRootException(serviceType,
                            nameof(ServiceLifetime.Scoped).ToLowerInvariant()));
                }

                throw new InvalidOperationException(
                    Resources.FormatScopedResolvedFromRootException(
                        serviceType,
                        scopedService,
                        nameof(ServiceLifetime.Scoped).ToLowerInvariant()));
            }
        }

View Code

繼續往上，看到了GetService方法的實現：

        internal object GetService(Type serviceType, ServiceProviderEngineScope serviceProviderEngineScope)
        {
            if (_disposed)
            {
                ThrowHelper.ThrowObjectDisposedException();
            }

            var realizedService = RealizedServices.GetOrAdd(serviceType, _createServiceAccessor);
            _callback?.OnResolve(serviceType, serviceProviderEngineScope);
            DependencyInjectionEventSource.Log.ServiceResolved(serviceType);
            return realizedService.Invoke(serviceProviderEngineScope);
        }

View Code

可以看到，_callback在為空的情況下是不會做驗證的，於是猜想有參數能對它進行配置。把追溯對象換成_callback繼續往上翻，在DI框架的核心類ServiceProvider中找到如下方法：

        internal ServiceProvider(IEnumerable<ServiceDescriptor> serviceDescriptors, ServiceProviderOptions options)
        {
            IServiceProviderEngineCallback callback = null;
            if (options.ValidateScopes)
            {
                callback = this;
                _callSiteValidator = new CallSiteValidator();
            }
            //省略....
        }    

說明我的猜想沒錯，驗證是受ValidateScopes控制的。這樣來看，把ValidateScopes設置成False就可以解決了，這也是網上普遍的解決方案：

      .UseDefaultServiceProvider(options =>
       {
              options.ValidateScopes = false;
       })

但這樣做是極其危險的。

為什麼危險？到底什麼是root provider？那就要從原生DI的生命周期說起。我們知道，DI容器被封裝成一個IServiceProvider對象，服務都是從這裏來獲取。不過這並不是一個單一對象，它是具有層級結構的，最頂層的即前面提到的root provider，可以理解為僅屬於系統層面的DI控制中心。在Asp.Net Core中，內置的DI有3種服務模式，分別是Singleton、Transient、Scoped，Singleton服務實例是保存在root provider中的，所以它才能做到全局單例。相對應的Scoped，是保存在某一個provider中的，它能保證在這個provider中是單例的，而Transient服務則是隨時需要隨時創建，用完就丟棄。由此可知，除非是在root provider中獲取一個單例服務，否則必須要指定一個服務範圍（Scope），這個驗證是通過ServiceProviderOptions的ValidateScopes來控制的。默認情況下，Asp.Net Core框架在創建HostBuilder的時候會判定當前是否開發環境，在開發環境下會開啟這個驗證：

所以前面那種關閉驗證的方式是錯誤的。這是因為，root provider只有一個，如果恰好有某個singleton服務引用了一個scope服務，這會導致這個scope服務也變成singleton，仔細看一下註冊DbContext的擴展方法，它實際上提供的是scope服務：

如果發生這種情況，數據庫連接會一直得不到釋放，至於有什麼後果大家應該都明白。

所以前面的測試代碼應該這樣寫：

     using (var serviceScope = app.ApplicationServices.CreateScope())
     {
         var context = serviceScope.ServiceProvider.GetService<BloggingContext>();
     }

與之相關的還有一個ValidateOnBuild屬性，也就是說在構建IServiceProvider的時候就會做驗證，從源碼中也能體現出來：

            if (options.ValidateOnBuild)
            {
                List<Exception> exceptions = null;
                foreach (var serviceDescriptor in serviceDescriptors)
                {
                    try
                    {
                        _engine.ValidateService(serviceDescriptor);
                    }
                    catch (Exception e)
                    {
                        exceptions = exceptions ?? new List<Exception>();
                        exceptions.Add(e);
                    }
                }

                if (exceptions != null)
                {
                    throw new AggregateException("Some services are not able to be constructed", exceptions.ToArray());
                }
            }

View Code

正因為如此，Asp.Net Core在設計的時候為每個請求創建獨立的Scope，這個Scope的provider被封裝在HttpContext.RequestServices中。

 [小插曲]

通過代碼提示可以看到，IServiceProvider提供了2種獲取service的方式：

這2個有什麼區別呢？分別查看各自的方法摘要可以看到，通過GetService獲取一個沒有註冊的服務時會返回null，而GetRequiredService會拋出一個InvalidOperationException，僅此而已。

        // 返回結果:
        //     A service object of type T or null if there is no such service.
        public static T GetService<T>(this IServiceProvider provider);

        // 返回結果:
        //     A service object of type T.
        //
        // 異常:
        //   T:System.InvalidOperationException:
        //     There is no service of type T.
        public static T GetRequiredService<T>(this IServiceProvider provider);

終極大招

到現在為止，儘管找到了一種看起來合理的方案，但還是不夠優雅，使用過其他第三方DI框架的朋友應該知道，屬性注入的快感無可比擬。那原生DI有沒有實現這個功能呢，我滿心歡喜上G站搜Issue，看到這樣一個回復（）：

官方明確表示沒有開發屬性注入的計劃，沒辦法，只能靠自己了。

我的思路大概是：創建一個自定義標籤（Attribute），用來給需要注入的屬性打標籤，然後寫一個服務激活類，用來解析給定實例需要注入的屬性並賦值，在某個類型被創建實例的時候也就是構造函數中調用這個激活方法實現屬性注入。這裡有個核心點要注意的是，從DI容器獲取實例的時候一定要保證是和當前請求是同一個Scope，也就是說，必須要從當前的HttpContext中拿到這個IServiceProvider。

先創建一個自定義標籤：

    [AttributeUsage(AttributeTargets.Property)]
    public class AutowiredAttribute : Attribute
    {

    }

解析屬性的方法：

        public void PropertyActivate(object service, IServiceProvider provider)
        {
            var serviceType = service.GetType();
            var properties = serviceType.GetProperties().AsEnumerable().Where(x => x.Name.StartsWith("_"));
            foreach (PropertyInfo property in properties)
            {
                var autowiredAttr = property.GetCustomAttribute<AutowiredAttribute>();
                if (autowiredAttr != null)
                {
                    //從DI容器獲取實例
                    var innerService = provider.GetService(property.PropertyType);
                    if (innerService != null)
                    {
                        //遞歸解決服務嵌套問題
                        PropertyActivate(innerService, provider);
                        //屬性賦值
                        property.SetValue(service, innerService);
                    }
                }
            }
        }

然後在控制器中激活屬性：

        [Autowired]
        public IAccountService _accountService { get; set; }

        public LoginController(IHttpContextAccessor httpContextAccessor)
        {
            var pro = new AutowiredServiceProvider();
            pro.PropertyActivate(this, httpContextAccessor.HttpContext.RequestServices);
        }

這樣子下來，雖然功能實現了，但是裏面存着幾個問題。第一個是由於控制器的構造函數中不能直接使用ControllerBase的HttpContext屬性，所以必須要通過注入IHttpContextAccessor對象來獲取，貌似問題又回到原點。第二個是每個構造函數中都要寫這麼一堆代碼，不能忍。於是想有沒有辦法在控制器被激活的時候做一些操作？沒考慮引入AOP框架，感覺為了這一個功能引入AOP有點重。經過網上搜索，發現Asp.Net Core框架激活控制器是通過IControllerActivator接口實現的，它的默認實現是DefaultControllerActivator（）：

       /// <inheritdoc />
        public object Create(ControllerContext controllerContext)
        {
            if (controllerContext == null)
            {
                throw new ArgumentNullException(nameof(controllerContext));
            }

            if (controllerContext.ActionDescriptor == null)
            {
                throw new ArgumentException(Resources.FormatPropertyOfTypeCannotBeNull(
                    nameof(ControllerContext.ActionDescriptor),
                    nameof(ControllerContext)));
            }

            var controllerTypeInfo = controllerContext.ActionDescriptor.ControllerTypeInfo;

            if (controllerTypeInfo == null)
            {
                throw new ArgumentException(Resources.FormatPropertyOfTypeCannotBeNull(
                    nameof(controllerContext.ActionDescriptor.ControllerTypeInfo),
                    nameof(ControllerContext.ActionDescriptor)));
            }

            var serviceProvider = controllerContext.HttpContext.RequestServices;
            return _typeActivatorCache.CreateInstance<object>(serviceProvider, controllerTypeInfo.AsType());
        }

View Code

這樣一來，我自己實現一個Controller激活器不就可以接管控制器激活了，於是有如下這個類：

    public class HosControllerActivator : IControllerActivator
    {
        public object Create(ControllerContext actionContext)
        {
            var controllerType = actionContext.ActionDescriptor.ControllerTypeInfo.AsType();
            var instance = actionContext.HttpContext.RequestServices.GetRequiredService(controllerType);
            PropertyActivate(instance, actionContext.HttpContext.RequestServices);
            return instance;
        }

        public virtual void Release(ControllerContext context, object controller)
        {
            if (context == null)
            {
                throw new ArgumentNullException(nameof(context));
            }
            if (controller == null)
            {
                throw new ArgumentNullException(nameof(controller));
            }
            if (controller is IDisposable disposable)
            {
                disposable.Dispose();
            }
        }

        private void PropertyActivate(object service, IServiceProvider provider)
        {
            var serviceType = service.GetType();
            var properties = serviceType.GetProperties().AsEnumerable().Where(x => x.Name.StartsWith("_"));
            foreach (PropertyInfo property in properties)
            {
                var autowiredAttr = property.GetCustomAttribute<AutowiredAttribute>();
                if (autowiredAttr != null)
                {
                    //從DI容器獲取實例
                    var innerService = provider.GetService(property.PropertyType);
                    if (innerService != null)
                    {
                        //遞歸解決服務嵌套問題
                        PropertyActivate(innerService, provider);
                        //屬性賦值
                        property.SetValue(service, innerService);
                    }
                }
            }
        }
    }

View Code

需要注意的是，DefaultControllerActivator中的控制器實例是從TypeActivatorCache獲取的，而自己的激活器是從DI獲取的，所以必須額外把系統所有控制器註冊到DI中，封裝成如下的擴展方法：

        /// <summary>
        /// 自定義控制器激活，並手動註冊所有控制器
        /// </summary>
        /// <param name="services"></param>
        /// <param name="obj"></param>
        public static void AddHosControllers(this IServiceCollection services, object obj)
        {
            services.Replace(ServiceDescriptor.Transient<IControllerActivator, HosControllerActivator>());
            var assembly = obj.GetType().GetTypeInfo().Assembly;
            var manager = new ApplicationPartManager();
            manager.ApplicationParts.Add(new AssemblyPart(assembly));
            manager.FeatureProviders.Add(new ControllerFeatureProvider());
            var feature = new ControllerFeature();
            manager.PopulateFeature(feature);
            feature.Controllers.Select(ti => ti.AsType()).ToList().ForEach(t =>
            {
                services.AddTransient(t);
            });
        }

View Code

在ConfigureServices中調用：

services.AddHosControllers(this);

到此，大功告成！可以愉快的繼續CRUD了。

結尾

市面上好用的DI框架一堆一堆的，集成到Core裏面也很簡單，為啥還要這麼折騰？沒辦法，這不就是造輪子的樂趣嘛。上面這些東西從頭到尾也折騰了不少時間，屬性注入那裡也還有優化的空間，歡迎探討。

推薦閱讀：

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理
【其他文章推薦】

※為什麼 USB CONNECTOR 是電子產業重要的元件?

※網頁設計一頭霧水??該從何著手呢? 找到專業技術的網頁設計公司，幫您輕鬆架站!

※想要讓你的商品成為最夯、最多人討論的話題?網頁設計公司讓你強力曝光

※想知道最厲害的台北網頁設計公司推薦、台中網頁設計公司推薦專業設計師”嚨底家”!!

※專營大陸快遞台灣服務

※台灣快遞大陸的貨運公司有哪些呢?