New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

WIP: [zh] sync pod-scheduling-readiness.md #37986

Closed

iyear wants to merge 1 commit into kubernetes:dev-1.26 from iyear:zh-pod-sched-readiness

Contributor

iyear commented Nov 20, 2022

Sync with en #37675

I will proofread again after the original PR is merged.

k8s-ci-robot added this to the 1.26 milestone

k8s-ci-robot added do-not-merge/work-in-progress cncf-cla: yes labels

netlify bot commented Nov 20, 2022 •

edited

Loading

👷 Deploy Preview for kubernetes-io-vnext-staging processing.

Name	Link
🔨 Latest commit	`44729a5`
🔍 Latest deploy log	https://app.netlify.com/sites/kubernetes-io-vnext-staging/deploys/6379c1ad5e172b00074dcd44

k8s-ci-robot requested a review from chenrui333

November 20, 2022 05:55

Contributor

k8s-ci-robot commented Nov 20, 2022

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign mengjiao-liu for approval by writing /assign @mengjiao-liu in a comment. For more information see the Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

content/zh-cn/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

k8s-ci-robot added the language/zh label

k8s-ci-robot requested a review from windsonsea

November 20, 2022 05:55

k8s-ci-robot added sig/docs size/L labels


          [zh] sync pod-scheduling-readiness.md

44729a5

iyear force-pushed the zh-pod-sched-readiness branch from 6256499 to 44729a5 Compare

November 20, 2022 05:56

tengqm reviewed

View reviewed changes

content/zh-cn/docs/concepts/scheduling-eviction/pod-scheduling-readiness.md

+              title: Pod Scheduling Readiness
+              content_type: concept
+              weight: 40
+              ---

Contributor

tengqm Nov 21, 2022

line 8 and line 12 can be removed together.

content/zh-cn/docs/concepts/scheduling-eviction/pod-scheduling-readiness.md

+              These Pods actually churn the scheduler (and downstream integrators like Cluster AutoScaler)
+              in an unnecessary manner.
+              -->
+              之前，Pod 一旦创建就被认为可以进行调度。Kubernetes调度器会尽职尽责地寻找节点来放置所有待定的Pod。

Contributor

tengqm Nov 21, 2022

Suggested change

      
            之前，Pod 一旦创建就被认为可以进行调度。Kubernetes调度器会尽职尽责地寻找节点来放置所有待定的Pod。
          
            之前，Pod 一旦创建就被认为可以进行调度。Kubernetes 调度器会尽职尽责地寻找节点来放置所有待定的 Pod。

content/zh-cn/docs/concepts/scheduling-eviction/pod-scheduling-readiness.md

+              in an unnecessary manner.
+              -->
+              之前，Pod 一旦创建就被认为可以进行调度。Kubernetes调度器会尽职尽责地寻找节点来放置所有待定的Pod。
+              然而，在现实场景中，一些 Pod 可能会长期处于“缺失必要资源”状态。

Contributor

tengqm Nov 21, 2022

Suggested change

      
            然而，在现实场景中，一些 Pod 可能会长期处于“缺失必要资源”状态。
          
            然而，在现实场景中，一些 Pod 可能会长期处于“缺失必要资源（missing-essential-resources）”状态。

content/zh-cn/docs/concepts/scheduling-eviction/pod-scheduling-readiness.md

+              -->
+              之前，Pod 一旦创建就被认为可以进行调度。Kubernetes调度器会尽职尽责地寻找节点来放置所有待定的Pod。
+              然而，在现实场景中，一些 Pod 可能会长期处于“缺失必要资源”状态。
+              这些 Pod 实际上在以不必要的方式搅动调度器（和下游集成商，如Cluster AutoScaler）。

Contributor

tengqm Nov 21, 2022

Suggested change

      
            这些 Pod 实际上在以不必要的方式搅动调度器（和下游集成商，如Cluster AutoScaler）。
          
            这些 Pod 实际上在以不必要的方式搅动调度器（和下游集成服务，如 Cluster AutoScaler）。

content/zh-cn/docs/concepts/scheduling-eviction/pod-scheduling-readiness.md

+              <!--
+              ## Configuring Pod schedulingGates
+              -->
+              ## 配置 Pod 的调度门控

Contributor

tengqm Nov 21, 2022

Suggested change

      
            ## 配置 Pod 的调度门控
          
            ## 配置 Pod 的 schedulingGates  {#configuring-pod-schedulinggates}

content/zh-cn/docs/concepts/scheduling-eviction/pod-scheduling-readiness.md

+              <!--
+              ## Usage example
+              -->
+              ## 使用示例

Contributor

tengqm Nov 21, 2022

Suggested change

      
            ## 使用示例
          
            ## 用法示例    {#usage-example}

content/zh-cn/docs/concepts/scheduling-eviction/pod-scheduling-readiness.md

+              After the Pod's creation, you can check its state using:
+              -->
+              要标记一个 Pod 未调度就绪，你可以像这样创建它，其中包含一个或多个调度门控：

Contributor

