《5-使用Kubernetes1.0构建PaaS平台-方应》.ppt

使用kubernetes1.0构建CaaS 二、组件详解 一、kubernetes架构 三、kubernetes实践 四、问题与展望 目 录 CONTENTS PATR 1 Kubernetes架构 Master： apiserver controller scheduler Node： kubelet（cadvisor） proxy Other： heastper influxdb skyDNS 目录 Kubernetes架构 01 apiserver controller scheduler node PATR 2 组件详解 职责 1.处理api请求 2.用户验证和授权 3.资源验证 4.创建各种资源 5.数据持久化，写etcd 目录 apiserver 01 目录 controller 02 职责 1.管理endpoint 2.管理rc 3.管理node，维护健康状态 4.管理namespace 5.为pod调度volume 6.生成serviceAccount token 目录 scheduler 03 职责 调度每一个新创建的pod 算法 针对每一个等待调度的pod，分为两个步骤来决定调度到那个node 方法：轮询每个node 1.可不可以调度 2.合不合适调度 目录 Node/kubelet 04 职责 1.管理pod生命周期 2.管理pod所需volume 3.汇报node健康状态 4.收集pod运行数据 5.资源回收（containers、images） 6.管理pod所需资源 目录 Node/kube-proxy 05 职责 通过apiserver监听endpoint变更，根据endpoint修改iptables、启动代理线程，将数据流量导入pod PATR 3 Kuberneter实践 安全 1.认证：密码、token、证书 2.授权：ABAC模式 目录 Apiserver实践 01 生成证书推荐使用easyrsa工具 /kubernetes/kubernetes/blob/master/cluster/saltbase/salt/generate-cert/make-ca-cert.sh 原生支持通过配置文件配置token的方式来认证，以及配置授权文件，缺点是不能动态生效 网易蜂巢系统中采共用了IaaS层的keystone 资源 资源限制分为几个层次namespace：ResourceQuota，pod和container：limitRange 目录 Apiserver实践 02 serviceAccount通过服务端配置的私钥来生成的用于访问kubernetes服务的token，本质是一个secrets，secret安全性比直接存在文件系统中要好 蜂巢在实际中也采用了secret特性 返回 集群 Kubernetes目前只能叫做高可靠，通常的做法是部署多套（每一套apiserver、controller、scheduler位于同一台机器），通过一个HA来进行切换，同时只有一套是处于服务状态中，etcd推荐采用集群部署 目录 集群部署 03 集群 如果集群使用https，而且希望通过证书来和客户端进行双向认证，apiserver前端可以使用haproxy进行透传 目录 集群部署 04 官方的切换脚本有个小问题，在实际使用中，如果apiserver挂掉不能够正确的切换 这种HA的方式在性能方面显得有些局促，apiserver和scheduler都不能进行水平扩展 返回 除了高可靠，在实际使用docker中，存储、网络、日志、灰度发布、快速扩容等也受到广泛关注。 目录 存储 05 存储 Kubernetes在存储方面提供了多种选择，gce、aws、iscsi等，使用这些volume可以通过PersistentVolume（pv）、和PersistentVolumeClaim（pvc）来实现。 网易蜂巢在kubernetes中集成了网易NBS（云存储），容器则全部运行在SSD上，同时支持挂载基于SSD的云存储。 Kube-proxy Kube-proxy实际是一个代理，为每一个service创建一个线程，通过iptables将访问服务ip的流量导入这个线程，由其转发至pod 目录 网络 06 如果多个pod在同一个node上，会采用简单的轮询。Kube-proxy在规模大的时候会有性能问题。可以考虑使用haproxy或者其他负载均衡产品。社区也在考虑全用iptables来实现流量转发。 日志 Kubernetes支持flutend到处日志。每个contai