Kubernetes(初学K8s)记录

简单介绍一下Kubernetes

Kubernetes（常简称为K8s）是一个开源的容器编排系统，它用于自动化部署、扩展和管理容器化应用程序。简单来说，K8s可以帮助你管理运行在多台计算机上的容器，使它们像一个整体一样工作。

以下是关于K8s的详细介绍：

K8s的核心功能：

• 自动化部署和回滚：
  • K8s可以自动将应用程序的容器部署到集群中的各个节点上，并监控应用程序的运行状况。
  • 如果出现问题，K8s可以自动回滚到之前的版本，确保应用程序的稳定性。
• 服务发现和负载均衡：
  • K8s可以为每个容器提供一个唯一的IP地址，并提供服务发现机制，使容器之间可以相互通信。
  • K8s还提供负载均衡功能，可以将流量均匀地分配到多个容器上，提高应用程序的性能。
• 自我修复：
  • K8s可以自动重启失败的容器，替换死亡的节点，并杀死不响应健康检查的容器。
  • 这确保了应用程序的高可用性。
• 存储编排：
  • K8s可以自动挂载所需的存储系统，包括本地存储、云存储和网络存储。
  • 这使得容器可以持久化存储数据。
• Secret和配置管理：
  • K8s可以安全地管理应用程序的敏感信息和配置，而无需将它们硬编码到容器镜像中。
• 水平扩缩：
  • K8s可以根据应用程序的负载情况，自动增加或减少容器的数量。
  • 这使得应用程序可以弹性地应对不同的流量。

K8s的常见应用场景：

• 微服务架构：
  • K8s非常适合部署和管理微服务应用程序，它可以帮助你轻松地管理大量的微服务容器。
• 持续集成/持续交付（CI/CD）：
  • K8s可以与CI/CD工具集成，实现自动化部署和发布。
• 大数据处理：
  • K8s可以用于部署和管理大数据处理应用程序，如Spark和Hadoop。
• 云计算：
  • K8s是云计算领域的核心技术之一，各大云服务提供商都提供了K8s服务。
• 混合云和多云环境：
  • K8s 具有可移植性，这让它能很好的在不同的环境中运行，所以它能很好的管理混合云和多云环境。

为什么使用K8s：

• 提高应用程序的可用性和稳定性。
• 简化应用程序的部署和管理。
• 提高资源利用率。
• 加速应用程序的开发和发布。

如何做到管理大量的微服务容器

服务架构的核心挑战

首先，让我们回顾一下微服务架构的核心概念。微服务架构将一个大型应用程序分解为一组小型、独立的服务。每个服务都负责特定的业务功能，并且可以独立开发、部署和扩展。

然而，这种架构也带来了一些挑战：

• 服务数量庞大： 一个复杂的应用程序可能包含数十甚至数百个微服务。
• 服务之间的通信： 微服务之间需要进行频繁的通信，这需要高效的网络和可靠的服务发现机制。
• 服务部署和管理： 每个微服务都需要独立部署和管理，这增加了运维的复杂性。
• 服务扩展和弹性： 每个微服务都需要能够根据负载进行独立扩展，以保证应用程序的性能和可用性。
• 服务健康监测与自我修复： 需要时刻监控微服务的健康状态，并在出现故障时自动进行修复。

K8s如何解决这些挑战

K8s 提供了一系列功能，可以有效地解决微服务架构面临的挑战：

• 容器编排：
  • K8s 可以自动化部署、扩展和管理容器化的微服务。
  • 它将微服务打包成容器，并将其部署到集群中的各个节点上。
  • 这简化了微服务的部署和管理，并提高了应用程序的可移植性。
• 服务发现和负载均衡：
  • K8s 提供了内置的服务发现机制，使微服务之间可以轻松地相互通信。
  • 它还提供了负载均衡功能，可以将流量均匀地分配到多个微服务实例上。
  • 这提高了应用程序的性能和可用性。
• 自动化部署和回滚：
  • K8s 支持自动化部署和回滚，可以快速、安全地发布新版本的微服务。
  • 这简化了微服务的发布流程，并提高了应用程序的迭代速度。
