master高可用

架构

master节点——整个集群的控制中枢

1. Kube-APIServer：集群的控制中枢，各个模块之间信息交互都需要经过Kube-APIServer，同时它也是集群管理、资源配置、整个集群安全机制的入口。
2. Controller-Manager：集群的状态管理器，保证Pod或其他资源达到期望值，也是需要和APIServer进行通信，在需要的时候创建、更新或删除它所管理的资源。
3. Scheduler：集群的调度中心，它会根据指定的一系列条件，选择一个或一批最佳的节点，然后部署我们的Pod。
4. Etcd：键值数据库，报错一些集群的信息，一般生产环境中建议部署三个以上节点（奇数个）。

node节点——工作节点

Worker、node节点、minion节点

1. Kubelet：负责监听节点上Pod的状态，同时负责上报节点和节点上面Pod的状态，负责与Master节点通信，并管理节点上面的Pod。
2. Kube-proxy：负责Pod之间的通信和负载均衡，将指定的流量分发到后端正确的机器上。
3. 查看Kube-proxy工作模式：curl 127.0.0.1:10249/proxyMode
   1. Ipvs：监听Master节点增加和删除service以及endpoint的消息，调用Netlink接口创建相应的IPVS规则。通过IPVS规则，将流量转发至相应的Pod上。
   2. Iptables：监听Master节点增加和删除service以及endpoint的消息，对于每一个Service，他都会场景一个iptables规则，将service的clusterIP代理到后端对应的Pod。

其他组件

1. Calico：符合CNI标准的网络插件，给每个Pod生成一个唯一的IP地址，并且把每个节点当做一个路由器。
2. CoreDNS：用于Kubernetes集群内部Service的解析，可以让Pod把Service名称解析成IP地址，然后通过Service的IP地址进行连接到对应的应用上。
3. Docker：容器引擎，负责对容器的管理。

搭建

…

kubeadm搭建

…

二进制搭建

…

探针

1. StartupProbe：k8s 1.16版本后新加的探测方式，用于判断容器内应用程序是否已经启动。如果配置了startupProbe，就会先禁止其他的探测，直到它成功为止，成功后将不在进行探测。
2. LivenessProbe：用于探测容器是否运行，如果探测失败，kubelet会根据配置的重启策略进行相应的处理。若没有配置该探针，默认就是success。
3. ReadinessProbe：一般用于探测容器内的程序是否健康，它的返回值如果为success，那么久代表这个容器已经完成启动，并且程序已经是可以接受流量的状态。

检测方式

1. ExecAction：在容器内执行一个命令，如果返回值为0，则认为容器健康。
2. TCPSocketAction：通过TCP连接检查容器内的端口是否是通的，如果是通的就认为容器健康。
3. HTTPGetAction：通过应用程序暴露的API地址来检查程序是否是正常的，如果状态码为200~400之间，则认为容器健康。

探针检查参数配置

initialDelaySeconds: 60       # 初始化时间
timeoutSeconds: 2     # 超时时间
periodSeconds: 5      # 检测间隔
successThreshold: 1 # 检查成功为1次表示就绪
failureThreshold: 2 # 检测失败2次表示未就绪

执行顺序

在 Kubernetes 中，三种探针（Liveness Probe、Readiness Probe 和 Startup Probe）的执行顺序如下：

1. Startup Probe（启动探针）：当容器启动时，首先执行 Startup Probe。它会在容器启动后立即开始运行，并在其成功之前不会影响容器的状态。如果 Startup Probe 失败，Kubernetes 将认为容器启动失败，并可能触发容器的重启。

2. Liveness Probe（存活探针）：一旦容器成功启动，并且 Startup Probe 成功，Kubernetes 开始执行 Liveness Probe。Liveness Probe 用于检测容器是否存活。如果 Liveness Probe 失败，Kubernetes 将重启容器，以尝试恢复容器的健康状态。

3. Readiness Probe（就绪探针）：一旦容器成功启动，并且 Liveness Probe 成功，Kubernetes 开始执行 Readiness Probe。Readiness Probe 用于检测容器是否准备好接收流量。如果 Readiness Probe 失败，Kubernetes 将停止将流量转发到容器，直到探针恢复为成功。

通过同时配置这三种探针，可以实现更全面的容器管理和健康检查策略。Startup Probe 可以用于确保容器在启动过程中成功启动，Liveness Probe 可以用于检测容器是否存活，而 Readiness Probe 可以用于检测容器是否准备好接收流量。

每个探针可以根据容器的需要进行配置，并具有不同的检测频率、超时时间和探测逻辑。这样，Kubernetes 可以根据这些探针的结果来判断容器的健康状况，并采取相应的行动，如重启容器、停止转发流量等。

