無名

13 声望

人生能有几回搏。

人生能有几回搏。

个人动态
  • 無名 回复 识趣缩小 Kubernetes pod 为0,并保持配置、deployment等完好无损 中 :

    全部变为0。

    kubectl scale deploy -n <namespace> --replicas=0 --all
    
    6天前
  • 無名 回复 识趣Kubernetes - 向容器传递多个命令 中 :

    在一个容器中只能有一个入口,如果你想运行多个命令,让bash成为入口,并让所有其他命令成为bash运行的参数。

    command: ["/bin/bash","-c","touch /foo && echo 'here' && ls /"]
    
    16天前
  • 無名 回复 识趣使用 kubectl 查找有关 Kubernetes master的详细信息的命令是什么? 中 :

    kubectl version --short 显示一个精简的k8s集群version:

    aathith@k8-master:~# kubectl version --short
    Client Version: v1.18.1
    Server Version: v1.18.1
    

    还有可通过api获取

    命令行窗口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"
    }
    
    1月前
  • 無名 回复 识趣kubernetes pod 不断因“CrashLoopBackOff”而崩溃,但我又找不到任何日志 中 :

    如果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就绪检查算法的工作原理如下:

    1. 等待initialDelaySeconds
    2. 如果失败的次数大于 failureThreshold 返回失败否则等待 periodSeconds 并开始新的检查。

    在我的情况中,会受到这些验证的影响。

    1月前
  • 啊啊 回复 無名kubernetes列出所有正在运行的pods名称 中 :

    这个更方便!

    1月前
  • 我叫不生气 赞了 在 sudo kubeadm reset时阻塞了 的评论!

    一般是docker的原因导致的。

    一个可行的解决方案是重新启动 Docker 服务,然后重新运行 kubeadm reset

    sudo systemctl restart docker.service
    sudo kubeadm reset
    

    检查 docker 的日志:

    journalctl -ul docker
    
    1月前
  • 1月前
  • 发表了 什么是kvm?  
    4月前
  • 关注了用户 Lance.Wu · 4月前
  • 订阅了 java 主题! · 4月前
  • 赞了 無名用kafka命令发送消息时候,一直报WARN Error while fetching metadata with correlation id 0 : {test=UNKNOWN_TOPIC_OR_PARTITION}? 的评论!

    你看下kafka集群的配置文件,是否设置了auto.create.topics.enable=false

    如果有,就设置为ture,当topic不存在,导致的,允许它自动创建。

    或者你也可以手动创建topic:

    bin/kafka-topics.sh --create --zookeeper localhost:2181 --replication-factor 2 --partitions 4 --topic test
    
    5月前
  • 赞了 無名如何监听kubernetes job? 的评论!
    $ kubectl wait --for=condition=complete --timeout=600s job/myjob
    
    5月前
  • 赞了 KubeBiz中文教程 · 5月前
  • 半兽人 赞了 在 Kubernetes(k8s)中文教程 的评论!

    Kubernetes(k8s)就是按照用户的期望的样子来运行部署应用程序。
    赞!

    5月前
  • 订阅了 bootstrap5 主题! · 5月前
  • 赞了 無名kafka中文教程 的评论!

    大佬,非常高兴能看到你得文章

    5月前
  • 赞了 無名Kafka的主要API有哪些? 的评论!

    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

    5月前
  • 赞了 無名k8s节点NotReady是什么导致的?NotReady会发生什么? 的评论!

    NotReady是什么导致的?

    导致kubernetes node状态为NotReady的原因有很多,常见的错误如下:

    1. kubelet启动节点失败(核心)
    2. 网络附加组件cni,如:calico、flannel等故障
    3. 节点OOM(NotReady和Ready状态反复切换,因为释放容器之后,又满了,轮询反复)

    大部分情况是kubelet引起的:

    • RPC 调用过程中容器运行时响应超时(有可能是性能下降,死锁或者出现了 bug)。

    • 节点上的 Pod 数量太多,导致 relist操作无法在 3 分钟内完成。事件数量和延时与 Pod 数量成正比,与节点资源无关。

    • relist 出现了死锁,该 bug 已在 Kubernetes 1.14 中修复。

    • 获取 Pod 的网络堆栈信息时CNI插件出现了bug(简而言之即容器管理系统和网络插件之间通过 JSON 格式的文件进行通信,实现容器的网络功能)。

    NotReady会发生什么?

    1、NotReady的node上的容器依然提供服务,但已脱离了kubernetes的调度,不会做任何变动。
    2、kubernetes将NotReady的node节点上的容器调度正常的node上。

    5月前
  • 赞了 無名Kubernetes(k8s)的QoS是怎么实现的? 的评论!

    QoS是怎么实现的

    从容器的角度出发,限制容器使用的CPU和内存,是通过cgroup来实现的,目前kubernetes的QoS只能管理CPU和内存,所以kubernetes现在也是通过对cgroup的配置来实现QoS管理的。

    QoS是什么

    在kubernetes中,每个Pod都有个QoS标记,QoS的英文全称为 Quality of Service,中文名为服务质量,它取决于用户对服务质量的预期,也就是期望的服务质量。对于Pod来说,服务质量体现在两个指标上,一个指标是CPU,另一个指标是内存。在实际运行过程中,当NODE节点上内存资源紧张的时候,kubernetes根据Pod具有的不同QoS标记,采取不同调度和驱逐策略。

    QoS 类

    Kubernetes 创建 Pod 时就给它指定了下列一种 QoS 类:

    • Guaranteed
    • Burstable
    • BestEffort

    QoS 类为 Guaranteed 的 Pod

    • Pod 中的每个容器必须指定内存请求和内存限制,并且两者要相等。
    • Pod 中的每个容器必须指定 CPU 请求和 CPU 限制,并且两者要相等。

    QoS 类为 Burstable 的 Pod

    如果满足下面条件,将会指定 Pod 的 QoS 类为 Burstable:

    • Pod 不符合 Guaranteed QoS 类的标准。
    • Pod 中至少一个容器具有内存或 CPU 请求。

    QoS 类为 BestEffort 的 Pod

    • 对于 QoS 类为 BestEffort 的 Pod,Pod 中的容器必须没有设置内存和 CPU 限制或请求。

    QoS级别决定了kubernetes处理这些Pod的方式,我们以内存资源为例:

    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)

    5月前
  • 订阅了 shares 主题! · 6月前
  • 订阅了 kafka 主题! · 6月前
  • Lance.Wu 关注了Ta · 10月前
  • 半兽人 关注了Ta · 2年前
  • C`c 关注了Ta · 2年前
  • Explore 关注了Ta · 3年前