- 正如我们所有人都知道 IT 部门推出了数千个容器，其任务在分布式系统中遍布全球众多节点。
- 在这种情况下，公司可以使用能够为基于云的应用程序提供敏捷性，横向扩展功能和DevOps 实践的东西。
- 因此，该公司可以使用 Kubernetes 来定制他们的调度架构并支持多种容器格式。这使得容器任务之间的亲和性成为可能，从而提供更高的效率，并为各种容器网络解决方案和容器存储提供广泛支持。
- 公司可以通过构建 CI/CD 管道来实现 DevOps 方法，但是这里可能出现的一个问题是配置可能需要一段时间才能启动并运行。
- 因此，在实施 CI/CD 管道之后，公司的下一步应该是在云环境中工作。一旦他们开始处理云环境，他们就可以在集群上安排容器，并可以在 Kubernetes 的帮助下进行协调。这种方法将有助于公司缩短部署时间，并在各种环境中加快速度。
- 为了给数百万客户提供他们期望的数字体验，公司需要一个可扩展且响应迅速的平台，以便他们能够快速地将数据发送到客户网站。现在，要做到这一点，公司应该从他们的私有数据中心（如果他们使用任何）转移到任何云环境，如 AWS。
- 不仅如此，他们还应该实现微服务架构，以便他们可以开始使用 Docker 容器。一旦他们准备好基础框架，他们就可以开始使用最好的编排平台，即 Kubernetes。这将使团队能够自主地构建应用程序并快速交付它们。
- 那么，为了解决这个问题，我们可以将他们的单片代码库转移到微服务设计，然后每个微服务都可以被视为一个容器。因此，所有这些容器都可以在 Kubernetes 的帮助下进行部署和协调。
- 团队可以试验容器编排平台，例如 Kubernetes，并在数据中心运行。因此，通过这种方式，公司可以生成模板化应用程序，在五分钟内部署它，并在此时将实际实例集中在暂存环境中。
- 这种 Kubernetes 项目将有数十个并行运行的微服务，以提高生产率，即使节点出现故障，也可以立即重新安排，而不会影响性能。
- 这个问题的解决方案就是 Kubernetes。Kubernetes 确保资源得到有效优化，并且只使用特定应用程序所需的那些资源。因此，通过使用最佳容器编排工具，公司可以有效地实现资源分配。
- 公司可以采用集装箱化的概念。一旦他们将所有应用程序部署到容器中，他们就可以使用 Kubernetes 进行编排，并使用像 Prometheus 这样的容器监视工具来监视容器中的操作。
- 因此，利用容器的这种使用，在数据中心中为它们提供更好的容量规划，因为它们现在将受到更少的限制，因为服务和它们运行的硬件之间存在抽象。
- 该公司可以使用 Docker 环境，组建一个横截面团队，使用 Kubernetes 构建 Web 应用程序。这种框架将帮助公司实现在最短的时间内将所需产品投入生产的目标。
- 因此，在这样的机器运行的情况下，公司可以向所有具有各种环境的客户发放电子邮件。
- 该公司可以将其基础设施分解为微服务，然后采用 Kubernetes。这将使公司在不同的云基础架构上运行各种工作负载。
- 由于公司的目标是从单一应用程序转向微服务，它们最终可以逐个构建，并行构建，只需在后台切换配置。然后他们可以将这些内置微服务放在 Kubernetes 平台上。
- 因此，他们可以从一次或两次迁移服务开始，并监控它们以确保一切运行稳定。一旦他们觉得一切顺利，他们就可以将其余的应用程序迁移到他们的 Kubernetes 集群中。
- 一般查看系统资源是否满足，然后就是查看 pod 日志看看原因。
- describe 通过这个参数查看 pod 失败的原因。
- 还有就是看组件日志，apiserver 等组件日志，有没有异常。
- 访问不到看看网络插件状态和日志，还有就是 dns 状态和日志。
k8s 上面会跑大量的 pod/容器。 特别是集群相关的控制面 容器、业务容器，有时候我们要对容器日志进行监控与分析处理，这时一套好用的日志系统就格外的重要。
而成熟的日志解决方案有哪些呢？ 以前的 ELK ， k8s 主推的基于云原生的 EFK ，这里的 F 是 CNCF 认证的子项目 fluentd ，fluentd 是 ruby 的项目，由于个人体验习惯与 yaml 配置，以及项目特点， 选择了 filebeat ，所以 整套日志系统使用的技术包括（elasticsearch、fidlebeat 、kibana）。
- raw 表：确定是否对该数据包进行状态跟踪
- mangle 表：为数据包设置标记
- nat 表：修改数据包中的源、目标 IP 地址或端口
- filter 表：确定是否放行该数据包（过滤）
- INPUT：处理入站数据包
- OUTPUT：处理出站数据包
- FORWARD：处理转发数据包
- POSTROUTING 链：在进行路由选择后处理数据包
- PREROUTING 链：在进行路由选择前处理数据包
- 由于典型的应用程序具有跨多个主机运行的容器集群，因此所有这些容器都需要相互通信。因此，要做到这一点，您需要一些可以平衡负载，缩放和监视容器的东西。
- 由于 Kubernetes 与云无关，并且可以在任何公共/私有提供商上运行，因此必须选择简化容器化部署。
- Kubernetes 主节点控制节点，并且在节点内部存在容器。现在，这些单独的容器包含在 Pod 内，每个 Pod 内，您可以根据配置和要求拥有各种数量的容器。
- 因此，如果必须部署 Pod，则可以使用用户界面或命令行界面来部署它们。然后，在节点上调度这些Pod，并根据资源需求将 Pod 分配给这些节点。kube-apiserver 确保在 Kubernetes 节点和主组件之间建立了通信。
- kube – apiserver 遵循横向扩展架构，并且是主节点控制面板的前端。这将公开Kubernetes 主节点组件的所有 API，并负责在 Kubernetes 节点和 Kubernetes 主组件之间建立通信。
- kube-scheduler调度程序负责在工作节点上分配和管理工作负载。因此，它根据资源需求选择最合适的节点来运行计划外的 Pod，并跟踪资源利用率。它可以确保未在已满的节点上调度工作负载。
- 副本集和复制控制器执行几乎相同的操作。它们两者都确保在任何给定时间都运行指定数量的 Pod 副本。不同之处在于使用选择器来复制容器。副本集使用基于集合的选择器，而复制控制器使用基于权益的选择器。
- 基于股权的选择器：这种类型的选择器允许按标签键和值进行过滤。因此，以通俗易懂的术语来说，基于权益的选择器将仅查找具有与标签词组完全相同的词组的豆荚。
- 示例：假设您的标签键为 app = nginx，那么使用此选择器，您只能查找标签为 app 等于 nginx 的吊舱。
- 基于选择器的选择器：这种类型的选择器允许根据一组值过滤键。因此，换句话说，基于选择器的选择器将查找其标签已在集合中提及的 Pod。
- 示例：说您的标签密钥说（nginx，NPS，Apache）中为 app。然后，使用此选择器，如果您的应用等于 nginx，NPS 或 Apache 中的任何一个，则选择器会将其视为真实结果。