kubernetes相关概念

kubernetes相关概念

 

 

 

 

kubernetes内部组件工做原理 http://dockone.io/article/5108

从物理层面来划分的话，kubernetes分两个角色，master节点和node节点：

Master

Master是整个集群的控制中心，kubernetes的全部控制指令都是发给master，它负责具体的执行过程。通常咱们会把master独立于一台物理机或者一台虚拟机，它的重要性不言而喻。

master上有这些关键的进程：

Kubernetes API Server（kube-apiserver)，提供了HTTP Rest接口关键服务进程，是全部资源增、删、改、查等操做的惟一入口，也是集群控制的入口进程。 #也就是说咱们想要增长或减小pod，配置一些服务（service）等等。都是要经过这个API总入口进入

Kubernetes Controller Manager(kube-controlker-manager)，是全部资源对象的自动化控制中心，能够理解为资源对象的大总管。

Kubernetes Scheduler(kube-scheduler)，负责资源调度（pod调度）的进程，至关于公交公司的“调度室”。 #主要针对pod，好比node在一节点仍是二节点，就是由他来调度

etcd Server，kubernetes里全部资源对象的数据都是存储在etcd中的。 #好比rc、service（svc）、pod这些资源对象全都存到了etcd下面

Node

除了Master，Kubernetes集群中其余机器被称为Node，早期版本叫作Minion。Node能够是物理机也能够是虚拟机，每一个Node上会被分配一些工做负载（即，docker容器），当Node宕机后，其上面跑的应用会被转移到其余Node上。

Node上有这些关键进程：

kubelet：负责Pod对应容器的建立、启停等任务，同时与Master节点密切协做，实现集群管理的基本功能。

kube-proxy：实现Kubernetes Service的通讯与负载均衡机制的重要组件。

Docker Engine（docker）：Docker引擎，负责本机容器的建立和管理。

kubectl get nodes #查看集群中有多少个node

kubectl describe node <node name> #查看Node的详细信息

Pod

查看pod命令： kubectl get pods #s能够省略。

查看容器命令： docker ps

能够看到容器和pod是有对应关系的，在咱们作过的实验中，每一个pod对应（至少）两个容器，一个是Pause容器，一个是rc里面定义的容器（实际上，每一个pod里能够有多个应用容器）。这个Pause容器叫作“根容器”，只有当Pause容器“死亡”才会认为该pod“死亡”。Pause容器的IP以及其挂载的Volume资源会共享给该pod下的其余容器。

pod定义示例： #跟上一章的rc差很少

apiVersion: v1

kind: pod #这个地方为pod

metadata:

name: myweb

labels:

name: myweb

spec:

containers:

- name: myweb

image: kubeguide/tomcat-app:v1

ports:

- containerPort: 8080

env:

- name: MYSQL_SERVICE_HOST

value: 'mysql'

- name: MYSQL_SERVICE_PORT

value: '3306'

每一个pod均可以对其能使用的服务器上的硬件资源进行限制（CPU、内存）。CPU限定的最小单位是1/1000（千分之一）个cpu，用m表示，

如100m，就是0.1个cpu。内存限定的最小单位是字节，能够用Mi（兆） 表示，如128Mi就是128M。

在kubernetes里，一个计算资源进行配额限定须要设定两个参数：

1）requests：该资源的最小申请量

2）Limits：该资源容许的最大使用量。

资源限定示例：

spec:

containers: #定义容器

- name: db

image: mysql

resources:

requests: #最小值

memory: "64Mi"

cpu: "250m"

limits: #最大值

memory: "128Mi"

cpu: "500m"

Label

Label是一个键值对（标签），其中键和值都由用户自定义，Label能够附加在各类资源对象上，如Node、Pod、Service、RC等。一个资源对象能够定义多个Label，同一个Label也能够被添加到任意数量的资源对象上。Label能够在定义对象时定义，也能够在对象建立完后动态添加或删除。

Label示例：

"release":"stable", "environment":"dev", "tier":"backend"等等。

