Skip to content

Commit 5836475

Browse files
authored
Merge pull request #37407 from mengjiao-liu/remove_duplicate_chars_zh
[zh-cn] Remove duplicate Chinese characters
2 parents 245d406 + 44cf6e6 commit 5836475

File tree

5 files changed

+5
-5
lines changed

5 files changed

+5
-5
lines changed

content/zh-cn/blog/_posts/2018-07-10-coredns-ga.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -275,7 +275,7 @@ You can find out more on the [CoreDNS Blog](https://coredns.io/blog).
275275
--->
276276
## 下一步工作
277277

278-
CoreDNS 是一个独立的项目,许多与 Kubernetes 不直接相关的功能正在开发中。但是,其中许多功能将在 Kubernetes 中具有对应的应用。例如,与策略引擎完成集成后,当请求无头服务时,CoreDNS 能够智能地选择返回哪个端点。这可用于将流量分流到到本地 Pod 或响应更快的 Pod。更多的其他功能正在开发中,当然作为一个开源项目,我们欢迎您提出建议并贡献自己的功能特性!
278+
CoreDNS 是一个独立的项目,许多与 Kubernetes 不直接相关的功能正在开发中。但是,其中许多功能将在 Kubernetes 中具有对应的应用。例如,与策略引擎完成集成后,当请求无头服务时,CoreDNS 能够智能地选择返回哪个端点。这可用于将流量分流到本地 Pod 或响应更快的 Pod。更多的其他功能正在开发中,当然作为一个开源项目,我们欢迎您提出建议并贡献自己的功能特性!
279279

280280
上述特征和差异是几个示例。CoreDNS 还可以做更多的事情。您可以在 [CoreDNS 博客](https://coredns.io/blog) 上找到更多信息。
281281

content/zh-cn/case-studies/workiva/index.html

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -89,7 +89,7 @@ <h2>去年秋天,MacLeod Broad 在 Workiva 的平台团队在准备该公司
8989
<!-- With Workiva’s back-end code running on <a href="https://cloud.google.com/compute/">Google Compute Engine</a> as well as App Engine and AWS, Broad knew that he needed a tracing system that was platform agnostic. "We were looking at different tracing solutions," he says, "and we decided that because it seemed to be a very evolving market, we didn’t want to get stuck with one vendor. So OpenTracing seemed like the cleanest way to avoid vendor lock-in on what backend we actually had to use."<br><br> -->
9090
Workiva 的后端代码在 <a href="https://cloud.google.com/compute/">Google Compute Engine</a> 、App Engine 和 AWS 上运行,Broad 知道他需要一个与平台无关的跟踪系统。“我们正在研究不同的追踪解决方案,”他说,“我们决定,由于市场似乎是一个不断发展的市场,我们不想被一个供应商卡住。因此,OpenTracing 似乎是避免供应商限制我们实际使用的后端的最简捷方法。”<br><br>
9191
<!-- Once they introduced OpenTracing into this first use case, Broad says, "The trace made it super obvious where the bottlenecks were." Even though everyone had assumed it was Workiva’s existing code that was slowing things down, that wasn’t exactly the case. "It looked like the existing code was slow only because it was reaching out to our next-generation services, and they were taking a very long time to service all those requests," says Broad. "On the waterfall graph you can see the exact same work being done on every request when it was calling back in. So every service request would look the exact same for every response being paged out. And then it was just a no-brainer of, ‘Why is it doing all this work again?’"<br><br> -->
92-
Broad 说,一旦他们将 OpenTrace 引入到第一个用例中,“跟踪使得瓶颈所在位置变得非常明显。”尽管每个人都认为是 Workiva 的现有代码减缓了速度,但事实并非如此。Broad 说:“看起来现有代码速度很慢,只是因为它能够达到到我们下一代服务的水平,而且它们需要很长时间才能处理所有这些请求。”“在瀑布图上,你可以看到每个请求在得到响应时所做的完全相同的工作。因此,对于被分页的每个响应,每个服务请求看起来都完全相同。然后,就不用费神去思考‘为什么它再次做所有这些工作?’”<br><br>
92+
Broad 说,一旦他们将 OpenTrace 引入到第一个用例中,“跟踪使得瓶颈所在位置变得非常明显。”尽管每个人都认为是 Workiva 的现有代码减缓了速度,但事实并非如此。Broad 说:“看起来现有代码速度很慢,只是因为它能够达到我们下一代服务的水平,而且它们需要很长时间才能处理所有这些请求。”“在瀑布图上,你可以看到每个请求在得到响应时所做的完全相同的工作。因此,对于被分页的每个响应,每个服务请求看起来都完全相同。然后,就不用费神去思考‘为什么它再次做所有这些工作?’”<br><br>
9393
<!-- Using the insight OpenTracing gave them, "My team was able to look at a trace and make optimization suggestions to another team without ever looking at their code," says Broad. "The way we named our traces gave us insight whether it’s doing a SQL call or it’s making an RPC. And so it was really easy to say, ‘OK, we know that it’s going to page through all these requests. Do the work once and stuff it in cache.’ And we were done basically. All those calls became sub-second calls immediately."<br><br> -->
9494
使用 OpenTrace 的跟踪功能,“我的团队能够查看跟踪,并针对另一个团队提出优化建议,而无需查看他们的代码,”Broad 说。“我们命名跟踪的方式可以说明请求是执行 SQL 调用还是创建 RPC。因此,可以非常简单地说,‘好吧,我们知道它能处理所有这些请求。处理一次缓存一次。’我们基本上完成了。所有这些调用立即变成了亚秒级的调用。”<br><br>
9595

content/zh-cn/docs/concepts/architecture/nodes.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -202,7 +202,7 @@ re-scheduled.
202202
如果在 kubelet 重启期间 Node 配置发生了变化,已经被调度到某 Node 上的 Pod
203203
可能会出现行为不正常或者出现其他问题,例如,已经运行的 Pod
204204
可能通过污点机制设置了与 Node 上新设置的标签相排斥的规则,也有一些其他 Pod,
205-
本来与此 Pod 之间存在不兼容的问题,也会因为新的标签设置而被调到到同一节点
205+
本来与此 Pod 之间存在不兼容的问题,也会因为新的标签设置而被调到同一节点
206206
节点重新注册操作可以确保节点上所有 Pod 都被排空并被正确地重新调度。
207207
{{< /note >}}
208208

content/zh-cn/docs/reference/access-authn-authz/authentication.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1897,7 +1897,7 @@ Presence or absence of an expiry has the following impact:
18971897
时间戳格式给出的证书到期时间。
18981898
证书到期时间的有无会有如下影响:
18991899

1900-
- 如果响应中包含了到期时间,持有者令牌和 TLS 凭据会被缓存,直到到期期限到来
1900+
- 如果响应中包含了到期时间,持有者令牌和 TLS 凭据会被缓存,直到期限到来
19011901
或者服务器返回 401 HTTP 状态码,或者进程退出。
19021902
- 如果未指定到期时间,则持有者令牌和 TLS 凭据会被缓存,直到服务器返回 401
19031903
HTTP 状态码或者进程退出。

content/zh-cn/docs/tasks/administer-cluster/migrating-from-dockershim/migrating-telemetry-and-security-agents.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -208,7 +208,7 @@ The pod accessing Docker may have name containing:
208208
- `dynatrace-oneagent`
209209
-->
210210
如何迁移:
211-
[在 Dynatrace 上从 Docker-only 迁移到到通用容器指标](https://community.dynatrace.com/t5/Best-practices/Migrating-from-Docker-only-to-generic-container-metrics-in/m-p/167030#M49)
211+
[在 Dynatrace 上从 Docker-only 迁移到通用容器指标](https://community.dynatrace.com/t5/Best-practices/Migrating-from-Docker-only-to-generic-container-metrics-in/m-p/167030#M49)
212212

213213
Containerd 支持公告:[在基于 containerd 的 Kubernetes 环境的获取容器的自动化全栈可见性](https://www.dynatrace.com/news/blog/get-automated-full-stack-visibility-into-containerd-based-kubernetes-environments/)
214214
CRI-O 支持公告:[在基于 CRI-O 的 Kubernetes 环境获取容器的自动化全栈可见性(测试版)](https://www.dynatrace.com/news/blog/get-automated-full-stack-visibility-into-your-cri-o-kubernetes-containers-beta/)

0 commit comments

Comments
 (0)