Kubernetes是谷歌严格保密十几年的秘密武器——Borg的一个开源版本,是Docker分布式系统解决方案。php
- Borg
Borg是谷歌内部使用的大规模集群管理系统,基于容器技术,目的是实现资源管理的自动化,以及跨多个数据中心的资源利用率的最大化;- Endpoint(IP+Port)
标识服务进程的访问点;- Master
集群控制节点,负责整个集群的管理和控制,基本上Kubernetes全部的控制命令都是发给它,它来负责具体的执行过程,咱们后面全部执行的命令基本都是在Master节点上运行的;
- Kubernetes API Server(kube-apiserver),提供Http Rest接口的关键服务进程,是Kubernetes里全部资源的增、删、改、查等操做的惟一入口,也是集群控制的入口进程;
- Kubernetes Controller Manager(kube-controller-manager),Kubernetes里全部资源对象的自动化控制中心,能够理解为资源对象的“大总管”;
- Kubernetes Scheduler(kube-scheduler),负责资源调度(Pod调度)的进程,至关于公交公司的“调度室”;
- etcd Server,Kubernetes里全部的资源对象的数据所有是保存在etcd中;
- Node
除了Master,Kubernetes集群中的其余机器被称为Node节点,Node节点才是Kubernetes集群中的工做负载节点,每一个Node都会被Master分配一些工做负载(Docker容器),当某个Node宕机,其上的工做负载会被Master自动转移到其余节点上去;
- kubelet,负责Pod对应的容器的建立、启停等任务,同时与Master节点密切协做,实现集群管理的基本功能。一旦Node被归入集群管理范围,kubelet进程就会想Master几点汇报自身的情报,这样Master能够获知每一个Node的资源使用状况,并实现高效均衡的资源调度策略。而某个Node超过指定时间不上报信息,会被Master断定为“失联”,Node状态被标记为不可用(Not Ready),随后Master会触发“工做负载大转移”的自动流程;
- kube-proxy,实现Kubernetes Service的通讯与负载均衡机制的重要组件;
- Docker Engine(docker),Docker引擎,负责本机的容器建立和管理工做;
- Pod
- 每一个Pod都有一个特殊的被称为“根容器”的Pause容器,还包含一个或多个紧密相关的用户业务容器;
- 一个Pod里的容器与另外主机上的Pod容器可以直接通讯;
- 若是Pod所在的Node宕机,会将这个Node上的全部Pod从新调度到其余节点上;
- 普通Pod及静态Pod,前者存放在etcd中,后者存放在具体Node上的一个具体文件中,而且只能在此Node上启动运行;
- Docker Volume对应Kubernetes中的Pod Volume;
- 每一个Pod能够设置限额的计算机资源有CPU和Memory;
- Requests,资源的最小申请量;
- Limits,资源最大容许使用的量;
- Event
是一个事件记录,记录了事件最先产生的时间、最后重复时间、重复次数、发起者、类型,以及致使此事件的缘由等信息。Event一般关联到具体资源对象上,式排查故障的重要参考信息;- Label
Label能够附加到各类资源对象上,一个资源对象能够定义任意数量的Label。给某个资源定义一个Label,至关于给他打一个标签,随后能够经过Label Selector(标签选择器)查询和筛选拥有某些Label的资源对象。咱们能够经过给指定的资源对象捆绑一个或多个Label来实现多维度的资源分组管理功能,以便于灵活、方便的进行资源分配、调度、配置、部署等管理工做;
Label Selector示例:select * from pod where pod’s name=’XXX’,env=’YYY’,支持操做符有=、!=、in、not in;- Replication Controller(RC)
部署和升级Pod,声明某种Pod的副本数量在任意时刻都符合某个预期值;
- Pod期待的副本数;
- 用于筛选目标Pod的Label Selector;
- 当Pod副本数量小于预期数量的时候,用于建立新Pod的Pod模板(template);
- Replica Set
下一代的Replication Controlle,Replication Controlle只支持基于等式的selector(env=dev或environment!=qa)但Replica Set还支持新的、基于集合的selector(version in (v1.0, v2.0)或env notin (dev, qa)),这对复杂的运维管理带来很大方便。- Deployment
拥有更加灵活强大的升级、回滚功能。在新的版本中,官方推荐使用Replica Set和Deployment来代替RC,二者类似度>90%,相对于RC一个最大升级是咱们随时指导当前Pod“部署”的进度。Deployment使用了Replica Set,除非须要自定义升级功能或根本不须要升级Pod,通常状况下,咱们推荐使用Deployment而不直接使用Replica Set;
典型使用场景:
- 建立一个Deployment对象来生成对应的Replica Set并完成Pod副本的建立过程;
- 检查更新Deployment的状态来查看部署动做是否完成(Pod副本的数量是否达到预期的值);
- 更新Deployment以建立新的Pod;(好比镜像升级)
- 若是当前Deployment不稳定,则回滚到一个早先的Deployment版本;
- 挂起或者回复一个Deployment;
- Horizontal Pod Autoscaler(HPA)
意思是Pod横向自动扩容,目标是实现自动化、智能化扩容或缩容。
Pod负载度量指标:
- CPUUtilizationPercentage
一般使用一分钟内的平均值,能够经过Heapster扩展组件获取这个值。一个Pod自身的CPU利用率是该Pod当前CPU的使用量除以它的Pod Request的值。例如Pod Request定义值为0.4,当前Pod使用量为0.2,则它的CPU使用率为50%。但若是没有定义Pod Request值,则没法使用CPUUtilizationPercentage来实现Pod横向自动扩容的能力;- 应用程序自定义的度量指标,好比服务在每秒内的相应的请求书(TPS或QPS)
- Service
Service其实就是咱们常常提起的微服务架构中的一个“微服务”,经过分析、识别并建模系统中的全部服务为微服务——Kubernetes Service,最终咱们的系统由多个提供不一样业务能力而又彼此独立的微服务单元所组成,服务之间经过TCP/IP进行通讯,从而造成了咱们强大而又灵活的弹性网络,拥有了强大的分布式能力、弹性扩展能力、容错能力;
如图示,每一个Pod都提供了一个独立的Endpoint(Pod IP+ContainerPort)以被客户端访问,多个Pod副本组成了一个集群来提供服务,通常的作法是部署一个负载均衡器来访问它们,为这组Pod开启一个对外的服务端口如8000,而且将这些Pod的Endpoint列表加入8000端口的转发列表中,客户端能够经过负载均衡器的对外IP地址+服务端口来访问此服务。运行在Node上的kube-proxy其实就是一个智能的软件负载均衡器,它负责把对Service的请求转发到后端的某个Pod实例上,而且在内部实现服务的负载均衡与会话保持机制。Service不是共用一个负载均衡器的IP地址,而是每一个Servcie分配一个全局惟一的虚拟IP地址,这个虚拟IP被称为Cluster IP。- Node IP
Node节点的IP地址,是Kubernetes集群中每一个节点的物理网卡的IP地址,是真是存在的物理网络,全部属于这个网络的服务器之间都能经过这个网络直接通讯;- Pod IP
Pod的IP地址,是Docker Engine根据docker0网桥的IP地址段进行分配的,一般是一个虚拟的二层网络,位于不一样Node上的Pod可以彼此通讯,须要经过Pod IP所在的虚拟二层网络进行通讯,而真实的TCP流量则是经过Node IP所在的物理网卡流出的;- Cluster IP
Service的IP地址。特性以下:
- 仅仅做用于Kubernetes Servcie这个对象,并由Kubernetes管理和分配IP地址;
- 没法被Ping,由于没有一个“实体网络对象”来响应;
- 只能结合Service Port组成一个具体的通讯端口;
- Node IP网、Pod IP网域Cluster IP网之间的通讯,采用的是Kubernetes本身设计的一种编程方式的特殊的路由规则,与IP路由有很大的不一样;
- Volume
能够经过以下命令查看Volume信息:
注:Node、Pod、Replication Controller和Service等均可以看做是一种“资源对象”,几乎全部的资源对象均可以经过Kubernetes提供的kubectl工具执行增、删、改、查等操做并将其保存在ectd中持久化存储。node
- 轻装上阵,小团队便可轻松应付从设计实现到运维的复杂的分布式系统;
- 全面拥抱微服务架构;
- 迁移方便,能够很方便的搬迁到公有云或基于OpenStack的私有云上;
- 超强的横向扩容能力;
64位CentOS7mysql
systemctl disable firewalld
systemctl stop firewalld
yum install -y etcd kubernetes
安装完毕后,须要修改以下两个配置文件:
* 修改/etc/sysconfig/docker,将其中OPTIONS内容设置为:OPTIONS=’–selinux-enabled=false –insecure-registry grc.io’;
* 修改/etc/kubernetes/apiserver,把–admission-control参数的ServiceAccount删除;linux
systemctl start etcd systemctl start docker systemctl start kube-apiserver systemctl start kube-controller-manager systemctl start kube-scheduler systemctl start kubelet systemctl start kube-proxy
若是不肯定服务是否启动成功,能够运行下面命令进行一一确认web
ps aux | grep 服务名
Java Web应用
注:Tomcat有可能没法正常启动,缘由是虚机的内存和CPU设置太小,请酌情调大!sql
docker pull kubeguide/tomcat-app:v2apache
docker pull daocloud.io/library/mysql:latest编程
mysql-rc.yaml后端
apiVersion: v1
kind: ReplicationController
metadata:
name: mysql
spec:
replicas: 1
selector:
app: mysql
template:
metadata:
labels:
app: mysql
spec:
containers:
- name: mysql image: mysql ports: - containerPort: 3306 env: - name: MYSQL_ROOT_PASSWORD value: "123456"
kubectl create -f mysql-rc.yaml
kubectl get rc
kubectl get pods
mysql-svc.yaml
apiVersion: v1 kind: Service metadata: name: mysql spec: ports: - port: 3306 selector: app: mysql
kubectl create -f mysql-svc.yaml
kubectl get svc
myweb-rc.yaml
kind: ReplicationController
metadata:
name: myweb
spec:
# Pod的数量 replicas: 1 # spec.selector与spec.template.metadata.labels,这两个字段必须相同,不然下一步建立RC会失败。 selector: app: myweb template: metadata: labels: app: myweb # 容器组的定义 spec: containers: # 容器名称 - name: myweb # 容器对应的镜像 image: kubeguide/tomcat-app:v1 ports: # 在8080端口上启动容器进程,PodIP与容器端口组成Endpoint,表明着一个服务进程对外通讯的地址 - containerPort: 8080 env: #此处若是在未安装域名解析的状况下,会没法将mysql对应的IP解析到env环境变量中,所以先注释掉! # - name: MYSQL_SERVICE_HOST # value: 'mysql' - name: MYSQL_SERVICE_PORT value: '3306'
kubectl create -f myweb-rc.yaml
kubectl get rc
kubectl get pods
myweb-svc.yaml
apiVersion: v1 kind: Service metadata: name: myweb spec: type: NodePort ports: - port: 8080 nodePort: 30001 selector: app: myweb
kubectl create -f myweb-svc.yaml
kubectl get services
浏览器中输入http://虚拟机IP:30001/demo便可呈现以下内容:
tomcat-deployment.yaml
#与RC不一样之处,版本配置不一样 apiVersion: extensions/v1beta1 #与RC不一样之处,Kind不一样 kind: Deployment metadata: name: frontend spec: replicas: 1 selector: matchLabels: tier: frontend matchExpressions: - {key: tier, operator: In, values: [frontend]} template: metadata: labels: app: app-demo tier: frontend spec: containers: - name: tomcat-demo image: tomcat # 设置资源限额,CPU一般以千分之一的CPU配额为最小单位,用m来表示。一般一个容器的CPU配额被定义为100~300m,即占用0.1~0.3个CPU; resources: requests: memory: "64Mi" cpu: "250m" limits: memory: "128Mi" cpu: "500m" imagePullPolicy: IfNotPresent ports: - containerPort: 8080
kubectl create -f tomcat-deployment.yaml
kubectl get deployments
- DESIRED,Pod副本数量的指望值,及Deployment里定义的Replica;
- CURRENT,当前Replica实际值;
- UP-TO-DATE,最新版本的Pod的副本数量,用于指示在滚动升级的过程当中,有多少个Pod副本已经成功升级;
- AVAILABLE,当前集群中可用的Pod的副本数量;
kubectl get rs
看一下这里的名称与Deployment里面名称的关系;
kubectl get pods
看一下这里Pod的命名以Deployment对应的Replica Set的名字为前缀;
kubectl describe deployments
php-apache.yaml
apiVersion: autoscaling/v1 kind: HorizontalPodAutoscaler metadata: name: php-apache namespace: default spec: maxReplicas: 10 minReplicas: 1 scaleTargetRef: kind: Deployment name: php-apache targetCPUUtilizationPercentage: 90
这个HPA控制的目标对象为一个名叫php-apache的Deployment里的Pod副本,当这些Pod副本的CPUUtilizationPercentage超过90%时会触发自动扩容行为,扩容或缩容时必须知足的一个约束条件是Pod的副本数要介于1与10之间;
kubectl autoscale deployment php-apache –cpu-percent=90 –min=1 –max=10
tomcat-service.yaml
apiVersion: v1 kind: Service metadata: name: tomcat-service spec: # 服务若是想被外部调用,必须配置type type: NodePort ports: - port: 8080 name: service-port # 服务若是想被外部调用,必须配置nodePort nodePort: 31002 - port: 8005 name: shutdown-port selector: tier: frontend
上述内容定义了一个名为“tomcat-service”的Servcie,它的服务端口为8080,拥有“tier=frontend”这个Label的全部Pod实例都属于它;
这里的NodePort没有彻底解决外部访问Service的全部问题,好比负载均衡,假如咱们又10个Node,则此时最好有一个负载均衡器,外部的请求只需访问此负载均衡器的IP地址,由负载局衡器负责转发流量到后面某个Node的NodePort上。这个负载均衡器能够是硬件,也能够是软件方式,例如HAProxy或者Nginx;
若是咱们的集群运行在谷歌的GCE公有云上,那么只要咱们把Service的type=NodePort改成type=LoadBalancer,此时Kubernetes会自动建立一个对应的LoadBalancer实例并返回它的IP地址供外部客户端使用。其它公有云提供商只要实现了支持此特性的驱动,则也能够达到上述目的;
kubectl create -f tomcat-service.yaml
kubectl get endpoints
kubectl get svc tomcat-service -o yaml
apiVersion: v1 kind: Service metadata: creationTimestamp: 2017-04-21T15:47:43Z name: tomcat-service namespace: default resourceVersion: "227916" selfLink: /api/v1/namespaces/default/services/tomcat-service uid: dbf15b30-26a9-11e7-b185-080027d589d3 spec: # Kubernetes集群内部的地址,没法在集群外部使用这个地址 clusterIP: 10.254.2.210 ports: # 服务的虚端口 - port: 8080 protocol: TCP # 肯定提供该服务的容器所暴露的端口号,默认与port相同 targetPort: 8080 selector: tier: frontend sessionAffinity: None type: ClusterIP status: loadBalancer: {}
docker images
docker rmi 镜像ID
docker ps
docker exec -it 容器ID sh
docker logs 容器ID
docker rm -f 容器ID
kubectl apply -f XXX.yaml
kubectl delete -f XXX.yaml kubectl create -f XXX.yaml
kubectl get nodes
kubectl describe node 节点名
kubectl scale rc XXX --replicas=3
kubectl describe rc 标签名或者选择器名
kubectl replace -f rc.yaml 或 kubect edit replicationcontroller replicationcontroller名
kubectl rolling-update replicationcontroller名 --image=镜像名
kubectl rolling-update replicationcontroller名 -f XXX.yaml