为了实现service和pod之间的关联，又有了标签（label）的概念，咱们把功能相同的pod设定为同一个标签，好比，能够把全部提供mysql服务的pod贴上标签name＝mysql，这样mysql service要做用于全部包含name＝mysql标签的pod上。

RC

RC是kubernetes中核心概念之一，简单说它定义了一个指望的场景，即声明某种pod的副本数量在任意时刻都符合某个预期

值，RC定义了以下几个部分：

1）pod期待的副本数 #可定义多个

2）用于筛选目标pod的Label Selector

3）建立pod副本的模板（template）

RC一旦被提交到kubernetes集群后，Master节点上的Controller Manager组件就会接收到该通知，它会按期巡检集群中存活的pod，并确保pod数量符合RC的定义值。能够说经过RC，kubernetes实现了用户应用集群的高可用性，而且大大减小了管理员在传统IT环境中不得不作的诸多手工运维工做，好比编写主机监控脚本、应用监控脚本、故障恢复处理脚本等 #也就是说rc有一个机制，能够自动的监控pod的数量是否符合预期，若是其中一个pod宕机了，能够自动的启动一个新的pod起来，这样咱们不用去监控他，一切都是自动的

RC工做流程（假如，集群中有3个Node）：

1）RC定义2个pod副本

2）假设系统会在2个Node上（Node1和Node2）建立pod

3）若是Node2上的pod（pod2）意外终止，这颇有多是由于Node2宕机

4）则会建立一个新的pod，假设会在Node3上建立pod3，固然也有可能在Node1上建立pod3

RC中动态修改pod副本数量：

kubectl scale rc <rc name> --replicas=n #n为数量

利用动态修改pod的副本数，能够实现应用的动态升级（滚动升级）：

1）以新版本的镜像定义新的RC，但pod要和旧版本保持一致（由Label决定）

2）新版本每增长1个pod，旧版本就减小一个pod，始终保持固定的值

3）最终旧版本pod数为0，所有为新版本

删除RC：

kubectl delete rc <rc name>

删除RC后，RC对应的pod也会被删除掉

Deployment

在1.2版本引入的概念，目的是为了解决pod编排问题，在内部使用了Replica Set，它和RC比较，类似度为90%以上，能够认为是RC的升级版。 跟RC比较，最大的一个特色是能够知道pod部署的进度。 #后期能够逐渐的靠着Deployment去作，逐渐的把rc丢弃掉。目前仍是会有使用rc

Deployment示例：

apiVersion: extensions/v1beta1

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

imagePullPolicy: IfNotPresent

ports:

- containerPort: 8080

kubectl create -f tomcat-deployment.yaml

kubectl get deployment

HPA(Horizontail Pod Autoscaler) #暂时没涉及到，了解

在1.1版本，kubernetes官方发布了HPA，实现pod的动态扩容、缩容，它属于一种kubernetes的资源对象。它经过追踪分析

RC控制的全部目标pod的负载变化状况，来决定是否须要针对性地调整目标Pod的副本数，这是HPA的实现原理。

pod负载度量指标：

1）CpuUtilizationPercentage

目标pod全部副本自身的cpu利用率平用均值。一个pod自身的cpu利用率＝该pod当前cpu的使用量／pod Request值。若是某

一个时刻，CPUUtilizationPercentage的值超过了80%，则断定当前的pod已经不够支撑业务，须要增长pod。

2）应用程序自定义的度量指标，好比服务每秒内的请求数（TPS或QPS）

HPA示例：

apiVerion: autosacling/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副本，当cpu平均值超过90%时就会扩容，pod副本数控制范围是1－10.

除了以上的xml文件定义HPA外，也能够用命令行的方式来定义：

kubectl autoscale deployment php-apache --cpu-percent=90 --min=1 --max=10

Service

Service是kubernetes中最核心的资源对象之一，Service能够理解成是微服务架构中的一个“微服务”，pod、RC、

Deployment都是为Service提供嫁衣的。