需要注意的是，配置探针时应根据应用程序的需求进行权衡和调整，以确保适当的容器管理和健康检查策略。

为什么有了livenessProbe和readnessProbe还要有StartupProbe（1.16）

Startup Probe（启动探针）在容器启动过程中起着独特的作用，与 Liveness Probe（存活探针）和 Readiness Probe（可读探针）有所不同。虽然 Liveness Probe 和 Readiness Probe 可以用于检测容器的状态和可用性，但 Startup Probe 具有以下特点：

1. 启动过程中的延迟：在容器启动后，Liveness Probe 和 Readiness Probe 可能需要一定的时间才能开始执行和检测容器状态。这意味着在容器刚启动时，它们可能会返回失败的结果。Startup Probe 旨在在容器启动的早期阶段执行，以便更快地检测容器的启动状态。

2. 避免误判：Liveness Probe 和 Readiness Probe 可能会因为容器启动时的瞬时问题而导致误报。例如，容器可能在启动时进行初始化或加载依赖项，这可能会导致短暂的不可用状态。通过使用 Startup Probe，可以将容器的启动过程与正常的运行状态分开，以避免误判和过早地重启容器。

3. 针对特定的容器启动问题：有些应用程序在启动时可能需要进行一些特定的操作，如数据库初始化、数据加载或网络连接等。Startup Probe 可以用于检测这些特定的启动问题，并在启动失败时防止容器接收流量。一旦 Startup Probe 成功，Liveness Probe 和 Readiness Probe 将接管以持续监测容器的状态。

综上所述，Startup Probe 提供了一个独立的探针来检测容器的启动过程，并确保容器在正常运行之前成功完成启动。它与 Liveness Probe 和 Readiness Probe 相互补充，提供了更全面的容器管理和健康检查策略。

零宕机发布

pod退出流程

preStop

可以执行，

# 杀掉进程
kill `pgrep app`

然后新的容器启动后就可以直接服务了。

如果写sleep xxs，会导致不生效：

只会执行30多秒

无状态服务Deploy

用于部署无状态的服务，这个最常用的控制器。一般用于管理维护企业内部无状态的微服务，比如configserver、zuul、springboot。可以管理多个副本的Pod实现无缝迁移、自动扩容缩容、自动灾难恢复、一键回滚等功能。

Q&A

k8s为什么选用etcd做kv存储，而不是redis？

Kubernetes（简称k8s）选择使用etcd作为其默认的键值存储（KV存储）的原因有以下几点：

1. Consistency guarantees: 在分布式系统中，保证一致性是非常重要的。etcd是一个分布式的一致性存储，能够提供强一致性保证，确保所有节点的视图都是相同的。而Redis虽然支持主从复制和哨兵机制，但它不支持多主同步，并且不保证强一致性，因此不太适合用于Kubernetes这样对一致性要求很高的系统。

2. Performance and scalability: Kubernetes需要一个高性能、高可扩展性的存储系统来存储其状态信息，etcd采用了基于Raft协议的分布式一致性算法，能够提供高可用性和高可扩展性。而Redis虽然也具有高性能和可扩展性，但不如etcd在多节点分布式场景下的表现。

3. Open source and community support: etcd是一个开源项目，与Kubernetes一样，也由CNCF（云原生计算基金会）维护。这意味着etcd拥有一个庞大的社区支持，能够吸引更多的开发者为其贡献代码和提供支持。

综上所述，etcd比Redis更适合用于Kubernetes的KV存储，因为它提供了强一致性保证、高性能和可扩展性，并拥有一个庞大的开源社区支持。

为什么说"redis不保证强一致性"？

Redis是一个内存中的键值存储系统，其在默认情况下提供的是最终一致性（Eventual Consistency），而不是强一致性（Strong Consistency）。最终一致性指的是在一段时间内，系统中的不同节点可能会拥有不同的数据视图，但在一定时间后，所有节点最终会达成一致。而强一致性则保证系统在任何时刻的任何节点的数据视图都是相同的。

Redis提供的主从复制和哨兵机制可以提高系统的可用性和容错能力，但是这些机制并不能保证数据的强一致性。当主节点出现故障时，哨兵会自动将从节点中的某一个节点升级为主节点，但在这个过程中，可能会出现数据丢失或数据不一致的情况，因为新的主节点可能没有完全复制之前主节点的数据，或者有些客户端可能会在主从切换的过程中访问旧的主节点，导致数据不一致。

因此，Redis在设计时并不是一个强一致性的存储系统，而是更注重性能和可扩展性的最终一致性存储系统。在分布式系统中，强一致性是非常重要的，因为它能够保证所有节点的数据视图都是一致的，避免了数据不一致和错误。在一些强一致性要求比较高的场景下，如分布式事务、分布式锁等场景，Redis可能并不是最合适的选择。