• 弹性伸缩：
  • K8s 可以根据微服务的负载情况，自动增加或减少微服务实例的数量。
  • 这使得微服务能够弹性地应对不同的流量，并保证应用程序的性能和可用性。
• 健康检查和自我修复：
  • K8s 可以定期检查微服务的健康状态，并在出现故障时自动重启或替换失败的微服务实例。
  • 这提高了应用程序的可靠性和稳定性。

举例说明

假设你有一个电子商务应用程序，它包含以下微服务：

• 用户服务：管理用户账户。
• 产品服务：管理产品信息。
• 订单服务：处理用户订单。
• 支付服务：处理用户支付。

使用 K8s，你可以将每个微服务打包成一个容器，并将其部署到 K8s 集群中。K8s 会负责管理这些容器的运行，并提供服务发现、负载均衡、弹性伸缩等功能。

例如，当订单量增加时，K8s 可以自动增加订单服务和支付服务的实例数量，以保证应用程序的性能。如果某个微服务出现故障，K8s 会自动重启或替换它，以保证应用程序的可用性。K8s在常见的厂商中是一个普遍应用的状态，OpenAI在2023年第一季度的时候就宣布他们将K8s应用于管理7500个节点，说明对于多微服务架构来说，这的确是一个极佳的工具。

实际常见问题处理

现在有8台服务器，同时有8个docker服务，请你告诉我，我用k8s之后他会自动的管理这些服务吗，k8s服务需要单独的一台服务器吗？另外如果其中一个服务的负载很高，这时候k8s会怎么做

K8s 是否会自动管理这些服务？

是的，使用 K8s 后，它会自动化管理这些 Docker 服务，具体如下：

• 容器编排：
  • K8s 会将您的 Docker 容器（即服务）封装在 Pod 中。
  • 它负责在您的 8 台服务器（集群节点）上部署和运行这些 Pod。
  • 您可以通过 K8s 的声明式配置文件（例如 Deployment）来定义您期望的服务状态（例如副本数量）。
• 服务发现和负载均衡：
  • K8s 提供了 Service 资源，用于在集群内部暴露您的服务。
  • 它会自动为您的服务提供一个稳定的内部 IP 地址和 DNS 名称，使得其他服务可以方便地访问它。
  • K8s 还可以实现服务间的负载均衡，将流量均匀地分配到不同的 Pod 实例。
• 健康检查和自我修复：
  • K8s 会定期对您的 Pod 进行健康检查（例如通过 liveness 和 readiness probes）。
  • 如果某个 Pod 出现故障，K8s 会自动将其重启或替换。
• 弹性伸缩：
  • 您可以使用 K8s 的 Horizontal Pod Autoscaler (HPA) 功能，根据服务的 CPU 或内存使用率自动调整 Pod 副本数量。

K8s 服务是否需要单独的服务器？

• 控制平面：
  • K8s 的控制平面（包括 API server、etcd、controller manager 和 scheduler 等组件）负责整个集群的管理。
  • 在生产环境中，通常建议将控制平面部署在多台服务器上，以实现高可用性。
  • 但是，对于小型集群或开发环境，也可以将控制平面部署在单台服务器上。
• 工作节点：
  • 您的 Docker 服务（Pod）运行在 K8s 的工作节点上。
  • 您的 8 台服务器都可以作为工作节点，运行您的 Docker 服务。
  • 所以说，不一定需要单独的服务器，但是控制平面，建议在生产环境，部署在多台服务器上面，达到高可用。

如果其中一个服务的负载很高，K8s 会怎么做？

• 水平扩缩（Horizontal Pod Autoscaling，HPA）：
  • 如果配置了 HPA，K8s 会根据服务的 CPU 或内存使用率自动增加 Pod 副本数量。
  • 例如，如果某个服务的 CPU 使用率超过了设定的阈值，HPA 会自动增加该服务的 Pod 实例，以分担负载。
