亿动网
监控云资源对于确保其正常运行、优化性能和防止停机至关重要。本文将介绍如何监控亚马逊网络服务 (AWS) EC2 实例、微软 Azure 虚拟机和 Kubernetes 集群。
AWS EC2 实例
AWS CloudWatch 是监控 EC2 实例的原生服务。它提供了以下关键指标：
- CPU 使用率
- 内存使用率
- 磁盘 I/O
- 网络吞吐量
- 状态检查
要配置 CloudWatch 监控，您需要：
- 启用 CloudWatch 监视代理
- 创建 CloudWatch 警报规则
- 查看和分析监控数据
Azure 虚拟机
Azure Monitor 是监控 Azure 虚拟机的原生服务。它提供了与 CloudWatch 类似的关键指标集，以及附加功能，例如：
- 日志记录
- 诊断
- 自动修复
要配置 Azure Monitor 监控，您需要：
- 启用 Azure Monitor 代理
- 创建 Azure Monitor 警报规则
- 查看和分析监控数据
Kubernetes 集群
对于 Kubernetes 集群，可以使用 Prometheus 和 Grafana 等开源工具进行监控。这些工具提供以下关键指标：
- Pod 和容器状态
- CPU 和内存使用率
- 网络吞吐量
- 存储使用量
要配置 Prometheus 和 Grafana 监控，您需要：
- 部署 Prometheus 集群
- 部署 Grafana 仪表盘
- 创建 Grafana 警报规则
最佳实践
无论您使用哪个监控平台，以下最佳实践对于确保有效监控至关重要：
- 定义明确的目标：确定您要监控的内容以及要实现的目标。
- 使用警报规则：配置警报规则以在关键指标超出阈值时通知您。
- 定期审查数据：定期查看和分析监控数据以识别趋势和异常情况。
- 整合自动化：使用自动化工具（如 Terraform）来配置和管理监控基础设施。
结论
通过遵循本文中的步骤，您可以有效监控 AWS EC2 实例、Azure 虚拟机和 Kubernetes 集群，以确保正常运行时间、优化性能和防止停机。
2019年20+个Kubernetes工具盘点
Kube集群部署工具
Minikube为Kubernetes提供一套本地实验环境，允许用户在本地安装并试用Kubernetes。该工具可为您提供试用体验以决定是否选用Kubernetes，且能够通过简单易操作的方式在笔记本电脑的虚拟机（VM）内启动一个单节点Kubernetes集群。此外，Minikube亦适用于Windows、Linux以及OSX，并且只需短短5分钟，就能够让您对Kubernetes的主要功能有所了解。最后，仅需一行命令即可启动Minikube仪表盘。
链接：
使用成本：免费
Kubeadm是Kubernetes自版本1.4以来就默认使用的分发工具，该工具可帮助用户在现有的基础架构上体验Kubernetes的最佳实践。尽管如此，Kubeadm无法为开发人员配置基础设施。该工具的主要优势在于其可在任何环境下启动最小的可行Kubernetes集群。需要注意的是，Kubeadm内不含任何附加组件与网络设置，因此您需要手动或使用其他工具完成相关工具的安装。
链接：
使用成本：免费
监控工具
Kubebox是一套用于Kubernetes集群的终端控制台，其能够让用户通过美观且经典的界面对集群实时状态进行管理与监控。Kubebox能够显示容器资源的使用情况、集群监控以及容器日志等。除此之外，用户还可借助Kubebox轻松导航到目标名称空间，并在目标容器中执行相关操作，借此以快速排除故障/恢复。
链接：
使用成本：免费
5. Kubedash
链接：
使用成本：免费
6. Kubernetes Operational View (Kube-ops-view)
Kube-ops-view是一款面向多个Kubernetes集群的只读系统仪表板。用户可以通过Kube-ops-view在集群、监控节点以及pod 健康 状况之间轻松导航，且其还能够为部分进程提供动画效果——例如pod的创建与终止。此外，类似于Kubedash，Kube-ops-view也将Heapster作为其数据源。
链接：
使用成本：免费
测试工具
7. Kube-monkey
Kube-monkey是Netflix公司旗下ChaosMonkey项目的Kubernetes版本。Kube-monkey是一款遵循混沌工程原理的工具，其可以随机删除Kubernetes pod，检查服务是否具备抗失效能力并帮助维持相关系统的 健康 运转。Kube-monkey也可经由TOML文件完成配置，而TOML文件不仅能够终止指定的应用程序，还可以决定恢复策略的执行时间。
链接：
使用成本：免费
8. K8s-testsuite
K8s-testsuite由两个Helm图表组合而成，适用于网络带宽测试与单个Kubernetes集群的负载测试。负载测试模拟了带有loadbots的简单网页服务器，这些服务器可在Vegeta基础上以Kubernetes微服务的形式运行。网络测试则是在内部连续对iperf3与netperf-2.7.0运行三次。这两项测试都会生成涵盖全部结果与指标的综合日志信息。
链接：
使用成本：免费
9. Test-infra
Test-infra是一套用于Kubernetes测试与结果验证的工具集合。Test-infra包括多种仪表板，分别用于显示 历史 记录、汇总故障以及当前正在测试的内容。用户可通过创建自定义测试作业以增强Test-infra套件。此外，Test-infra可在使用Kubetest的不同供应商平台上，通过模拟完整的Kubernetes生命周期实现端到端Kubernetes测试。
链接：
使用成本：免费
安全工具
10. Trireme
Trireme是一项灵活且直接的Kubernetes网络策略实现方案，其适用于任何Kubernetes集群，并允许用户管理不同集群内pod之间的流量。Tririme的主要优势在于其无需任何集中式策略管理，能够轻松实现Kubernetes中所部署的两种资源的彼此交互，并且无需配合任何复杂的SDN、VLAN标签以及子网（Trireme使用常规的L3-网络）。
链接：
使用成本：免费
12. Twistlock
链接：
使用成本：每份许可证每年1700美元起（试用版免费）。
实用的CLI工具
Cabin可作为Kubernetes集群远程管理的移动仪表板。用户可通过Cabin快速管理应用程序、扩展部署，并通过Android或iOS设备对整个Kubernetes集群实施故障排查。对于Kubernetes集群的运营者而言，Cabin无疑是一款强大的工具，其能够在故障发生时执行快速有效的补救措施。
链接：
使用成本：免费
14. Kubectx/Kubens
Kubectx是一款小型开源实用工具，其不仅能够增强Kubectl的功能表现，还能够轻松切背景，并同时与多个Kubernetes集群实现连接。另外，Kubens允许用户在Kubernetes命名空间之间进行导航。最后，这两款工具均可在bash/zsh/fishshell上提供自动补全功能。
链接：
使用成本：免费
15. Kube-shell
Kube-shell能够在运行Kubectl时提升生产力。Kube-shell能够启用命令以实施自动补全与自动建议。此外，Kube-shell还能够提供有关执行命令的内嵌文档，其甚至还可以在输入错误时执行检索与纠正命令。因此，这是一款能够在Kubernetes控制台中改进性能与生产力的工具。
链接：
使用成本：免费
开发工具
链接：
使用成本：免费
Helm是一款适用于Kubernetes的软件包管理器。其与APT/Yum/Homebrew类似，但作用对象为Kubernetes。Helm使用Char实现运行，而Char是一套用于为分布式应用程序构建Kubernetes资源清单的归档集。用户可通过创建Helm图表来实现应用程序共享。此外，Helm允许用户创建可重复的构建模式，并通过简单方式管理Kubernetes清单。
链接：
使用成本：免费
Keel允许用户自动执行Kubernetes部署更新，并能够在专用命名空间内以Kubernetes服务的形式进行启动。通过这样的组织方式，Keel可尽可能降低环境中的额外负载水平，并显著提升鲁棒性。此外，Keel可通过标签、注释以及图表强化Kubernetes服务。因此，用户只需为每个部署或Helm版本指定更新策略，即可在存储库中出现新的应用程序版本时，由Keel自动为其更新相关环境。
链接：使用成本：免费
持续集成
无服务器/函数工具
Kubeless是一款Kubernetes原生无服务器框架，能够在无需底层基础设施的前提下部署少量代码。Kubeless能够快速识别Kubernetes资源，并据此提供自动扩展、API路由、监控与故障排除等功能。Kubeless完全依赖于Kubernetes基元，因此Kubernetes用户也可以配合使用原生Kubernetes API服务器与API网管。
链接：
使用成本：免费
Fission是一款针对Kubernetes的快速无服务器框架，专注于提升开发人员的生产力与性能水平。Fission能够运行于任何环境下的Kubernetes集群当中：笔记本电脑、任何公有云或私有数据中心。用户可使用Python、NodeJS、Go、C#或PHP编写函数，然后再使用Fission将相关函数部署到Kubernetes集群。
链接：
使用成本：免费
原生服务发现
CoreDNS是一套由Go编写而成且用于执行DNS功能的插件。带有附加Kubernetes插件的CoreDNS可替换默认的Kube-DNS服务并实现针对基于KubernetesDNS服务发现的规范定义。除此之外，CoreDNS还能够监听经由UDP/TCP、TLS与gRPC传入的DNS请求
链接：使用成本：免费
原生可视化与控制
23. Kubernetes Dashboard
KubernetesDashboard是一款具备Kubernetes集群通用性且基于Web的用户界面。使用这样一套本机仪表板，用户可通过更简便的方式对Kubernetes集群实施故障排查与监控。为此，用户需要在机器与KubernetesAPI服务器之间创建一条安全的通道以实现相关仪表板的访问。这款原生KubernetesDashboard依赖于Heapster数据收集器，因此您需要预先在目标系统当中安装Heapster数据收集器。
链接：使用成本：免费
Kubernetes应用程序的保护和移动性策略
随着Kubernetes（K8s）和容器成为开发、部署、运行和扩展云原生和下一代IT应用程序的事实选择，企业正在K8s集群上运行越来越多的业务关键型应用程序。业务关键型应用程序通常是有状态的。有状态应用程序具有关联的状态、数据和配置信息，并依赖以前的数据事务来执行其业务逻辑。
Kubernetes上提供服务的业务关键型应用程序通常与传统应用程序一样具有可用性和业务连续性要求，这意味着服务中断（违反SLA）会严重影响提供商的收入和声誉。企业通常意识到，他们需要使用数据管理工具使其Kubernetes部署能够在影响服务的灾难之后或面临到新集群或环境的硬应用程序迁移任务时对服务故障具有恢复能力。
企业认识到这一需求，但使用内部开发的定制工具，这些工具很难在企业和应用程序团队之间进行扩展、应用和规范化。换句话说，这种工具是特定于应用程序的，需要为每个应用程序定制开发。因此，企业需要为其Kubernetes资产制定一个连贯一致的持久性和数据管理战略。
K8s应用程序数据持久性和管理的现状
更大的Kubernetes社区和生态系统在定义容器存储接口（CSI）方面做得非常出色，它解决了用户在有状态Kubernetes应用程序的持久存储资源调配和消耗方面的一阶问题。CSI接口还定义了数据管理原语，如对持久卷（PV）快照和克隆的支持。这些接口为存储和数据管理供应商建立综合应用数据保护和移动性解决方案奠定了基础。
Kubernetes数据管理（应用程序感知是关键），并不总是关于集群中的内容
目前还没有关于Kubernetes应用程序组成的具体定义。但是，对于大多数Kubernetes从业者和用户来说，K8s应用程序是通过包含有关应用程序的数据和元数据形成的，这些数据和元数据结合了标准K8s对象和资源（如ConfigMap、Secrets、Deployment、ReplicaSet）、Persistent Volumes（PV）和跨命名空间（在某些情况下，跨集群）的自定义资源（CRD和CRs）。因此，任何与应用程序无关的Kubernetes数据管理工具都需要考虑构成应用程序的所有这些组件。
如果不这样做，也不复制和/或备份与K8s应用程序关联的持久卷，则在灾难发生后恢复应用程序时，可能会导致一些严重的故障。将应用程序视为保护和迁移的整体单元是实现Kubernetes应用程序数据管理的关键。
使这种情况更加复杂的是主要用于公共云的云原生K8s应用程序设计模式，在公共云中，应用程序团队利用了使用完全托管的云服务（如数据库、消息队列和对象存储）的便利性、稳定性和性能。在这种情况下，根据定义，K8s应用程序不再局限于集群，而是跨集群之外的完全托管的服务。在Kubernetes集群中运行的应用程序中使用外部完全托管或自我管理的数据库是非常常见的。
在这种云原生开发设计模式的基础上，AWS和Azure等公共云使得通过Kubernetes原生API使用Kubernetes集群的完全托管服务变得更加容易。AWS Controllers for Kubernetes（ACK）和Azure Service Operator（for Kubernetes）就是例子。
Kubernetes原生持久性的替代方案——常见设计模式及其原因
如上所述，构建基于Kubernetes的现代服务的应用程序团队除了使用不限于K8s集群中使用持久卷的原生云服务外，还经常使用多种持久性技术。出现这种模式的原因有很多，包括但不限于：
——坚信Kubernetes是只运行无状态应用程序的优秀平台。
——在K8s集群上运行数据库的早期经验，或了解尝试这样做的失败项目。
——采用云原生和微服务方法，使用原生公共云DBaaS（例如AWS RDS、Google cloud SQL、Azure Cosmos DB）、第三方供应商管理的数据存储（作为SaaS提供）或自我管理的外部数据库集群构建Kubernetes应用程序，感觉很正常。这种设计范式遵守云原生设计方法，它利用这些数据服务的可伸缩性、可恢复性、弹性和灵活性，在微服务之间使用基于API的契约。
——使用对象存储满足K8s持久性需要，因为它在公共云中无处不在，并且广泛用于持久化现代应用程序。
与其他选择一样，这些持久性选择也有缺点。使用完全托管的原生公共云数据库和NoSQL数据存储可能成本高昂，并导致对一个公共云的隐式锁定。但对于那些选择单一或主要云提供商满足其IT需求的企业来说，这可能是一个不错的设计选择。为了避免云提供商锁定，采用多云战略的企业通常使用第三方ISV提供的云不可知DBaaS产品。
在其他情况下，他们在云提供商的保留实例上运行外部数据库集群（利用折扣保留实例定价），以节省成本。这样做，他们最终会自我管理数据库集群，这可能会很乏味。
使用对象存储实现Kubernetes持久性非常流行。但是，使用对象存储也会使应用程序本身的可移植性降低，因为用于访问公共云中原生对象存储服务的API不兼容，因为不支持相同的API。K8s社区正在开发一个新的标准容器对象存储接口（COSI），为使用K8s应用程序的对象存储提供公共抽象层，这将让使用对象存储的K8s应用程序的可移植性更容易。此外，对象存储不适用于许多现有应用程序，即使它们正在重构。
这对企业意味着什么？
很明显，Kubernetes应用程序的组成及其持久性需求的定义并不总是精确地映射到集群内的Kubernetes资源和连接到集群内运行的pod的持久卷。K8s数据持久性的选择非常丰富，每种选择都有其优缺点。这意味着流行的K8s应用程序数据管理功能（如备份、恢复、迁移和合规性）必须包括K8s集群内部的内容，以及可能位于集群外部且是应用程序不可分割的一部分的对象和资源。
例如，对K8s应用程序进行一致备份还意味着触发对完全管理的公共云数据库的备份，该数据库除了K8s资源、元数据和Kubernetes集群中存在的对象之外，还向该应用程序提供数据服务。除集群内K8s资源外，后续恢复过程还必须恢复外部数据库。
因此，企业必须仔细审查其K8s应用程序保护、移动性和合规性战略，并为其K8s存储和数据管理解决方案使用选择标准，以保证其应用程序团队和开发人员采用的最常见的云原生持久性设计模式。
原文链接：
2021-10-这一篇 K8S（Kubernetes）我觉得可以了解一下！！！28
Kubernetes是Google开源的分布式容器管理平台，是为了更方便的在服务器中管理我们的容器化应用。
Kubernetes简称 K8S，为什么会有这个称号？因为K和S是 Kubernetes首字母和尾字母，而K和S中间有八个字母，所以简称 K8S，加上 Kubernetes 比较绕口，所以一般使用简称 K8S。
Kubernetes即是一款容器编排工具，也是一个全新的基于容器技术的分布式架构方案，在基于Docker的基础上，可以提供从创建应用>应用部署>提供服务>动态伸缩>应用更新 一系列服务，提高了容器集群管理的便捷性。
大家可以先看一下，下面一张图，里面有我们的 mysql，redis，tomcat，nginx 等配置信息，如果我们想要安装里面的数据，我们需要一个一个手动安装，好像也可以，反正也就一个，虽然麻烦了一点，但也不耽误。
但是随着技术的发展和业务的需要，单台服务器已经不能满足我们日常的需要了，越来越多的公司，更多需要的是集群环境和多容器部署，那么如果还是一个一个去部署，运维恐怕要疯掉了，一天啥也不干就去部署机器了，有时候，可能因为某一个环节出错，要重新，那真的是吐血。。。。。，如下图所示：
如果我想要部署，以下几台机器：
如果要一个一个去部署，人都要傻掉了，这什么时候是个头，如果是某里巴的两万台机器，是不是要当场提交辞职信，所以 K8S 就是帮助我们来做这些事情的，方便我们对容器的管理和应用的自动化部署，减少重复劳动，并且能够自动化部署应用和故障自愈。
并且如果 K8S 对于微服务有很好的支持，并且一个微服务的副本可以跟着系统的负荷变化进行调整，K8S 内在的服务弹性扩容机制也能够很好的应对突发流量。
Docker-Compose是用来管理容器的，类似用户容器管家，我们有N多台容器或者应用需要启动的时候，如果手动去操作，是非常耗费时间的，如果有了 Docker-Compose只需要一个配置文件就可以帮我们搞定，但是 Docker-Compose只能管理当前主机上的 Docker，不能去管理其他服务器上的服务。意思就是单机环境。
Docker Swarm是由Docker 公司研发的一款用来管理集群上的Docker容器工具，弥补了 Docker-Compose单节点的缺陷， Docker Swarm可以帮助我们启动容器，监控容器的状态，如果容器服务挂掉会重新启动一个新的容器，保证正常的对外提供服务，也支持服务之间的负载均衡。而且这些东西 Docker-Compose 是不支持的，
Kubernetes它本身的角色定位是和 Docker Swarm是一样的，也就是说他们负责的工作在容器领域来说是相同的部分，当然也要一些不一样的特点， Kubernetes 是谷歌自己的产品，经过大量的实践和宿主机的实验，非常的成熟，所以 Kubernetes正在成为容器编排领域的领导者，其 可配置性、可靠性和社区的广大支持，从而超越了 Docker Swarm ，作为谷歌的开源项目，它和整个谷歌的云平台协调工作。
在下图中，是K8S的一个集群，在这个集群中包含三台宿主机，这里的每一个方块都是我们的物理虚拟机，通过这三个物理机，我们形成了一个完整的集群，从角色划分，可以分为两种
打一个比较形象的比喻，我们可以把Pod理解成一个豆荚，容器就是里面的豆子，是一个共生体。
Pod里面到底装的是什么？
具体怎么部署Pod里面的容器，是按照我们项目的特性和资源的分配进行合理选择的。
pause容器：
Pause容器 全称infrastucture container（又叫infra）基础容器，作为init pod存在，其他pod都会从pause 容器中fork出来，这个容器对于Pod来说是必备的 一个Pod中的应用容器共享同一个资源：
在上图中如果没有 pause容器 ，我们的Nginx和Ghost，Pod内的容器想要彼此通信的话，都需要使用自己的IP地址和端口，才可以彼此进行访问，如果有 pause容器 ，对于整个Pod来说，我们可以看做一个整体，也就是我们的Nginx和Ghost直接使用localhost就可以进行访问了，他们唯一不同的就只是端口，这里面可能看着觉得比较简单，但其实是使用了很多网络底层的东西才实现的，感兴趣的小伙伴可以自行了解一下。
在 Kubernetes中，每个Pod都会被分配一个单独的IP地址，但是Pod和Pod之间，是无法直接进行交互的，如果想要进行网络通信，必须要通过另外一个组件才能交流，也就是我们的 Service
Service是服务的意思，在K8S中 Service 主要工作就是将多个不同主机上的Pod，通过 Service 进行连通，让Pod和Pod之间可以正常的通信
我们可以把 Service 看做一个域名，而相同服务的Pod集群就是不同的ip地址， Service是通过 Label Selector来进行定义的。
使用NodePort提供外部访问，只需要在每个Node上打开一个主机的真实端口，这样就可以通过Node的客户端访问到内部的Service。
Label 一般以 kv的方式附件在各种对象上，Label 是一个说明性的标签，它有着很重要的作用，我们在部署容器的时候，在哪些Pod进行操作，都需要根据Label进行查找和筛选，我们可以理解Label是每一个Pod的别名，只有取了名称，作为K8S的Master主节点才能找到对应的Pod进行操作。
用户通过Kubectl 提交一个创建Replication Controller 请求，这个请求通过 API Server写入 etcd中，这个时候 Controller Manager 通过 API Server 的监听到了创建的命名，经过它认真仔细的分析以后，发现当前集群里面居然还没有对应的Pod实例，赶紧根据 Replication Controller 模板定义造一个Pod对象，再通 过Api Server写到我们 etcd里面
到下面，如果被 Scheduler 发现了，好家伙不告诉我？？？，无业游民，这家伙一看就不是一个好人啊，它就会立即运行一个复杂的调度流程，为这个新的Pod选一个可以落户的Node，总算有个身份了，真是让人操心，然后通过 API Server将这个结果也写到etcd中，随后，我们的Node 上运行的小管家 Kubelet 进程通过 API Server检测到这个 新生的小宝宝——“Pod”，就会按照它，就会按照这个小宝宝的特性，启动这个Pod并任劳任怨的负责它的下半生，直到Pod的生命结束。
然后我们通过 Kubectl 提交一个新的映射到这个Pod的Service的创建请求， Controller Manager 会通过Label标签查询到相关联的Pod实例，生成Service的Endpoints的信息，并通过 API Server写入到etcd中，接下来，所有 Node 上运行的Proxy进程通过 Api Server查询并监听 Service对象 与其对应的 Endpoints 信息，建立一个软件方式的负载均衡器来实现 Service 访问到后端Pod的流量转发功能。
kube-proxy：是一个代理，充当这多主机通信的代理人，前面我们讲过Service实现了跨主机、跨容器之间的网络通信，在技术上就是通过 kube-proxy 来实现的，service是在逻辑上对Pod进行了分组，底层是通过 kube-proxy 进行通信的
kubelet：用于执行K8S的命令，也是K8S的核心命令，用于执行K8S的相关指令，负责当前Node节点上的Pod的创建、修改、监控、删除等生命周期管理，同时Kubelet定时“上报”本Node的状态信息到API Server里
etcd：用于持久化存储集群中所有的资源对象，API Server提供了操作 etcd的封装接口API，这些API基本上都是对资源对象的操作和监听资源变化的接口
API Server ：提供资源对象的操作入口，其他组件都需要通过它提供操作的API来操作资源数据，通过对相关的资源数据“全量查询”+ “变化监听”，可以实时的完成相关的业务功能。
Scheduler ：调度器，负责Pod在集群节点中的调度分配。
Controller Manager：集群内部管理控制中心，主要是实现Kubernetes 集群的故障检测和恢复的自动化工作。比如Pod的复制和移除，Endpoints对象的创建和更新，Node的发现、管理和状态监控等等都是由Controller Manager 完成。
到这里K8S的基本情况我们就讲解完毕了，有喜欢的小伙伴记得 点赞关注 ，相比如Docker来说K8S有着更成熟的功能，经过谷歌大量实践的产物，是一个比较成熟和完善的系统。
关于K8S大家有什么想要了解或者疑问的地方欢迎大家留言告诉我。
我是牧小农，一个卑微的打工人，如果觉得文中的内容对你有帮助，记得一键三连，你们的三连是小农最大的动力。
