调试缓慢的 Kubernetes 部署答案

【问题标题】：Debugging slow Kubernetes deployment调试缓慢的 Kubernetes 部署
【发布时间】：2021-09-29 15:56:27
【问题描述】：

我们在托管的 Azure 环境中使用 K8S，在 Ubuntu 中使用 Minikube，以及在本地机器上构建的 Rancher 集群，通常情况下，我们的部署需要大约 30 秒来拉取容器、运行并准备好。但是，我最近一次尝试创建部署（本地）需要一分钟以上，有时甚至更长时间。它是一个小型 Web 服务，与我们的其他部署非常相似。唯一（明显）的区别是使用启动探测和活跃度探测，虽然我们的其他一些服务确实有探测，但它们是不同的。

通过提取正在运行的 yaml 并使用 kubectl 从等式中删除 Octopus deploy 后，一旦（单个）pod 启动，我就开始读取日志，并且正如预期的那样，启动和 liveness 探针被非常快速地调用。启动成功，集群开始调用 live probe，也成功了。但是，如果我在 pod 上使用 kubectl describe，它会显示 Initialized 和 PodScheduled 为 True，但 ContainersReady（有一个容器）和 Ready 在大约一分钟内都是错误的。除了探测失败之外，我看不到会导致此问题的原因，但这些都被记录为成功。

他们最终开始工作并正常工作，但我不知道他们为什么要花这么长时间。

kind: Deployment 
apiVersion: apps/v1 
metadata: 
  name: 'redirect-files-deployments-28775' 
  labels: 
    Octopus.Kubernetes.SelectionStrategyVersion: "SelectionStrategyVersion2" 
    OtherOctopusLabels
spec: 
  replicas: 1 
  selector: 
    matchLabels: 
      Octopus.Kubernetes.DeploymentName: 'redirect-files-deployments-28775' 

  template: 
    metadata: 
      labels: 
        Octopus.Kubernetes.SelectionStrategyVersion: "SelectionStrategyVersion2" 
        OtherOctopusLabels

    spec: 
      containers: 
      - name: redirect-files 
        image: ourregistry.azurecr.io/microservices.redirectfiles:1.0.34 
        ports: 
        - name: http 
          containerPort: 80 
          protocol: TCP 
        env: 
        - removed connection strings etc
        livenessProbe: 
          httpGet: 
            path: /api/version 
            port: 80 
            scheme: HTTP 
          successThreshold: 1 
        startupProbe: 
          httpGet: 
            path: /healthcheck 
            port: 80 
            scheme: HTTP 
            httpHeaders: 
            - name: X-SS-Authorisation 
              value: asdkjlkwe098sad0akkrweklkrew 

          initialDelaySeconds: 5 
          timeoutSeconds: 5 
      imagePullSecrets: 
      - name: octopus-feedcred-feeds-azure-container-registry

【问题讨论】：

你检查过你的 Pod 定义了吗？您确定没有任何 LimitRange，它可能会设置一些您不知道的资源限制/请求吗？和/或：您是否尝试过设置资源限制/请求，确保调度程序将您的部署分配给具有足够资源的节点？
@syn.不，我们只有一个包含 4 个大小相等的节点的小型集群，它有足够的容量容纳当前正在运行的少量 pod。虽然 pod 很慢，但根据 hypervisor，节点上的 CPU 非常低，并且该服务没有做任何特殊的事情，它只是启动了一个 dotnet 核心 Web 服务。
很难说...如果您确定没有限制/请求自动添加到您的 pod 模板之上，...您是否尝试过启动多个副本/任何可能的应用程序都会' t 使用多个 CPU？当您说它很慢时：与什么相比？ Pod 在 ContainerCreating 中意味着它正在初始化、拉取镜像、安装卷……首先怀疑是大镜像和/或 I/O 受限卷。比较虚拟机上的 k8s 和开发笔记本电脑上的 docker 之间的启动时间并不重要。您正在嵌套容器+virt 技术，使用网络驱动器 (SDS)、两层 SDN，...。
谢谢@SYN。这个容器没有卷，图像只有几百兆（alpine + 一个应用程序），由于探测器在创建后很快被调用，它一定是在容器创建后发生的，尽管我仍然希望它们显示为 ContainersReady。当我说慢时，将 hicharts 部署到同一个集群（类似大小）需要 20 秒。我唯一能想到的就是把所有的东西都一个一个地去掉，看看添加它们是否能显示我。
虽然如果有一些部署日志显示在时间线上发生了什么，那将会很有帮助。

标签： kubernetes kubernetes-pod

【解决方案1】：

所以原因是启动和/或活性探测。当我删除它们时，部署时间从一分钟多到 18 秒，尽管日志证明在容器启动后很快就成功调用了探测器。

至少我现在有更具体的东西要寻找。

【讨论】：