• 负载均衡：
  • K8s 的 Service 资源会将流量均匀地分配到所有可用的 Pod 实例。
  • 当 Pod 副本数量增加时，负载均衡器会自动将新的 Pod 实例纳入流量分配。
• 资源限制：
  • 您可以在 K8s 中为每个 Pod 设置资源限制（例如 CPU 和内存）。
  • 这样可以防止某个服务过度占用资源，影响其他服务的运行。
• 节点资源：
  • 如果节点资源不够用，那么可以给k8s集群增加节点，让更多的pod平均分布在集群中，达到负载均衡的目的。

"K8s 会根据服务的 CPU 或内存使用率自动增加 Pod 副本数量。 "

这里我有一点问题，例如我有一个docker服务是运行的mysql，那么你创建副本之后，你如何确保副本和正式数据一定保持一致呢，而且你的负载均衡策略该如何做呢

数据一致性问题

• 有状态服务的挑战：
  • 像 MySQL 这样的数据库是有状态的，这意味着它们需要持久化存储数据。简单地增加 Pod 副本并不意味着数据会自动同步。
  • 如果多个 MySQL 副本同时写入数据，可能会导致数据冲突和不一致。
• 解决方案：
  • Operator 模式：
  • 对于像 MySQL 这样的复杂有状态服务，通常使用 Kubernetes Operator。Operator 是一种特定的应用控制器，它知道如何正确管理有状态应用。
  • MySQL Operator 可以确保副本之间的数据同步，例如通过 MySQL 的主从复制或 Group Replication。
  • StatefulSet：
  • Kubernetes 的 StatefulSet 资源可以为有状态应用提供稳定的网络标识和持久化存储。
  • StatefulSet 可以保证 Pod 的顺序部署和删除，以及稳定的网络标识，这对于数据库集群非常重要。
  • 持久化存储：
  • 确保使用持久化存储（Persistent Volumes）来存储 MySQL 数据。这样，即使 Pod 被删除或重新创建，数据也不会丢失。
• 关于mysql的数据同步方式：
  • 主从复制：
  • 通过配置mysql的主从复制，来达到数据同步的目的。
  • Group Replication：
  • mysql的组复制，也是一个很好的数据同步方案。

负载均衡策略

• 读写分离：
  • 对于 MySQL 数据库，常见的负载均衡策略是读写分离。
  • 将写操作路由到主数据库，将读操作路由到从数据库。
  • 可以使用 Kubernetes Service 或 Ingress 控制器来实现读写分离。
• Service 策略：
  • Kubernetes Service 提供了多种负载均衡策略，例如：
  • ClusterIP：
    • 在集群内部提供一个虚拟 IP 地址，用于访问服务。
  • NodePort：
    • 在每个节点上打开一个端口，用于从集群外部访问服务。
  • LoadBalancer：
    • 在云平台上创建一个外部负载均衡器，用于从集群外部访问服务。
  • 定制化负载均衡：
  • 对于更复杂的负载均衡需求，可以使用 Service Mesh 技术（例如 Istio）或定制化的负载均衡器。
• 如何实践：
  • Operator 的作用：
  • MySQL Operator 通常会提供内置的负载均衡功能，例如自动配置读写分离。
  • 外部负载均衡器：
  • 可以使用外部负载均衡器（例如 HAProxy 或 Nginx）来实现更高级的负载均衡策略。

关键考虑因素

• 数据一致性是首要任务：
  • 在进行数据库扩缩容时，必须确保数据一致性。
• 选择合适的工具：
  • MySQL Operator 和 StatefulSet 是管理有状态应用的强大工具。
• 监控和警报：
  • 密切监控数据库的性能和健康状况，并设置警报，以便及时发现和解决问题。

"通过 MySQL 的主从复制"

这种复制是经常进行的吗？如果不经常进行并且又采用读写分离的话，会不会导致读从数据的时候并不是最新数据？如果经常进行复制的话 会不会对服务器负债造成太大压力

主从复制的频率和数据延迟

• 复制的本质：
  • MySQL 的主从复制是基于二进制日志 (binlog) 的。主服务器将数据变更记录到 binlog 中，从服务器读取 binlog 并重放这些变更，从而实现数据同步。
  • 这个过程是异步的，这意味着主服务器在提交事务后，不会立即等待从服务器完成复制。