简单讲一个service本质上是一组pod组成的一个集群，前面咱们说过service和pod之间是经过Label来串起来的，相同Service的pod的Label同样。同一个service下的全部pod是经过kube-proxy实现负载均衡，而每一个service都会分配一个全局惟一的虚拟ip，也叫作cluster ip（kubectl get svc)。在该service整个生命周期内，cluster ip是不会改变的，而在kubernetes中还有一个dns服务，它把service的name和cluster ip映射起来。（kubectl get svc出来的name和clusterip） #上一节讲在没有使用dns的时候，只能使用ip，用了dns以后，仓可使用<name>（web-rc.ymal的配置）

service示例:(文件名tomcat-service.yaml)

apiVersion: v1

kind: Service

metadata:

name: tomcat-service

spec:

ports:

- port: 8080

selector:

tier: frontend

kubectl create -f tomcat-service.yaml

kubectl get endpoints //查看pod的IP地址以及端口 #这个出来的ip，咱们基本上不去用它

kubectl get svc tomcat-service -o yaml //查看service分配的cluster ip #就是指定查看他的格式是yaml

多端口的service： #就是说这个service里面能够有多个服务（好比web服务80的，还有php的）

apiVersion: v1

kind: Service

metadata:

name: tomcat-service

spec:

ports:

- port: 8080 #好比tomcat的8080

name: service-port

- port: 8005 #以及tomcat的8005

name: shutdown-port

selector:

tier: frontend

对于cluster ip有以下限制：

1）Cluster ip没法被ping通，由于没有实体网络来响应 #可是能够telnet <ip> <port>ping同他的端口

2）Cluster ip和Service port组成了一个具体的通讯端口，单独的Cluster ip不具有TCP/IP通讯基础，它们属于一个封闭的空间。

3）在kubernetes集群中，Node ip、pod ip、cluster ip之间的通讯，采用的是kubernetes本身设计的一套编程方式的特殊路由规则。

要想直接和service通讯，须要一个Nodeport，在service的yaml文件中定义：

apiVersion: v1

kind: Service

metadata:

name: tomcat-service

spec:

ports:

- port: 8080

nodeport: 31002 #大于30000

selector:

tier: frontend

它实质上是把cluster ip的port映射到了node ip的nodeport上了

Volume(存储卷)

Volume是pod中可以被多个容器访问的共享目录，kubernetes中的volume和docker中的volume不同，主要有如下几个方面：

1）kubernetes的volume定义在pod上，而后被一个pod里的多个容器挂载到具体的目录下 #同一个pod里面的容易都是能够去分享同一个volume的

2）kubernetes的volume与pod生命周期相同，但与容器的生命周期不要紧，当容器终止或者重启时，volume中的数据并不会丢失

3）kubernetes支持多种类型的volume，如glusterfs，ceph等先进的分布式文件系统

如何定义并使用volume呢？只须要在定义pod的yaml配置文件中指定volume相关配置便可：

template:

metadata:

labels:

app: app-demo

tier: frontend

spec:

volumes:

- name: datavol

emptyDir: {}

containers:

- name: tomcat-demo

image: tomcat

volumeMounts:

- mountPath: /mydata-data

name: datavol

imagePullPolicy: IfNotPresent

说明: volume名字是datavol，类型是emptyDir，将volume挂载到容器的/mydata-data目录下

volume的类型：

1）emptyDir

是在pod分配到node时建立的，初始内容为空，不须要关心它将会在宿主机（node）上的哪一个目录下，由于这是kubernetes自动分配的一个目录，当pod从node上移除，emptyDir上的数据也会消失。因此，这种类型的volume不适合存储永久数据，适合存放临时文件。

2）hostPath

hostPath指定宿主机（node）上的目录路径，而后pod里的容器挂载该共享目录。这样有一个问题，若是是多个node，虽然目录同样，可是数据不能作到一致，因此这个类型适合一个node的状况。

配置示例：

volumes:

- name: "persistent-storage"

hostPath:

path: "/data"

3）gcePersistentDisk #离咱们比较远

使用Google公有云GCE提供的永久磁盘（PD）存储volume数据。毫无疑问，使用gcePersistentDisk的前提是kubernetes的

