# kubernets native cloud 实践 功能 | 组件 | ---|--- version|v1.13.5 master管理方式|kubespray docker version|v18.03 docker Storage Driver|overlay network plugins|flannedl(vxlan) 服务网关|ingress-nginx CI/CD|jenkins 监控|prometheus-operator 日志| efk rabbitmq|v3.17 redis-cluser|v5.0.2 ### version - 新版kube-proxy 使用ipvs 替换iptable 的nat 转发。 实现方式和kube-router一样 - dns 组件 由 core dns 替换 SkyDNS, dns解析性能提升 - 可实现磁盘i/o 的资源限制 ### master 管理方式 - rancher 类似kubeadmin k8s核心组件都采用容器化方式部署。同时提供友好的UI 管理界面 - rancher 提供灵活的扩展方式 - rancher 过度依赖docker。 底层docker 出问题， 导致整个集群宕机 - kubespray k8s 核心组件使用二进制方式部署。 - kubespray 依赖ansible 实现灵活的扩展方式 > 个人偏向使用kubespray 管理集群服务,更加灵活可塑。 rancher 适合小规模场景使用。 ### HA mode - 常见方案 haproxy+keepalive - kubespray及rancher 都支持HA 管理 ### docker version - v17.03 经过官方验证 ### docker Storage Driver - centos7.5 默认kernel 以支持 overlay 驱动 ### network plugins - 在公有云可选方案 vxlan 或 gw-host - Vxlan 可实现 跨域访问。因为多次封包 性能有消耗 - gw-host 不能跨域访问。依赖二层路由，性能优势明显 - 阿里云 aws 都有gw-host 专属驱动。EX:ali-vpc - [gw-host github项目地址](https://github.com/coreos/flannel/blob/master/Documentation/backends.md) ### 服务与发现 #### 第一种场景 user ---> service - nginx-ingress - NGINX 二次封装 ，依赖 service name 实现服务自动注册于发现 - 基本流程: user --> ingress --> service name --> pod #### 第二种场景 service--> service - 依赖 k8s 自身dns 服务 与 zookeeper 配置集中管理 - app1 service name地址注册到 zookeeper EX: uniauth-server.default.svc.cluster.local - app2 从zookeeper 获取 service name 地址 #### nginx-ingress 与 kong ingress 对比 kong ingress 类似一个 api-getway - 金丝雀发布 - 暂时无release - [kong ingress 官方地址](https://getkong.org/) > 个人觉得 kong ingress 会一统天下 #### Orchestrate Common Functionality  ### ci/cd #### 第一阶段 - 套用点融当前ci 流程，使用yaml文件方式管理 - 应用配置文件无法剥离 - 应用回滚依赖 git branch - 快速迁移服务能力较弱。 #### 第二阶段 - 依赖helm 实现应用管理 - 应用配置集中管理 - helm依赖Deployment 实现版本回滚 - 实现服务快速部署能力，真正做到安装即用 ### 监控 Prometheus -operator - 全面实现监控服务的自动发现 - 原生支持prometheus 集群部署 - 聚合报警功能 - 高效的查询性能 [prometheus-operators实践文档链接](https://www.kancloud.cn/huyipow/prometheus)  ### 日志服务 - efk - 在每一个pod 里面启动一个fluentd ，通过pod 共享volume 实现日志的采集 - es实例化方式部署