KubeOperator 的定位

!!! warning “” KubeOperator 是一个开源的轻量级 Kubernetes 发行版。与 OpenShift 等重量级 PaaS 平台相比,KubeOperator 只专注于解决一个问题,就是帮助企业规划(Day 0)、部署(Day 1)、运营(Day 2)生产级别的 Kubernetes 集群,并且做到极致

what-is-ko

!!! warning “” 云原生正在快速兴起,三个互相关联的领域在同步进化:

  1. - 基础设施方面: 物理资源 虚拟化资源 容器化( Kubernetes )资源 的演进
  2. - 开发模式方面: 瀑布模型 敏捷开发 DevOps 的演进
  3. - 应用架构方面: 单体架构 多层次架构 微服务 的演进

开源版和企业版的区别

=== “开源版本” !!! warning “” 和同属飞致云旗下的 JumpServer 开源堡垒机一样,KubeOperator 的核心功能全部开源,坚持按月发布新版本,永久免费使用

=== “企业版本” !!! warning “” 相比 KubeOperator 开源版,KubeOperator 企业版提供面向企业级应用场景的 X-Pack 增强包,以及高等级的原厂企业级支持服务,有效助力企业构建并运营生产级别的 K8s 集群 !!! warning “X-Pack 增强包”

  1. * 自定义 Logo 配色
  2. * 对接 LDAP
  3. * 增加消息中心
  4. * 支持邮箱、钉钉、企业微信告警
  5. * 集群健康评估
  6. * 对接 F5
  7. * 多集群配置管理

与其他工具的区别

=== “差异” !!! warning “” KubeOperator 不仅提供 Day 1 部署功能,还提供 Day 2 的 K8s 集群升级、扩容、监控、检查、备份恢复等功能

  1. ![overview](img/faq/overview.png)

=== “优势” !!! warning “” KubeOperator 的优势包括:

  1. - 提供可视化的 Web UI,大大降低部署和管理 Kubernetes 的门槛;
  2. - 提供离线的、经过全面验证和测试的安装包;
  3. - VMwareOpenstack FusionCompute 等云平台紧密对接,能够实现一键虚机自动创建和部署(基于 Terraform Ansible);
  4. - KubeOperator 会提供经过充分验证的成熟企业级存储和网络方案。

Kubernetes 集群方案

!!! warning “”

  1. * 基于物理机部署大的 Kubernetes 集群: 通过 namespace 实现租户的隔离
  2. * 基于 IaaS 平台之上部署多个 Kubernetes 集群: 为每个租户分配独立的 Kubernetes 集群
  3. !!! warning ""
  4. 这两种方案各有好处,在 Kubernetes 采纳初期,使用第二种方案更为理性,因为:
  5. * 如果是单一大集群,升级会影响所有租户,风险比较大;
  6. * IaaS 平台上有成熟的、基于软件定义的存储和网络方案,落地更容易和灵活;
  7. * KubeOperator VMwareOpenstack IaaS 方案紧密集成,可以实现全栈的自动化,集群交付快,伸缩快。

KubeOperator 部署方式

!!! warning “” 基于 kubeadm 容器化部署 Kubernetes 集群

原生 Kubernetes 的好处