node是基于GCE的。

配置示例：

volumes:

- name: test-volume

gcePersistentDisk:

pdName: my-data-disk

fsType: ext4

4）awsElasticBlockStore #离咱们比较远

与GCE相似，该类型使用亚马逊公有云提供的EBS Volume存储数据，使用它的前提是Node必须是aws EC2。

5）NFS #这个离咱们比较近，后面会有演示

使用NFS做为volume载体。

示例：

volumes:

- name: "NFS"

NFS:

server: ip地址

path: "/"

6）其余类型

iscsi

flocker

glusterfs

rbd

gitRepo: 从git仓库clone一个git项目，以供pod使用

secret: 用于为pod提供加密的信息

persistent volume（PV）

PV能够理解成kubernetes集群中某个网络存储中对应的一块存储，它与volume相似，但有以下区别：

1）PV只能是网络存储，不属于任何Node，但能够在每一个Node上访问到

2）PV并非定义在pod上，而是独立于pod以外定义

3）PV目前只有几种类型：GCE Persistent Disk、NFS、RBD、iSCSCI、AWS ElasticBlockStore、GlusterFS

以下是NFS类型的PV定义：

apiVersion: v1

kind: PersistentVolume

metadata:

name: pv0003

spec:

capacity:

storage: 5Gi

accessModes:

- ReadWriteOnce

nfs:

path: /somepath

server: ip

其中accessModes是一个重要的属性，目前有如下类型：

ReadWriteOnce: 读写权限，而且只能被单个Node挂载

ReadOnlyMany: 只读权限，容许被多个Node挂载

ReadWriteMany：读写权限，容许被多个Node挂载 #最大权限

1.若是某个pod想申请某种条件的PV，首先须要定义一个PersistentVolumeClaim（PVC）对象：

kind: persistentVolumeClaim

apiVersion: v1

metadata:

name: myclaim

spec:

accessModes:

- ReadWriteOnce

resources:

requests:

storage: 8Gi

2.而后在pod的vomume定义中引用上面的PVC：

volumes:

- name: mypd

persistentVolumeClaim:

ClaimName: myclaim

Namespace（命名空间）

当kubernetes集群中存在多租户的状况下，就须要有一种机制实现每一个租户的资源隔离。而namespace的目的就是为了实现资源隔离。

kubectl get namespace //查看集群全部的namespace

1.定义namespace：

apiVersion: v1

kind: Namespace

metadata:

name: dev

kubectl create -f dev-namespace.yaml //建立dev namespace

2.而后再定义pod，指定namespace

apiVersion: v1

kind: Pod

metadata:

name: busybox

namespace: dev

spec:

containers:

- image: busybox

command:

- sleep

- "500"

name: busybox

查看某个namespace下的pod：

kubectl get pod --namespace=dev

etcd

etcd是用来存储kubernetes里的集群文件的（存配置文件配置的数据库）

 

 

总结：

master（控制中心）：从物理层次去划分两个角色（master和node）。他包括四个服务或进程

node（真正工做的节点）：上面有docker、pod。由kubelet来管理。kube-porxy来提供总入口访问他，实现负载均衡

pod（就是咱们的容器，上面的那一层）：pod里面有一个pose容器，提供网络和数据共享的一个容器

label（标签）：经过label把pod和service关联在一块儿

rc：用来描述或定义pod的一个场景，用rc来定义

Deployment：是rc的升级版。他的特色是能够知道pod部署的进度

HPA:是一个实现动态扩容缩容的一种资源对象

service：最终提供给用户服务的。一个cluster IP，一个name，就能够拿他去作事情了

volume：存储卷

pv：vollume之上就是pv。咱们有了pv以后，才能够把这么多的pod数据落地。好比跑一个网站，那这个网站的数据存到哪里去？数据库数据存到哪里去？最终要存到一个地方去，用pv来定义。有了pc还要建立一个pvc，pvc是要被pod引用的。pvc能够自动的去关联pv，只有pv是不行的

namespace（命名空间）：多租户的时候，须要有一个隔离的机制