今天，如果你正在运行Kubernetes，你就会知道安全性不是“内置的”。为了保护集群，你必须配置，添加或构建其他控件。其中一些控件是Kubernetes的一部分，例如基于角色的访问控制（RBAC），为容器指定受信任的镜像仓库，以及在容器运行时的扫描工具中进行分层。 在Kubernetes中，即使你可以“正确”地完成所有这些操作，但仍然会出错。虽然你可以使用安全性比较高的RBAC控件，只使用受信任

Kubernetes的部署很困难。这在很大程度上要归因于这样一个事实，即Kubernetes不仅是一个工具，而且是十几种组件的集合，这些组件提供了从应用程序部署和升级，日志记录和监视到持久数据存储的功能。 Kubernetes是迄今为止Github上最活跃的项目之一，已经积累了超过8万次提交和550个发布。在本地或在云中安装高可用Kubernetes集群的过程已经有足够多的文档，在大多数情况下，我

Kubernetes被越来越多的公司采用，但几乎所有组织都面临挑战。许多企业开始采用Kubernetes时没有专门的管理策略，各个团队创建自己的集群来满足特定的业务功能整个企业之间没有一致的结构，策略或管理实践。随着集群和工作负载数量的增长，由于它们是独立管理和治理的，从而导致集群蔓延，从而妨碍组织实现容器和Kubernetes的全部价值，导致资源的浪费。 解决这一挑战并同时提高投资回报率的一种方

redis集群有三种模式，主从，sentinel（哨兵），cluster。关于这三种模式的介绍和部署，其它文章也有相关介绍，本人参考了他人的博客完成了三种模式的部署，博客地址在评论区。 目前redis使用主从模式，集群信息如下： [root@master redis]# redis-cli -h 192.168.122.7 -a 123456 info replication Warning: U

如果你使用Kubernetes 的时间足够长，那么你肯定需要对其进行调试，但它是一个分布式系统，有很多组件，有时组件很难理解。在这篇文章中，我将介绍八个命令来调试Kubernetes 集群，它将帮助你了解集群并确保运行 Pod 的核心功能可用。 这篇文章将假设你拥有集群的管理员访问权限。我们将假设你收到了一个可以访问集群的 kubeconfig 文件，但你被告知集群已损坏。你从哪里开始？ 以下是要

本文来自 KubeSphere 社区用户 Liu_wt 投稿，欢迎所有社区用户参与投稿或分享经验案例。 本文将从零开始，在干净的机器上安装 Docker、Kubernetes (使用 kubeadm)、Calico、Helm 与 KubeSphere，通过手把手的教程演示如何搭建一个高可用生产级的 Kubernetes，并在 Kubernetes 集群之上安装 KubeSphere 容器平台可视化

随着 Kubernetes 被广泛的作为基础设施，各大云厂商都相继推出了各自的 Kubernetes 集群服务。那么在多个集群上，如何跨集群实践 DevOps 流水线呢？本文将主要以示例的形式给出回答。 提示，本文需要对 KubeSphere 和 DevOps 相关的知识具有一定了解，具体包括 Kubernetes 资源创建、生成 Sonarqube Token、获取集群 kubeconfig 等

为什么开源 KubeEye Kubernetes 作为容器编排的事实标准，虽然架构优雅功能也非常强大，但是 Kubernetes 在日常运行过程中总会有一些疑难杂症和隐性的问题让集群管理员和 Yaml 工程师们非常头疼。 基础设施守护进程问题：ntp 服务中断； 硬件问题：如 CPU，内存或磁盘异常； 内核问题：内核死锁，文件系统损坏； 容器运行时问题：运行时守护进程无响应； ··· 这样的问题还

本文是上海站 Meetup 中讲师李宇根据其分享内容梳理成的文章。本文介绍了 Kubernetes 社区多集群方向的发展历程以及已有的多集群解决方案，分享在混合云的场景下, KubeSphere 如何基于 Kubefed 统一应用的分发与部署，以达到跨 region 的多活/容灾等目的。同时探讨未来多集群领域可能迈向的去中心化的架构。 视频回放 大家好，很高兴来到今天下午的 Meetup。我先简单

本文是上海站 Meetup 讲师高日耀根据其分享内容整理的文章。点击查看视频回放 MySQL 运维有哪些挑战？ 传统的物理部署方式，即把数据库部署在物理机上。对运维人员而言，会遇到图 1 中四个维度的挑战。 1、成本 自建 MySQL 数据库集群，需要的硬件设备包括：服务器、网络交换机、内存、CPU、硬盘等 硬件设备。 硬件设备成本包括：选型、购买、维护、升级、损坏、数据丢失等。 2、传统部署 每

