Kubernetes从部署到运维详解

NigFurst 8年前
   <p>Kubernetes是Google开源的Docker容器集群编排管理系统,为容器化的应用提供自动部署,弹性伸缩,资源调度,负载均衡和服务发现等应用云平台所需的管理功能体系。Kubernetes 的灵感源于谷歌过去15年在生产环境中运行容器的管理经验,集合了社区中先进的理念和实战技术。</p>    <p>Kubernetes对计算资源进行了更高层次的抽象,通过将容器进行细致的组合,将最终的应用服务交给用户。Kubernetes在模型建立之初就考虑了容器跨机连接的要求,支持多种网络解决方案,同时在Service层次构建集群范围的SDN网络。其目的是将服务发现和负载均衡放置到容器可达的范围,这种透明的方式便利了各个服务间的通信,并为微服务架构的实践提供了平台基础。而在Pod层次上,作为Kubernetes可操作的最小对象,其特征更是对微服务架构的原生支持。</p>    <h3><strong>一.架构及部署</strong> <strong>Architecture</strong></h3>    <p style="text-align:center"><img src="https://simg.open-open.com/show/e9a3df78be2cb43d4b868240db843de5.png"></p>    <p>Kubernetes是2014年6月开源的,采用Golang的语言开发,每一个组件互相之间使用的是Master API的方式,Kubernetes的架构模式是用Master-slave模式,并且支持多种联机网络,支持多种分布式存储架构。</p>    <p>Master的核心组件是API server,对外提供REST API服务接口。kubernetes所有的信息都存储在分布式系统ETCD中. Scheduler是kubernetes的调度器,用于调度集群的主机资源。Controller用于管理节点注册以及容器的副本个数等控制功能。</p>    <p>在Node上的核心组件是kubelet,它是任务执行者,会跟apiserver进行交互,获取资源调度信息。 kubelet会根据资源和任务的信息和调度状态与Docker去交互,调用Docker的API, 创建、删除与管理容器,而kube-Proxy可以根据从API里获取的信息以及整体的Pod架构状态组成虚拟NAT网络。</p>    <p><strong>快速部署过程</strong></p>    <p>在最新更新的kubernetes 1.4版本中,社区开发了专用的部署组件kubeadm, 用来完成kubernetes集群整体的部署过程。Kubeadm是对以往手动或脚本部署的简化,集成了manifest配置、参数设置、认证设置、集群网络部署以及安全证书的获取。需要注意的是kubeadm目前默认从gcr.io的镜像中心获取镜像,若需使用其他镜像源,需要更改源码编译出定制版本。</p>    <p>Ubuntu 16.04环境的使用过程如下:</p>    <p>设定部署主机资源</p>    <p style="text-align:center"><img src="https://simg.open-open.com/show/165cdc9a2518af23567ff85886db2063.png"></p>    <p><strong>1)在所有节点上(包括master和node)部署基础运行环境</strong></p>    <p>部署内容包括docker, kubelet, kubeadm, kubectl kubernetes-cni</p>    <p>运行如下命令:</p>    <pre>  # curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | apt-key add -  # cat <<EOF > /etc/apt/sources.list.d/kubernetes.list  deb http://apt.kubernetes.io/ kubernetes-xenial main  EOF  # apt-get update  # apt-get install -y docker.io kubelet kubeadm kubectl kubernetes-cni</pre>    <p><strong>2)部署Master</strong></p>    <p>在Master上运行 kubeadm init, 运行结束后,可获得集群的token,以及提示在node上运行的命令:</p>    <p><strong>3)添加节点</strong></p>    <p>在master上的kubeadm init的输出中获取相应的参数并在Node上运行:</p>    <p><strong>4)部署网络</strong></p>    <p>kubernete集群需要可以跨主机的网络解决方案,使得位于不同主机的pod可以相互通信。目前有多种类似的解决方案,例如weave network, calico 或者 Canal。当前使用的是weave net</p>    <p>关于网络,对于隔离要求较高的场景需求,采用calico是比较合适的选择。calico会帮助容器在主机间搭建纯二层的网络,在每个主机上维护一个路由表,用来获取目标容器所在主机的可达路径,以及本机容器的路有项。利用iptables的防火墙机制去做隔离。容器之间跨主机进行交互时,IP包从容器出发,经过本地路有表选路,通过目标网段所在主机的路有项,到达目标主机,然后在目标主机内,进入路有选路前,先经由iptables隔离规则(可设置)进行判断决定是否丢弃或返回,然后再经路有选路到目标容器,最终到达目标容器。整个过程没有任何封包解包的过程,传输效率较高。</p>    <p>隔离规则可以设定在同一用户名下的哪些容器可以被隔离成一组,被隔离的容器间可通信,而与其它容器不可通信。或者设置规则来组成更加丰富的隔离效果。</p>    <p><strong>部署组件详解</strong></p>    <p>在kubernetes 1.4版本利用kubeadm部署过程中,安装的插件包括kube-discovery,kube-proxy和kube-dns,分别负责部署阶段配置的分发, NAT网络和集群系统的dns服务。值得注意的是kube-proxy不再通过manifest来运行,是通过插件用demonset的方式来部署。</p>    <p><strong>1)kubeadm</strong></p>    <p>在kubeadm init运行阶段,首先创建验证token以及静态pod文件(manifest的文件),以及运行所需的证书和kubeconfig。完成这些工作后,kubeadm会等待apiserver的启动并正常运行,以及等待首个节点的接入。</p>    <p>由于master节点启动kubelet来运行manifest文件,并且在kubelet.conf中设置了需要连接当前主机为master,因此此master 也会作为node节点接入,并且master作为节点运行也为kube-discovery提供运行的必须环境。</p>    <p>当节点加入并且apiserver运行正常后,将标示master的角色,kubeadm.alpha.kubernetes.io/role=master。</p>    <p><strong>2)Kube-discovery</strong></p>    <p>随后在部署运行kube-discovery时,在kube-discovery所运行的pod上设置node的亲和性,并将它限制成为必须在master上运行的pod。由于kube-discovery的主要功能是证书及token等配置的管理与分发,并且后续的节点加入时只需要一个简单的master ip信息,因此将kube-discovery限制到了master节点运行,以此统一服务的入口。</p>    <p>这些通过在pod的annotations来实现</p>    <p>requiredDuringSchedulingIgnoredDuringExecution表示在调度过程中需要满足的条件,和后面的nodeSelectorTerms在一起类似于nodeselector。这样设置即可将pod限制到master主机中。</p>    <p><strong>3)Kube-dns</strong></p>    <p>从kubernetes 1.3开始,kube-dns已经不再使用etcd+skydns+kube2sky的方式。而是使用了dns缓存及转发工具dnsmasq,以及利用skydns库和本地内存缓存组合而成的kube-dns。</p>    <p>Kube-dns将从kubernetes master中监听变动的service和endpoint信息,并建立从service ip 到service name的域名映射(对于无service的,将会建立pod ip和相应域名的映射)。Kube-dns将这些信息存放在本地的内存缓冲中,并监听127.0.0.1:10053提供服务。</p>    <p>Dnsmasq是简单的域名服务、缓存和转发工具,这里利用它的转发功能将kube-dns的dns服务转接到外部,参数–server=127.0.0.1:10053。</p>    <h3><strong>二.运维管理</strong> <strong>租户资源管理Namespace(命名空间)</strong></h3>    <p>namespace 是kubernete用来做租户管理的对象。每个租户独享自己的逻辑空间,包括replication controller、 pod、 service、 deployment、configmap等。</p>    <p>常用的查看方式:</p>    <pre>  kubectl get <resource type> <resource name> --namespace=<namespace>  或查看所有namespace的某类资源  kubectl get <resource type> <resource name> --all-namespaces  例如:查看所有的pod,并希望看到所部署的节点位置  kubectl get pod –all-namespaces –o wide  查看namespace为 test的replication controller,以及labet  kubectl get rc –namespace=test –show-labels</pre>    <p><strong>配置管理ConfigMap</strong></p>    <p>当服务运行在容器中时,需要访问外部的变量,或者需要根据环境的不同更改配置文件,比如,DB以传统的方式运行在容器云之外,当服务启动时,需要初始化包含DB信息的配置文件。当需要切换db时,就需要更改配置文件, 当容器中有服务在运行时, 并不推荐登陆到容器内进行文件配置更改。</p>    <p>合理的方式是利用kubernetes的配置管理,将配置信息写入到ConfigMap, 并挂载到对应的pod中。</p>    <p>例如golang程序golang-sample需要访问配置文件db.json,内容如下:</p>    <pre>  {          "dbType": "mysql",          "host": "192.168.1.22",          "user": "tenxcloud",          "password": "password",          "port": "3306",          "connectionLimit": 200,          "connectTimeout": 20000,          "database": "sample"      }</pre>    <p>将db.json写入config.yaml中:</p>    <pre>  apiVersion: v1  data:    db.json: |-      {          "dbType": "mysql",          "host": "192.168.1.22",          "user": "tenxcloud",          "password": "password",          "port": "3306",          "connectionLimit": 200,          "connectTimeout": 20000,          "database": "sample"      }  kind: ConfigMap  metadata:    name: config-sample    namespace: sample</pre>    <p>创建configmap对象:</p>    <pre>  kubectl create –f config.yaml</pre>    <p>在 pod中添加对应的volume</p>    <pre>  apiVersion: v1  kind: Pod  metadata:    labels:      name: golang-sample    name: golang-sample    namespace: sample  spec:    containers:    - image: inde.tenxcloud.com/sample/golang-sample:latest      volumeMounts:      - mountPath: /usr/src/app/config/db/        name: configmap-1    volumes:    - configMap:        items:        - key: db.json          path: db.json        name: config-sample      name: configmap-1</pre>    <p>当pod创建运行后,服务在pod容器内只需要读取固定位置的配置文件, 当配置需要改变时, 更新ConfigMap并重新分发到pod内,这样重启容器后,容器内所挂载的配置也会相应更新。当需要pod容器同时使用一个ConfigMap 时,更新ConfigMap内容的同时,可以批量更新容器的配置。</p>    <p><strong>主机运维管理</strong></p>    <p>对于运维操作来说,kubectl是一个很便利的命令行工具,首先可以对各种资源进行操作,比如添加、获取、删除,通过更多命令参数得到指定的信息。</p>    <p>获取资源列表及详细信息的方式可通过kubectl get 来进行,具体的操作运行kubectl get –help即可。</p>    <p>实践使用过程中,对节点的运维操作会影响到应用的使用和资源的调度,比如由于配置升级需要对节点主机进行重启,需要考虑已经运行在其上的容器的状况,用户的希望是对资源池的操作尽量少的影响容器应用,同时资源池的变动和上层的容器服务解藕。</p>    <p>当需要对主机进行维护升级时,首先将节点主机设置成不可调度模式:</p>    <pre>  kubectl cordon[nodeid]</pre>    <p>然后需要将主机上正在运行的容器驱赶到其它可用节点:</p>    <pre>  kubectl drain [nodeid]</pre>    <p>当容器迁移完毕后,运维人员可以对该主机进行操作,配置升级性能参数调优等等。当对主机的维护操作完毕后, 再将主机设置成可调度模式:</p>    <pre>  kubectl uncordon [nodeid]</pre>    <p>这样新创建的容器即可以分配到该主机,可以通过kubectl patch 对资源对象进行实时修改,比如为service增加端口,为pod修改容器镜像版本。Annotation 可以帮助用户更好的设置kubernete自定义插件。用户可以在自建组件中获取资源中对应的annotation以此进行操作。通过kubectl label可以方便的对资源打标签,比如对node打标签,然后容器调度时可指定分配到对应标签的主机。</p>    <p>Kubernetes作为容器集群管理工具,为应用平台提供了基于云原生的微服务支持,其活跃的社区吸引了广大开发者的热情关注,刺激了容器周边生态的快速发展,同时为众多互联网企业采用容器集群架构升级内部IT平台设施,构建高效大规模计算体系提供了技术基础。</p>    <p> </p>    <p>来自:http://www.iteye.com/news/31929</p>    <p> </p>