一、前提条件
·已创建了 TKE 集群。
·已安装了 Helm。
·已配置了 TKE 集群的 kubeconfig，并具有操作 TKE 集群的权限。详情请参见 连接集群。
二、在 TKE 配置 SSH 密钥
生成 SSH 密钥对，将 "your_email@example.com" 替换为你的 GitHub 注册邮箱。命令示例如下：
ssh-keygen -t ed25519 -C "your_email@example.com"
将公钥添加到 GitHub，查看并复制生成的公钥内容，命令示例如下：
cat ~/.ssh/id_ed25519.pub
你可以登录 GitHub，依次点击右上角头像 > Settings > SSH and GPG keys > New SSH key。
取一个易识别的 Title（例如 My TKE Node），将复制的内容粘贴到 Key 框中，点击 Add SSH key。
在 TKE 集群中创建 Kubernetes Secret，假设你的私钥文件名为 id_ed25519。使用 kubectl 命令在需要访问仓库的命名空间下创建一个 Secret。例如，创建在 istio-system 命名空间中：
kubectl create secret generic github-ssh-key \\ –namespace=istio-system \\ –from-file=id_ed25519=./id_ed25519
在 Pod 的 YAML 配置中挂载该 Secret。
apiVersion: apps/v1kind: Deploymentmetadata: name: my-app namespace: istio-systemspec: template: spec: containers: – name: my-app-container image: my-app-image volumeMounts: – name: ssh-key-volume mountPath: "/root/.ssh" # 挂载到容器的 SSH 目录，用户需根据镜像调整（如 root 或非root用户） volumes: – name: ssh-key-volume secret: secretName: github-ssh-key # 之前创建的 Secret 名称 defaultMode: 0600 # 关键：设置文件权限为 600，否则 SSH 会因权限太开放而拒绝使用
三、将 CoScheduler 作为第二调度器完成安装
pod 调度时需要指定 schedulerName 为 scheduler-plugins-scheduler。命令示例如下：
$ git clone git@github.com:kubernetes-sigs/scheduler-plugins.git$ cd scheduler-plugins/manifests/install/charts$ helm install scheduler-plugins as-a-second-scheduler/ –create-namespace –namespace scheduler-plugins
四、验证安装成功
执行如下命令，观察 Pod 运行情况。
$ kubectl get deploy -n scheduler-plugins
预期输出：
NAME READY UP-TO-DATE AVAILABLE AGEscheduler-plugins-controller 1/1 1 1 7sscheduler-plugins-scheduler 1/1 1 1 7s
五、PodGroup
PodGroup 是 CoScheduling 组件自定义资源，用来定义最少需要同时调度的 Pod 数。通过设置标签定义 Pod 属于哪一个 PodGroup。以下是 PodGroup 的 CRD 规范示例：
# PodGroup CRD specapiVersion: scheduling.x-k8s.io/v1alpha1kind: PodGroupmetadata: name: nginxspec: scheduleTimeoutSeconds: 10 minMember: 3—# Add a label `scheduling.x-k8s.io/pod-group` to mark the pod belongs to a grouplabels: scheduling.x-k8s.io/pod-group: nginx
创建 PodGroup：
kubectl apply -f podgroup.yaml
我们将在调度程序中计算正在运行的 pod 和正在等待的 pod（假设但未绑定）的总和，如果总和大于或等于 minMember，则将创建等待 pod。同一 PodGroup 中具有不同优先级的 Pod 可能会导致意外行为，因此需要确保同一 PodGroup 中的 Pod 具有相同的优先级。
六、示例
假设我们有一个只能容纳3个 nginx pod 的集群，创建一个 replicas=6 的 ReplicaSet，并将 minMember 的值设置为3。
apiVersion: scheduling.x-k8s.io/v1alpha1kind: PodGroupmetadata: name: nginxspec: scheduleTimeoutSeconds: 10 minMember: 3—apiVersion: apps/v1kind: ReplicaSetmetadata: name: nginx labels: app: nginxspec: replicas: 6 selector: matchLabels: app: nginx template: metadata: name: nginx labels: app: nginx scheduling.x-k8s.io/pod-group: nginx spec: containers: – name: nginx image: nginx resources: limits: cpu: 3000m memory: 500Mi requests: cpu: 3000m memory: 500Mi
3个 Pod 将一起被调度，如下：
$ kubectl get podsNAME READY STATUS RESTARTS AGEnginx-4jw2m 0/1 Pending 0 55snginx-4mn52 1/1 Running 0 55snginx-c9gv8 1/1 Running 0 55snginx-frm24 0/1 Pending 0 55snginx-hsflk 0/1 Pending 0 55snginx-qtj5f 1/1 Running 0 55s
如果此时修改 minMember 为4，因不满足 PodGroup 定义的 minMember 为3的要求，所有的 nginx pod 都处于 pending 状态：
$ kubectl get podsNAME READY STATUS RESTARTS AGEnginx-4vqrk 0/1 Pending 0 3snginx-bw9nn 0/1 Pending 0 3snginx-gnjsv 0/1 Pending 0 3snginx-hqhhz 0/1 Pending 0 3snginx-n47r7 0/1 Pending 0 3snginx-n7vtq 0/1 Pending 0 3s