介绍 对于生产环境，我们需要考虑 Kubernetes 集群的高可用性。本文教您部署如何在多台 AWS EC2 实例快速部署一套高可用的生产环境。要满足 Kubernetes 集群服务需要做到高可用，需要保证 kube-apiserver 的 HA ，可使用下列两种方式： AWS ELB（推荐） keepalived + haproxy 对 kube-apiserver 进行负载均衡，实现高可用

前言 KubeEye 是一款 Kubernetes 安全及配置问题检测工具，针对部署在 K8s 集群中的业务应用进行配置检测使用 OPA,针对集群部署的 Node 使用 Node-Problem-Detector 进行检测，同时除了系统内置有根据大多数业界常见场景的预定义规则，还支持用户自定义规则来进行集群检测。 架构 KubeEye 通过调用 Kubernetes API，通过匹配资源中的关键字

遇到这样一个场景，在同一套环境中需要存在多个 Host 控制面集群，因此想探索下 KubeSphere 的异地多活混合容器云管理方案。 集群角色介绍 一个兼容原生的 K8s 集群，可通过 ks-installer 来初始化完成安装，成为一个 QKE 集群。QKE 集群分为多种角色，默认是 None 角色（standalone 模式），开启多集群功能时，可以设置为 Host 或者 Member 角色

前言 Redis 是在开发过程中经常用到的缓存中间件，在生产环境中为了考虑稳定性和高可用一般为集群模式的部署。 常规部署在虚拟机上的方式配置繁琐并且需要手动重启节点，而使用 K8s 进行 Redis 集群的部署有以下优点： 安装便捷：使用镜像或者 yaml 配置文件即可一件安装 自动调度：容器挂掉后会自动调度重启和资源分配 缩扩容方便：在 扩容、缩容 方面的优点无需多说，一键伸缩 稳定高效：K8s

主要收获 了解采用服务网格技术的新兴架构趋势，特别是多云、多集群和多租户模式，如何在异构基础设施（裸机、虚拟机和 Kubernetes）中部署服务网格解决方案，以及从边缘计算层到网格的应用 / 服务连接。 了解服务网格生态系统中的一些新模式，如多集群服务网格、媒体服务网格（Media Service Mesh）和混沌网格，以及经典的微服务反模式，如“死星（Death Star） “架构。 获取最新

编者的话 本文是来自 Tetrate 工程师的分享，Tetrate 的拳头产品是 Tetrate Service Bridge（下文简称 TSB），它是在开源的 Istio 和 Envoy 基础上构建的，但为其增加了管理平面。 简介 Tetrate 的应用连接平台 Tetrate Service Bridge（TSB）提供两种网关类型，分别为一级网关（Tier-1）和二级网关（Tier-2），它们

您是否应该让多个团队使用同一个 Kubernetes 集群？ 您是否可以安全地运行来自不信任用户的不信任工作负载？ Kubernetes 是否具备多租户功能？ 本文将探讨在运行具有多个租户的集群时面临的挑战。 多租户可分为： 软多租户，适用于信任您的租户 - 比如与同一家公司的团队共享集群时。 硬多租户，适用于您不信任的租户。 您还可以混合使用！ 在租户之间共享集群的基本构建块是命名空间。 命名空

1. 受限的构建环境无法满足构建需求 default-scheduler 如上图，scheduler extender 提供了几个扩展点，当 kube-scheduler 调度流程进入该扩展阶段时，会向 sheduler extender 发送 http 请求，处理定制逻辑。部署时，可以使用 Deployment 部署 scheduler extender，修改 kube-scheduler 启动

在一个集群中2个节点需要选举，有一个节点会被选为主节点（master节点）主节点负责管理集群中的状态。对于用户来说这个ES主节点是谁都是无所谓的，我们只要连接到其中一台就可以的（我们所有操作都可以连接到任意一个节点上） ELKStack 实战之 Elasticsearch集群 [二] ELKStack ES集群介绍 ES默认使用组播的方式进行通讯，当我们将另外一台服务器配置完成后它就会去找其他节点

之前的文章介绍过传统方式安装Prometheus来监控集群，但是这种方式有一定的缺陷虽然完全可以用自定义方式来实现，但是不够灵活，不具有通用性。在自定义监控时还需要不断的更新Prometheus的配置。如果是kubernetes集群完全可以使用一种更原始的方式来实现kubernetes集群监控，即采用Prometheus Operator Prometheus Operator Prometheu