Update localization guidelines (#10485)
* Update localization guidelines for language labels
Continuing work
Continuing work
Continuing work
More work in progress
Add local OWNERS folders
Add an OWNERS file to Chinese
Remove shortcode for repos
Add Japanese
Alphabetize languages, change weights accordingly
More updates
Add Korean in Korean
Add English to languageName
Feedback from gochist
Move Chinese content from cn/ to zh/
Move OWNERS from cn/ to zh/
Resolve merge conflicts by updating from master
Add files back in to prep for resolution
After rebase on upstream/master, remove files
Review and update localization guidelines
Feedback from gochist, tnir, cstoku
Add a trailing newline to content/ja/OWNERS
Add a trailing newline to content/zh/OWNERS
Drop requirement for GH repo project
Clarify language about forks/branches
Edits and typos
Remove a shortcode specific to a multi-repo language setup
Update aliases and owners
Add explicit OWNERS for content/en
Migrate content from Chinese repo, update regex in config.toml
Remove untranslated strings
Add trailing newline to content/en/OWNERS
Add trailing newlines to OWNERS files
add Jaguar project description (#10433)
* add Jaguar project description
[Jaguar](https://gitlab.com/sdnlab/jaguar) is an open source solution for Kubernetes's network based on OpenDaylight.
Jaguar provides overlay network using vxlan and Jaguar CNIPlugin provides one IP address per pod.
* Minor newline tweak
blog post for azure vmss (#10538)
Add microk8s to pick-right-solution.md (#10542)
* Add microk8s to pick-right-solution.md
Microk8s is a single-command installation of upstream Kubernetes on any Linux and should be included in the list of local-machine solutions.
* capitalized Istio
Add microk8s to foundational.md (#10543)
* Add microk8s to foundational.md
Adding microk8s as credible and stable alternative to get started with Kubernetes on a local machine. This is especially attractive for those not wanting to incur the overhead of running a VM for a local cluster.
* Update foundational.md
Thank you for your suggestions! LMK if this works now?
* Rewrote first paragraph
And included a bullet list of features of microk8s
* Copyedit
fix typo (#10545)
Fix the kubectl subcommands links. (#10550)
Signed-off-by: William Zhang <warmchang@outlook.com>
Fix command issue (#10515)
Signed-off-by: mooncake <xcoder@tenxcloud.com>
remove imported community files per issue 10184 (#10501)
networking.md: Markdown fix (#10498)
Fix front matter, federation command-line tools (#10500)
Clean up glossary entry (#10399)
update slack link (#10536)
typo in StatefulSet docs (#10558)
fix discription about horizontal pod autoscale (#10557)
Remove redundant symbols (#10556)
Fix issue #10520 (#10554)
Signed-off-by: William Zhang <warmchang@outlook.com>
Update api-concepts.md (#10534)
Revert "Fix command issue (#10515)"
This reverts commit c02a7fb9f9.
Update memory-constraint-namespace.md (#10530)
update memory request to 100MiB corresponding the yaml content
Blog: Introducing Volume Snapshot Alpha for Kubernetes (#10562)
* blog post for azure vmss
* snapshot blog post
Resolve merge conflicts in OWNERS*
Minor typo fix (#10567)
Not sure what's supposed to be here, proposing removing it.
* Feedback from gochist
Tweaks to feedback
* Feedback from ClaudiaJKang
This commit is contained in:
Zach Corleissen
committed by
k8s-ci-robot
k8s-ci-robot
parent
753f57f0e6
commit
abcee2dccd
@@ -0,0 +1,86 @@
|
||||
---
|
||||
title: 调试Pods和Replication Controllers
|
||||
---
|
||||
|
||||
{{< toc >}}
|
||||
|
||||
## 调试Pods
|
||||
|
||||
调试一个pod的第一步是观察它。使用下面的命令检查这个pod的当前状态和最近事件：
|
||||
|
||||
$ kubectl describe pods ${POD_NAME}
|
||||
|
||||
看看pod中的容器的状态。他们都是`Running`吗？有最近重启了吗？
|
||||
|
||||
根据pod的状态继续调试。
|
||||
|
||||
### 我的Pod保持Pending
|
||||
|
||||
如果一个pod被卡在`Pending`中，就意味着它不能调度在某个节点上。一般来说，这是因为某种类型的资源不足
|
||||
阻止调度。 看看上面的命令`kubectl describe ...`的输出。调度器的消息中应该会包含无法调度Pod的原因。
|
||||
理由包括：
|
||||
|
||||
#### 资源不足
|
||||
|
||||
您可能已经耗尽了集群中供应的CPU或内存。在这个情况下你可以尝试几件事情：
|
||||
|
||||
* [添加更多节点](/docs/admin/cluster-management/#resizing-a-cluster) 到集群。
|
||||
|
||||
* [终止不需要的pod](/docs/user-guide/pods/single-container/#deleting_a_pod)
|
||||
为pending中的pods提供空间。
|
||||
|
||||
* 检查该pod是否不大于您的节点。例如，如果全部节点具有`cpu:1`容量，那么具有`cpu: 1.1`请求的pod永远不会被调度。
|
||||
|
||||
您可以使用`kubectl get nodes -o <format>`命令来检查节点容量。
|
||||
下面是一些能够提取必要信息的命令示例：
|
||||
|
||||
kubectl get nodes -o yaml | grep '\sname\|cpu\|memory'
|
||||
kubectl get nodes -o json | jq '.items[] | {name: .metadata.name, cap: .status.capacity}'
|
||||
|
||||
可以考虑配置[资源配额](/docs/concepts/policy/resource-quotas/)来限制可耗用的资源总量。如果与命名空间一起使用，它可以防止一个团队吞噬所有的资源。
|
||||
|
||||
#### 使用hostPort
|
||||
|
||||
当你将一个pod绑定到一个`hostPort`时，这个pod能被调度的位置数量有限。
|
||||
在大多数情况下，`hostPort`是不必要的; 尝试使用服务对象来暴露您的pod。
|
||||
如果你需要`hostPort`，那么你可以调度的Pod数量不能超过集群的节点个数。
|
||||
|
||||
### 我的Pod一直在Waiting
|
||||
|
||||
如果一个pod被卡在`Waiting`状态，那么它已被调度在某个工作节点，但它不能在该机器上运行。
|
||||
再次，来自`kubectl describe ...`的内容应该是可以提供信息的。
|
||||
最常见的原因`Waiting`的pod是无法拉取镜像。有三件事要检查：
|
||||
|
||||
* 确保您的镜像的名称正确。
|
||||
* 您是否将镜像推送到存储库？
|
||||
* 在您的机器上手动运行`docker pull <image>`，看看是否可以拉取镜像。
|
||||
|
||||
### 我的Pod一直Crashing或者有别的不健康状态
|
||||
|
||||
首先，查看当前容器的日志：
|
||||
|
||||
$ kubectl logs ${POD_NAME} ${CONTAINER_NAME}
|
||||
|
||||
如果您的容器先前已崩溃，则可以访问上一个容器的崩溃日志：
|
||||
|
||||
$ kubectl logs --previous ${POD_NAME} ${CONTAINER_NAME}
|
||||
|
||||
或者，您可以使用`exec`在该容器内运行命令：
|
||||
|
||||
$ kubectl exec ${POD_NAME} -c ${CONTAINER_NAME} -- ${CMD} ${ARG1} ${ARG2} ... ${ARGN}
|
||||
|
||||
请注意，`-c ${CONTAINER_NAME}`是可选的，对于pod只包含一个容器可以省略。
|
||||
|
||||
例如，要查看正在运行的Cassandra pod的日志，可以运行：
|
||||
|
||||
$ kubectl exec cassandra -- cat /var/log/cassandra/system.log
|
||||
|
||||
如果这些方法都不起作用，您可以找到该运行pod所在的主机并SSH到该主机。
|
||||
|
||||
## 调试Replication Controllers
|
||||
|
||||
Replication Controllers相当简单。他们能或不能创建pod。如果他们无法创建pod，那么请参考
|
||||
[上面的说明](#debugging_pods)来调试你的pod。
|
||||
|
||||
您也可以使用`kubectl describe rc ${CONTROLLER_NAME}`来检查和Replication Controllers有关的事件。
|
||||
|
||||
Reference in New Issue
Block a user