• 复制延迟：
  • 因此，主从复制存在一定的延迟。延迟的大小取决于多种因素，包括网络延迟、主服务器的负载、从服务器的性能以及 binlog 的大小。
  • 在理想情况下，延迟可能非常小，几乎是实时的。但在高负载或网络不稳定的情况下，延迟可能会增加。
• 读写分离和数据一致性：
  • 如果您采用读写分离，并且复制延迟较高，那么从服务器上的数据可能会落后于主服务器。
  • 这意味着，读取从服务器可能会返回过时的数据。
  • 为了减少这种风险，您可以：
  • 监控复制延迟，并设置警报，以便在延迟过高时发出通知。
  • 对于需要强一致性的读取操作，将其路由到主服务器。
  • 优化主从复制配置，以减少延迟。

复制对服务器负载的影响

• 主服务器负载：
  • 主服务器需要将数据变更写入 binlog，这会增加一定的 I/O 负载。
  • 在高写入负载下，这可能会对主服务器的性能产生影响。
• 从服务器负载：
  • 从服务器需要读取 binlog 并重放数据变更，这也会增加一定的 CPU 和 I/O 负载。
  • 如果从服务器的性能不足，可能会导致复制延迟增加。
• 减轻负载：
  • 为了减轻复制对服务器负载的影响，您可以：
  • 使用高性能的硬件。
  • 优化 MySQL 配置，例如调整缓冲池大小和 I/O 设置。
  • 使用半同步复制或组复制，这些复制模式可以减少主服务器的写入负载。
  • 使用合理的binlog格式，row格式会比statement格式消耗更多的资源。
• 总结：
  • MySQL主从复制是经常进行的，当主数据库发生写操作的时候，就会把记录写入到binlog日志里面，然后从数据库会实时的读取binlog日志，从而达到数据同步的目的。
  • MySQL主从复制会对服务器造成一定的负担，但是可以通过优化配置和使用高性能硬件来减轻这种负担。

什么是半同步复制或者组复制？row格式会比statement格式消耗更多的资源，这是为什么，他们两种格式分别是什么样的？有什么明显区别，优缺点是什么

半同步复制（Semi-Synchronous Replication）

• 工作原理：
  • 半同步复制是介于异步复制和全同步复制之间的一种折中方案。
  • 在半同步复制中，主服务器在提交事务后，不会立即返回给客户端，而是等待至少一个从服务器接收到 binlog 并写入 relay log 后，才会返回给客户端。
  • 这样可以提高数据的一致性，但也会带来一定的延迟。
• 优点：
  • 提高了数据一致性，减少了数据丢失的风险。
• 缺点：
  • 增加了延迟，影响了主服务器的性能。
  • 在网络出现问题的时候，会出现主服务器等待超时的情况，影响主服务器的运行。

组复制（Group Replication）

• 工作原理：
  • 组复制是一种基于分布式一致性协议的复制方案。
  • 多个 MySQL 服务器组成一个复制组，每个事务的提交都需要经过组内大多数成员的同意。
  • 这样可以实现高可用性和数据一致性。
• 优点：
  • 提供了更高的数据一致性和可用性。
  • 支持多主模式，可以实现多活架构。
• 缺点：
  • 性能开销较大，延迟较高。
  • 对网络要求比较高。

binlog 的 row 格式和 statement 格式

• statement 格式：
  • 记录的是 SQL 语句。
  • 优点：binlog 文件较小，节省磁盘空间。
  • 缺点：在某些情况下，可能会导致数据不一致，例如使用了 NOW() 或 RAND() 等不确定性函数。
• row 格式：
  • 记录的是每一行数据的变更。
  • 优点：可以保证数据的一致性。
  • 缺点：binlog 文件较大，消耗更多的磁盘空间和网络带宽。
  • row格式会记录每一行数据的变更，所以当变更的数据量比较大的时候，会产生大量的日志，消耗更多的资源。
