全部变为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)