tengqm Nov 21, 2022

Suggested change

      
            要标记一个 Pod 未调度就绪，你可以像这样创建它，其中包含一个或多个调度门控：
          
            要标记一个 Pod 未调度就绪，你可以在创建 Pod 时设置一个或多个调度门控，像这样：

content/zh-cn/docs/concepts/scheduling-eviction/pod-scheduling-readiness.md

+              You can check if the `schedulingGates` is cleared by running:
+              -->
+              要通知调度器这个 Pod 已经准备好进行调度，你可以通过重新应用修改过的清单来完全删除其 `schedulingGates` ：

Contributor

tengqm Nov 21, 2022

Suggested change

      
            要通知调度器这个 Pod 已经准备好进行调度，你可以通过重新应用修改过的清单来完全删除其 `schedulingGates` ：
          
            要通知调度器这个 Pod 已经准备好进行调度，你可以通过重新应用修改过的清单来彻底删除其 `schedulingGates` ：

content/zh-cn/docs/concepts/scheduling-eviction/pod-scheduling-readiness.md

+              has been tried scheduling but claimed as unschedulable, or explicitly marked as not ready for
+              scheduling. You can use `scheduler_pending_pods{queue="gated"}` to check the metric result.
+              -->
+              指标 `scheduler_pending_pods` 带有一个新的标签 `"gated"` ，

Contributor

tengqm Nov 21, 2022

多一空格

content/zh-cn/docs/concepts/scheduling-eviction/pod-scheduling-readiness.md

+              has been tried scheduling but claimed as unschedulable, or explicitly marked as not ready for
+              scheduling. You can use `scheduler_pending_pods{queue="gated"}` to check the metric result.
+              -->
+              指标 `scheduler_pending_pods` 带有一个新的标签 `"gated"` ，

Contributor

tengqm Nov 21, 2022

Suggested change

      
            指标 `scheduler_pending_pods` 带有一个新的标签 `"gated"` ，
          
            指标 `scheduler_pending_pods` 带有一个新的标签 `"gated"`，

Contributor

divya-mohan0209 commented Nov 21, 2022

Just a quick question, @iyear, I understand that this is the translation for a doc on the 1.26 release. However, is there a requirement/has there been an agreement for this to land in the dev-1.26 branch along with all other English docs? The reason is we typically have the localization teams work on the different docs AFTER the docs for that release are published since updating an isolated doc might result in inconsistencies.

cc : @reylejano @natalisucks @sftim @a-mccarthy

Contributor Author

iyear commented Nov 21, 2022 •

edited

Loading

@divya-mohan0209
I'm very sorry for interfering with your work. I just skimmed through the history of zh PRs and contribution docs...

Reasons why I committed to the dev-1.26 branch: #37981, so I directly submit a new PR...

So I should wait until the new docs are released and I commit the translation to the dev-1.26-zh.x branch...? Can I use "change base branch" on GitHub to do it?

Contributor

tengqm commented Nov 22, 2022

@iyear The concern from the reviewers is valid. We don't have a lot of localization PRs going into the dev-1.xy branch because most localization teams are busy translating current/previous (sub-)versions. The Chinese (zh-cn) localization team, thanks to the passions from all contributors, has been following and closely tracking the main branch for some time. We are kind of pushing the limit, contributing to dev-1.xy branch directly. This is good.

However, there are some risks on doing this. Given an existing page en/foo/page.md, we have a zh-cn/foo/page.md. There could be changes to the English version for current release (say '1.25', aka, 'main' branch). These changes can be tracked using the scripts/lsync.sh script. There could be NEW changes to the same page in the dev-1.26 branch. We may want to update the Chinese version in the dev-1.26 branch as well, but the story is getting complicated. The en/foo/page.md now has two versions (one in main, one in dev-1.26). The release team needs to make sure there are no conflicts between them. This team CANNOT do the same for Chinese localizations. When conflicts do arise, they break the build, or even delay the site release.

So, I'd suggest we DO NOT commit localization PRs to the dev-1.26 branch.

/hold

k8s-ci-robot added the do-not-merge/hold label

Contributor

sftim commented Nov 22, 2022

Here's my concern: the release docs team have to merge in changes and resolve conflicts. We don't expect those teams to include representatives from every launched localization. It's much easier to have that team specialize in the upstream (English) localization.

If any localization team wants to make a head start on changes, those are OK to work on, but PRs will need to rebase after the v1.26 release and should be draft before then.

Contributor Author

iyear commented Nov 22, 2022 •

edited

Loading

@divya-mohan0209 @tengqm @sftim Thank you very much for your reviews and replies, I didn't read the contribution docs carefully enough to cause the conflict. It's true that I shouldn't commit to dev-1.26 and cause trouble for the team.

And what should I do next? It looks like merging this PR cause more trouble.

tengqm deleted the branch kubernetes:dev-1.26

December 10, 2022 03:41

tengqm closed this

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

cncf-cla: yes do-not-merge/hold do-not-merge/work-in-progress language/zh sig/docs size/L