• 区别和优缺点总结：

导出到 Google 表格

为什么 row 格式消耗更多资源？

• row 格式需要记录每一行数据的变更，包括变更前和变更后的数据。
• 当更新大量数据时，row 格式会产生大量的 binlog 日志，这会增加 I/O 负载和网络传输量。
• statement 格式仅仅记录了sql语句，所以产生日志量比row格式小的多。

详细解释一下核心概念、架构、网络和一些组件

K8s 核心概念

• Pod：
  • Pod 是 K8s 中最小的可部署单元。它包含一个或多个共享存储和网络的容器。
  • 示例：一个 Pod 可以包含一个运行应用程序的容器和一个运行日志收集器的容器。
• Deployment：
  • Deployment 用于管理无状态应用程序的部署和更新。它定义了应用程序的期望状态，并自动维护该状态。
  • 示例：创建一个 Deployment，指定运行 3 个 Nginx Pod 副本。如果某个 Pod 失败，Deployment 会自动创建一个新的 Pod。
• Service：
  • Service 提供了一种稳定的网络访问方式，用于访问一组 Pod。它定义了访问 Pod 的策略，并自动进行负载均衡。
  • 示例：创建一个 Service，将流量路由到运行 Nginx 的 Pod。
• StatefulSet：
  • StatefulSet 用于管理有状态应用程序的部署和更新，例如数据库。它为每个 Pod 提供稳定的网络标识和持久化存储。
  • 示例：使用 StatefulSet 部署 MySQL 集群，每个 MySQL 实例都有唯一的网络标识和持久化存储。
• Namespace：
  • Namespace 提供了一种将集群资源划分为多个虚拟集群的方式。它用于隔离不同的应用程序或团队。
  • 示例：创建一个名为 "dev" 的 Namespace，用于开发环境。

控制平面和工作节点

• 控制平面：
  • 控制平面是 K8s 集群的大脑。它负责管理整个集群，包括调度 Pod、维护期望状态和处理 API 请求。
  • 组件：
  • kube-apiserver： 提供 API 接口，用于与集群交互。
  • etcd： 存储集群的配置和状态数据。
  • kube-scheduler： 调度 Pod 到工作节点。
  • kube-controller-manager： 运行控制器，用于维护期望状态。
• 工作节点：
  • 工作节点是运行 Pod 的服务器。它们负责执行控制平面下达的任务。
  • 组件：
  • kubelet： 运行在每个工作节点上，负责管理 Pod 和容器。
  • kube-proxy： 维护网络规则，实现服务负载均衡。

K8s 网络

• Pod 网络：
  • Pod 网络允许 Pod 之间相互通信。每个 Pod 都有一个唯一的 IP 地址。
• Service 网络：
  • Service 网络提供了一种稳定的方式，用于访问一组 Pod。
• 外部访问：
  • 外部访问允许外部用户访问集群中的服务。
• CNI 网络插件：
  • CNI（容器网络接口）网络插件负责实现 K8s 的网络模型。
  • 常用插件：
  • Calico： 提供高性能的网络和网络策略。
  • Flannel： 提供简单的网络覆盖。
• Service 类型：
  • ClusterIP： 在集群内部提供一个虚拟 IP 地址，用于访问服务。
  • NodePort： 在每个节点上打开一个端口，用于从集群外部访问服务。
  • LoadBalancer： 在云平台上创建一个外部负载均衡器，用于从集群外部访问服务。

K8s 架构和组件

• kube-apiserver：
  • API server 是 K8s 控制平面的前端。它提供了一个 RESTful API，用于与集群交互。
  • 示例：使用 kubectl 命令行工具，通过 API server 创建 Pod。
• etcd：
  • etcd 是一个分布式键值存储系统，用于存储 K8s 集群的配置和状态数据。
  • 示例：etcd 存储了集群中所有 Pod、Service 和 Deployment 的信息。
• kubelet：
  • kubelet 运行在每个工作节点上，负责管理 Pod 和容器。
  • 示例：kubelet 接收来自 API server 的指令，创建和启动 Docker 容器。