!!! warning “”

  1. * KubeOperator 已经通过云原生基金会的 [Kubernetes 软件一致性认证](https://landscape.cncf.io)。
  2. * Kubernetes 迭代很快,且只维护最新的三个大版本。如果采纳其他发行版,可能很容易出现和原生版本脱节的情况。
  3. * 由于 Operator Helm 等日趋成熟,很多发行版的功能,比如 CI/ CD, Istio 等都可以通过 addon 方式部署到 Kubernetes 集群里面。Kubernetes 集群及其里面的应用应该是分离的,各自迭代升级。

KubeOperator 支持的存储

=== “NFS” !!! warning “” 手动模式和自动模式下的集群都支持 NFS 作为持久化存储

=== “LocalStorage” !!! warning “” 本地持久化存储

=== “External Ceph” !!! warning “” 创建成功之后,会在集群中初始化 ceph provisioner 相关 pod

=== “Rook-Ceph” !!! warning “” 需要指定 ceph 集群所需磁盘(集群所有节点都必须包含指定的磁盘,如sdb,sdc…)

=== “vSphere” !!! warning “” 集群服务器必须在指定 Folder 中(自动模式创建集群默认 Folder 为 kubeoperator),并且服务器名称要和集群 node 节点名称保持一致

=== “OceanStor

!!! warning “Static and Dynamic PVs 的支持情况取决于所选择的存储。以 vSphere 平台为例,各种存储选项可以参考此文章

Kubernetes 软件一致性认证

!!! warning “” 是的。KubeOperator 已经通过认证,具体请参加: https://landscape.cncf.io

与 Rancher 的区别

!!! warning “” Rancher 是完整的容器管理平台,KubeOperator 仅专注于帮助企业规划、部署和运营生产级别的 Kubernetes 集群,和 KubeOperator 有可比性的是 Rancher RKE,而不是 Rancher 全部

!!! warning “” KubeOperator 推荐企业采纳解耦的方式来实现云原生之路,也就是说容器云平台与其之上的 DevOps 平台、微服务治理平台、AI 平台、应用商店等是解耦的。

KubeOperator 部署机的推荐配置

!!! warning “” KubeOperator 部署机配置取决于初始化 k8s 集群节点数量,推荐配置参考如下:

集群节点数量 部署机推荐配置
1-5 2C 4G
6-10 4C 8G
11-50 8C 16G
51-100 16C 32G
101-200 32C 64G
> 200 64C 128G

K8s master 节点的推荐配置

!!! warning “” Kubernetes 集群中 master 节点配置取决于 worker 节点数量,推荐配置参考如下:

worker 节点数量 master 推荐配置
1-5 1C 4G
6-10 2C 8G
11-100 4C 16G
101-250 8C 32G
251-500 16C 64G
> 500 32C 128G

KubeOperator 其他说明

!!! warning “”

  1. * KubeOperator 自身重启、升级或者挂掉不会影响其创建和管理的 Kubernetes 集群(KubeOperator 是一个 100% 旁路系统,其与被管 Kubernetes 集群完全解耦)
  2. * 重启 Kubernetes 集群节点后,Kubernetes 等服务会自动恢复正常

Harbor 访问故障

!!! warning “” 可以通过 Web UI 访问,但是 docker login 不成功

=== “第一步” !!! warning “” 开启 TLS,修改 enable = true harbor_tls_enable

=== “第二步” !!! warning “” 配置一个固定的 NodePort 端口,端口不要和现有环境冲突即可 harbor_tls_enable

=== “第三步” !!! warning “” 修改 externalURL: https://worker:port , 如图: 172.16.10.100是 worker 节点的IP,30003 是第二个步骤中为 NodePort 设置的固定端口 harbor_tls_enable

!!! warning “” 点击右上角“部署”按钮,进行部署

!!! warning “” 在本地 Docker 客户端配置 daemon.json,使之信任 Harbor 私有仓库

  1. ```yaml
  2. {
  3. ...
  4. "insecure-registries" : [
  5. "172.16.10.100:30003"
  6. ]
  7. ...
  8. }
  9. ```

!!! warning “” 重启 docker 服务后执行 docker login 命令,输入正确的用户名和密码进行登录

  1. ```sh
  2. $ systemctl restart docker
  3. $ docker login 172.16.10.100:30003
  4. Username: admin
  5. Password:
  6. Login Succeeded
  7. ```

!!! warning “不论用 Ingress 还是 ClusterIP 对 Harbor 进行服务暴露,externalURL 一定要和实际访问 Harbor 时的 URL 一致,否则 docker login 认证时将会失败”