無名
人生能有几回搏。
人生能有几回搏。
人生能有几回搏。
人生能有几回搏。
全部变为0。
kubectl scale deploy -n <namespace> --replicas=0 --all
在一个容器中只能有一个入口，如果你想运行多个命令，让bash成为入口，并让所有其他命令成为bash运行的参数。
command: ["/bin/bash","-c","touch /foo && echo 'here' && ls /"]
kubectl version --short 显示一个精简的k8s集群version：
aathith@k8-master:~# kubectl version --short
Client Version: v1.18.1
Server Version: v1.18.1
命令行窗口1：
aathith@k8-master:~# kubectl proxy
Starting to serve on 127.0.0.1:8001
命令行窗口2：
aathith@k8-master:~# curl http://localhost:8001/version -k
{
"major": "1",
"minor": "18",
"gitVersion": "v1.18.1",
"gitCommit": "e0fccafd69541e3750d460ba0f9743b90336f24f",
"gitTreeState": "clean",
"buildDate": "2020-04-16T11:35:47Z",
"goVersion": "go1.13.9",
"compiler": "gc",
"platform": "linux/amd64"
}
如果application的启动速度较慢，可能与readiness/liveness探针的初始值有关。通过将initialDelaySeconds的值增加到120s来解决我的问题，因为我的SpringBoot应用程序要处理大量的初始化。
service:
livenessProbe:
httpGet:
path: /health/local
scheme: HTTP
port: 8888
initialDelaySeconds: 120
periodSeconds: 5
timeoutSeconds: 5
failureThreshold: 10
readinessProbe:
httpGet:
path: /admin/health
scheme: HTTP
port: 8642
initialDelaySeconds: 150
periodSeconds: 5
timeoutSeconds: 5
failureThreshold: 10
什么是initialDelaySeconds的默认值，对这些值有一个非常好的解释。
运行情况或readiness就绪检查算法的工作原理如下：
initialDelaySeconds。failureThreshold 返回失败否则等待 periodSeconds 并开始新的检查。在我的情况中，会受到这些验证的影响。
一般是docker的原因导致的。
一个可行的解决方案是重新启动 Docker 服务，然后重新运行 kubeadm reset：
sudo systemctl restart docker.service
sudo kubeadm reset
检查 docker 的日志：
journalctl -ul docker
你看下kafka集群的配置文件，是否设置了auto.create.topics.enable=false。
如果有，就设置为ture，当topic不存在，导致的，允许它自动创建。
或者你也可以手动创建topic：
bin/kafka-topics.sh --create --zookeeper localhost:2181 --replication-factor 2 --partitions 4 --topic test
$ kubectl wait --for=condition=complete --timeout=600s job/myjob
Kafka有5个核心API：
Producer API 允许应用程序发送数据流到kafka集群中的topic。Consumer API 允许应用程序从kafka集群的topic中读取数据流。Streams API 允许从输入topic转换数据流到输出topic。Connect API 通过实现连接器（connector），不断地从一些源系统或应用程序中拉取数据到kafka，或从kafka提交数据到宿系统（sink system）或应用程序。Admin API 用于管理和检查topic，broker和其他Kafka对象。具体可参考：kafka接口API
导致kubernetes node状态为NotReady的原因有很多，常见的错误如下：
RPC 调用过程中容器运行时响应超时(有可能是性能下降，死锁或者出现了 bug)。
节点上的 Pod 数量太多，导致 relist操作无法在 3 分钟内完成。事件数量和延时与 Pod 数量成正比，与节点资源无关。
relist 出现了死锁，该 bug 已在 Kubernetes 1.14 中修复。
获取 Pod 的网络堆栈信息时CNI插件出现了bug(简而言之即容器管理系统和网络插件之间通过 JSON 格式的文件进行通信，实现容器的网络功能)。
1、NotReady的node上的容器依然提供服务，但已脱离了kubernetes的调度，不会做任何变动。
2、kubernetes将NotReady的node节点上的容器调度正常的node上。
从容器的角度出发，限制容器使用的CPU和内存，是通过cgroup来实现的，目前kubernetes的QoS只能管理CPU和内存，所以kubernetes现在也是通过对cgroup的配置来实现QoS管理的。
在kubernetes中，每个Pod都有个QoS标记，QoS的英文全称为 Quality of Service，中文名为服务质量，它取决于用户对服务质量的预期，也就是期望的服务质量。对于Pod来说，服务质量体现在两个指标上，一个指标是CPU，另一个指标是内存。在实际运行过程中，当NODE节点上内存资源紧张的时候，kubernetes根据Pod具有的不同QoS标记，采取不同调度和驱逐策略。
Kubernetes 创建 Pod 时就给它指定了下列一种 QoS 类：
如果满足下面条件，将会指定 Pod 的 QoS 类为 Burstable：
1、当 NODE节点上内存资源不够的时候，QoS级别是BestEffort的Pod会最先被kill掉；当NODE节点上内存资源充足的时候，QoS级别是BestEffort的POD可以使用NODE节点上剩余的所有内存资源。
2、当NODE节点上内存资源不够的时候，如果QoS级别是BestEffort的Pod已经都被kill掉了，那么会查找QoS级别是Burstable的POD，并且这些POD使用的内存已经超出了requests设置的内存值，这些被找到的POD会被kill掉；当NODE节点上内存资源充足的时候，QoS级别是Burstable的POD会按照requests和limits的设置来使用。
3、当NODE节点上内存资源不够的时候，如果QoS级别是BestEffort和Burstable的Ppod都已经被kill掉了，那么会查找QoS级别是Guaranteed的POD，并且这些POD使用的内存已经超出了limits设置的内存值，这些被找到的POD会被kill掉；当NODE节点上内存资源充足的时候，QoS级别是Burstable的POD会按照requests和limits的设置来使用。
详细参考：配置Pod的服务质量（QoS）
