mischen520的博客

如果 Pod 里的容器反复退出并重启，是无法使用 kubectl exec 的。此时，除了检查节点或容器状态和日志之外，还可以使用 kubectl debug 的方式在 Pod 上启动一个临时容器，用于检查环境和依赖。

首先，使用 kubectl exec 需要指定容器，当 Pod 只有一个容器时则可以忽略。其次，Pod 是一组独立的 Linux 命名空间，容器本质上是一个进程，Pod 内容器共享 Network、IPC、UTS namespace，而每个容器的 PID、Mount namespace 则是独立的。"登录"的说法并不准确，kubectl exec -it – bash 既不是进入了 Pod，也不是进入了容器，而是在目标容器的隔离环境中创建了一个新的 bash 进程。

Kubernetes 提供了水平扩展（HPA）和垂直扩展（VPA）两种机制，由于 VPA 不是原地资源扩展，会删除 Pod 再创建，使用场景往往受限，所以使用更多是 HPA，可以根据指标（如 CPU 使用率、请求速率、其它自定义指标）动态调整 Pod 数量。当然，也可以在外部监测指标然后向 kube-apiserver 发起请求扩展 Pod 的数量。

综上所述，即使 livenessProbe 正常，也需要通过其他方式（比如 readinessProbe、日志监控、外部监控工具等）来确保 Pod 的健康状况。1.检查 livenessProbe 的配置是否正确，确保它指向正确的端口和路径，并且服务器能够响应。3.探针可能受到 Pod 内部资源瓶颈的影响，例如 CPU 或内存过载，导致探针响应延迟。4.有些时候，即使 livenessProbe 失败，Pod 也可能仍然在正常运行。1.探针可能因为错误的配置（例如，探针指向的端口或路径错误）而误报。

应用日志一般输出为 stdout/stderr，或者写入日志文件。针对前者，容器日志会被保存到节点上的特定位置，此时可以使用日志代理（如 Fluentd、Filebeat）并部署为 Daemonset 的方式进行采集，但是存在日志丢失的可能，因为一旦 pod 被删除，对应的容器日志文件也会被删除，而日志代理可能还未完成全部日志的采集。通过挂载持久化存储并写入日志文件的方式则可以避免丢失。应用日志要怎么采集，会不会有丢失的情况？

‌文件卷挂载‌：将ConfigMap的配置数据挂载到容器的文件系统中，这样应用程序可以直接读取这些文件。一旦ConfigMap更新，Kubelet会创建一个新的目录存放最新的文件，并通过更改符号链接来实现无缝的配置切换，而不需要重启Pod‌。‌环境变量‌：将ConfigMap的配置数据注入到容器的环境变量中，这样应用程序可以直接使用这些环境变量。‌编写ConfigMap的yaml文件创建‌：通过编写yaml文件定义ConfigMap的内容‌。‌使用目录创建‌：将目录中的文件作为ConfigMap的内容。

在Kubernetes环境中，当容器发生OOM时，根据Pod的RestartPolicy配置（默认是Always），容器会被重启，但Pod本身不会被重建‌。.‌资源限制‌：在Pod的资源配置中设置适当的内存和CPU限制，确保容器不会消耗过多的系统资源。‌系统资源竞争‌：多个容器共享有限的系统资源，当某个容器的内存使用量过高时，可能导致OOM。‌当容器发生OOM（Out-of-Memory）时，容器会被重启，但Pod不会被重建。‌内存分配不足‌：容器请求的内存超过了其可用的内存限制。容器OOM的原因和影响。

选择不同的调度策略会影响集群的资源利用效率和 Pod 的响应时间。MostAllocated 策略可以充分利用节点的资源，但可能导致某些节点资源紧张。‌在默认情况下，新的 Pod 会被调度到没有 Pod 的节点上‌。Kubernetes 的调度过程会考虑各种因素，包括节点的资源使用情况、Pod 的资源请求和限制等。在不考虑各种配置和节点资源相同的情况下，默认的调度策略是选择资源使用率最低的节点，即 LeastAllocated 策略‌。调度器会根据 Pod 的资源需求和节点的资源使用情况来决定调度策略。

它的性能受到多个因素的影响，包括节点数量、网络延迟、磁盘性能等。虽然增加节点数量可以提高系统的可用性和容错性，但在节点数过多时，可能会增加网络通信的开销，导致性能下降。此外，节点的增加也需要考虑数据同步的开销，过多的节点可能会增加数据同步的复杂性和时间，进而影响响应速度和系统效率。在设计和部署etcd集群时，需要根据具体的业务需求、网络条件、硬件性能等因素综合考虑，以达到最佳的性能和可用性平衡。此外，还需要注意节点的磁盘性能，因为etcd所在宿主机的磁盘性能差会直接影响etcd的性能‌。

‌etcd的Lease租约‌是一种机制，用于客户端与服务端之间的活性检测。因此，需要在到达TTL时间之前续租，以实现客户端与服务端之间的保活。需要注意的是，etcd的性能受到多种因素的影响，包括etcd grpc api层延时、etcd客户端使用不当、etcd boltdb性能不佳以及etcd内存索引层中锁使用不当等。此外，etcd的Lease租约机制还提供了其他功能，如撤销租约（Revoke）、续订租约（Renew）等，这些功能通过服务端中的Lessor接口和客户端Lease接口提供的方法实现‌。

2015年，etcd被Kubernetes选中作为其默认的分布式存储系统之一，这极大地提高了etcd的普及率。近年来，etcd在社区的维护下持续更新和改进，新增了一些重要特性，如gRPC proxy扩展和Range Stream等，极大地提高了etcd的读取性能和稳定性‌。从最初的服务发现、共享配置以及一致性保障（如数据库选主、分布式锁等），到后来的服务发现、发布订阅消息、负载均衡、分布式通知与协调、分布式锁、分布式队列、集群监控等，etcd的应用场景越来越广泛‌。

Docker 容器的数量受到宿主机的资源限制，包括CPU、内存和存储空间等。具体的容器数量取决于宿主机的硬件配置和资源使用情况。在实际操作中，创建过多的容器可能会导致资源竞争和性能问题，所以你应当根据宿主机的实际情况合理安排容器的数量。为了评估能创建多少容器，你需要考虑到每个容器的资源需求，并根据宿主机的总资源进行合理规划。B. 和宿主机的cpu/memory 资源有关系。宿主机上运行的其他应用程序和服务的资源占用情况。宿主机的CPU核心数量和每个核心的线程能力。宿主机的内存大小和是否有足够的交换空间。