嘉宾简介：杨乐，时速云联合创始人，时速云软件基础架构负责人，商品安全负责人。
kubernetes1.0刚刚发布，开源社区400多位贡献者一年的尽力，多达14000屡次的代码提交，终究达到了之前估计的milestone, 并意味着这个开源容器编列体系能够正式在出产环境运用，必将推进容器生态及周边工业的前进开展。本次共享首要介绍kubernetes1.0较新的功用特性，包含效劳发现方法及较新版别对应的设置改变，怎样用dns方法构建内网效劳发现，存储支撑，怎样解决集群存储及怎样运用rbd的方法将ceph存储块附加到Pod，监控，怎样在集群方法下建立监控体系等论题。以及介绍Kuberentes官方发布时官方说到的功用理念及将来有些的功用拓展，包含k8s商品司理Craig McLuckie所提及的kubernetes的整体愿景等。
下文是本次的共享收拾：
首先介绍 k8s v1.0的有些较新的特征，包含dns负载均衡，k8s监控和k8s ha高可用性的方法等
1. DNS，负载均衡
k8s效劳发现通用两种方法， kube-proxy和DNS， 在v1之前，Service富含字段portalip 和publicIPs， 别离指定了效劳的虚拟ip和效劳的出口机ip，publicIPs可恣意指定成集群中恣意包含kube-proxy的节点，可多个。portalIp 经过NAT的方法跳转到container的内网地址。在v1版别中，publicIPS被约好废弃，标记为deprecatedPublicIPs，仅用作向后兼容，portalIp也改为ClusterIp, 而在service port 界说列表里，增加了nodePort项，即对应node上映射的效劳端口。
这么portlist里仅仅是一个容器端口到效劳端口的maping，这种方法和marathon里的方法相似。loadbalancer项里是供给给外部clouder provider运用的，云供给商能够经过获取loadbanancer指定的进口ip和对应的虚拟效劳进口，来树立自界说的效劳衔接通道，或许经过获取endpoint或pod直接将拜访导入containter。当然，假如loadbanancer在集群外部，需求自行解决连入集群内网的疑问。
dns效劳发现，就是在k8s内网树立一套pod组合，对外供给dns效劳。dns效劳组自身是放在k8s渠道里的，一起又给k8s渠道供给效劳。这个和监控的效劳组合相似，当然也能够独自拿出来，以standalone的方法在k8s渠道之外运转供给效劳。
dns效劳以addon的方法，需求装置skydns和kube2dns。kube2dns会经过读取kubernetes API获取效劳的clusterIP和port信息，一起以watch的方法查看service的变化，及时搜集变化信息，并将关于的ip信息提交给etcd存档，而skydns经过etcd内的dns记载信息，开启53端口对外供给效劳。大概的dns的域名记载是 servicename.namespace.tenx.domain, "tenx.domain"是提前设置的主域名。
举例来说，假如在K8s中创立了一个效劳“mysql-service", namespace是"tenxcloud", 这时会在skydns中构成记载 mysql-service.tenxcloud.tenx.domain。在后续创立的pod中，假如依然以namespace 为tenxcloud创立，那么在pod内能够直接用 mysql-service 来拜访上述效劳，但假如在别的的namespace内拜访，就需求加上命名空间称号，如mysql-service.tenxcloud。实际上终究的url是要加上端口号，需求在servcie界说中给端口命名，比方mysql-service 的拜访端口是 {"name": "mysqlport" , "targetport": 3306, "protocol": "tcp"}, 那么关于的3306,关于的 DNS SRV记载是 _mysqlport._tcp.mysql-service.tenxcloud
kubernetes 支撑以 "link"方法衔接跨机容器效劳，但link的方法依赖于效劳的发动次序,容错功用较差，官方愈加引荐以dns的方法来构建。
2. kubernetes监控
对比老的版别 kubernetes需求外接cadvisor,首要功用是将node主机的container metrics抓取出来。在较新的版别里，cadvior功用被集成到了kubelet组件中，kubelet在与docker交互的一起，对外供给监控效劳。
kubernetes集群规模内的监控首要由kubelet, heapster和storage backend(如influxdb)构建。Heapster能够在集群规模获取metrics和事情数据。它能够以pod的方法运转在k8s渠道里，也能够独自运转以standalone的方法。
当以pod及效劳方法运转时，heapster经过虚拟网拜访kube-apiserver, 获取一切node的信息，首要是ip地址，然后经过node节点(ip地址)上Kubelet对外供给的效劳获取对应pod的metrics。
Kubelet则经过内部集成cadvisor的组件或许终究的数据。终究，heapster会将获取的数据存储到后端, 现阶段后端存储支撑Influxdb 和GCM等。
简略介绍下Influxdb, 它是时序数据库，即一切记载都带有时刻戳属性。首要用于实时数据收集，事情盯梢记载，存储时刻图表原始数据等。它的查询言语与SQL相似，又略有不一样;对外供给RESTAPI接口。自带的操作面板能够直接把数据大略转成曲线图表。支撑守时主动运转的计算指令，比方，守时履行求取平均值并存到别的的表格，关于带有时刻坐标的数据剖析有很高的价值。现在在过时数据整理上略有瑕疵，不能守时主动铲除过往数据，需求外接相似crontab等守时东西来处理。
Inflxudb可与Grafana联系，Grafana可将influxdb数据内容非常好的呈现成图表曲线的方法，假如不需求供给对外商品的话，Grafana是很好的数据图形东西。
经过设置heapster --source 来设置数据来历，--sink 参数能够设定后端存储为influxdb。 heapster 抓取数据后，将分类存储到多个influxdb 表格中，包含cpu, memory, network, eventlog 等，别的能够设置守时计算指令来处理这些raw数据。
heapster现在未到1.0版别，关于小规模的集群监控对比便利。但关于较大规模的集群，heapster现在的cache方法会吃掉很多内存。由于要守时获取全部集群的容器信息，信息在内存的暂时存储成为疑问，再加上heaspter要支撑api获取暂时metrics，假如将heapster以pod方法运转，很简单出现OOM。所以现在主张关掉cache,并以standalone的方法独立出k8s渠道，比方独自运转在一个VM上。而influxdb也要做好数据整理作业，日志及监控信息增长会给体系带来很大烦恼，外接crontab运转铲除指令即可。但作为GoogleCloudPlatform的东西，heapster也有望以容器东西集项目的方法参加CNCF,所以主张k8s监控仍是用heapster方法来做。
3. 官方Kubernetes HA的方法
运用etcd完成master 推举，从多个Master中得到一个kube-apiserver, 确保至少有一个master可用，完成high availability。对外以loadbalancer的方法供给进口。这种方法能够用作ha，但仍未老练，据了解，将来会更新晋级ha的功用。这儿用到了kubelet的发动方法，--config参数,设置路径增加kubelet发动时刻需求做的动作。 --config=/etc/kubernetes/manifests，能够运用其创立pod。
有以下几点：
Process watcher,确保 master运转失利后主动重启，这个是必要条件。monit的方法，或许自行解决守护疑问。
牢靠的冗余存储, 运用etcd集群方法。 etcd是key value的存储方法，它的人物相似于zookeeper。etcd建立集群节点至少3个，由于推举投票终究要断定leader和follower，初始投票会假定自身都是leader, 一起又都reject对方，无法构成大都的票数。3个能够构成大都对少量的状况，而且主张把投票timeout的设置成不一样的时刻。而5个以上较为安稳。
多个kube-apiserver, 用负载均衡的方法一致起来。node节点拜访时,经过haproxy的进口，分发到不一样的apiserver, 而apiserver背面是一样的etcd集群。
用组件podmaster 模仿推举。它运用etcd完成一个推举算法。相似zookeeper的方法，推举出来的kube-apiserver被发动并作为主出口，别的的kube-apiserver处于standby的状况被中止。
装置布置 kube-sheduller和kube-controller-manager，这儿在每台master机器上一起存在一套 kube-apiserver, kube-scheduller 和kube-controller-manager,而且以localhost的方法衔接。这么当kube-apiserver被选中时，同机的kube-scheduller和kube-controoler-manager起作用，当standby时，同机的3个组件都会不可用。
也就是说，etcd集群布景下，存在多个kube-apiserver，并用pod-master确保仅是主master可用。一起kube-sheduller和kube-controller-manager也存在多个，但伴随着kube-apiserver,同一时刻只能有一套运转。
QA节选：
疑问1：有几个疑问:1.容器 net方法 网络功用损失多少，2 .k8s是怎样做到的容器主动搬迁?
杨乐：容器是建在pod里，实际上终究用的是docker 的 网络参数，同pod里不必转发，是docker自身的功用，在虚拟网络里，是以NAT的方法。
疑问2：K8s是不是界说的一个pod的容器集群是只布置在同一个主机上?
杨乐：到现在是，同一个pod里的containerS 是布置在同一台主机的。
疑问3：这个图里的loadbalancer是装置在哪里的?一切的客户端以及kubelete会衔接这个嘛?
杨乐：loadbanlancer能够恣意当地，只要能拜访到集群，会作为api的出口。
疑问4：K8s中的etcd放在容器里的吗?
杨乐：不必放在里边，能够放进去，也能够在外面。（文章来自南京欣才PHP培训机构）
