kubernetes基本概念和术语
2021-03-27 01:26
标签：stat EAP self back idp 用户 主机 理解 前端 在Kubernetes中，几乎所有的概念，包括Master、Node、Pod、Label、Namespace、Volume等都可以看作是一种“资源对象”。 Master是Kubernetes集群的控制节点，每个kubernetes集群至少有一个Master节点， 在Kubernetes集群中，除了master节点之外就是Node节点，当然Etcd集群除外。 查看某一个Node的详细信息 RC是kubernetes的核心概念之一，它定义了一个期望的场景。 下面是一个定义RC的简单示例： 当我们定义了一个RC并提交到系统之后，Master节点的Controller-Manager就会得到通知，并定期巡检目标Pod的数量， Deployment是kubernetes1.2版本中为了更好的解决Pod的编排问题而引入的概念。 创建deployment： 查看deployment： 关于名词解释： 虽然告诉你了期望值、当前值和已经可用的值以及运行时间，但是并没有解决服务在滚动升级过程的推进过程。 deployment内部是调用Replica Set来实现的，因此也会自动创建： 查看已经创建的Pod： 创建了一个Pod。 查看容器： 每个pod都会创建一个Pause容器用于共享网络和存储卷。 Pod是Kubernetes的核心概念之一，Pod是kubernetes的最小管理单元。 简单示例： 创建pod： 查看Pod： 通过查看Pod的详细信息，可以了解该Pod的所有Event，包括其整个生命周期中所进行的操作。 Kubernetes中的所有资源对象都可以采用yaml或者JSON格式的文件来进行定义和描述。 Label同样是Kubernetes中非常核心的一个概念。Label是以键值对的形式进行定义的。 RS的定义方式： Label Selector在Kubernetes中重要使用场景有以下几处： 通过kubectl scale或者kubectl apply或者kubectl edit就可以实现来对pod扩容和缩容。 应用程序自定义的度量指标，比如服务在每秒内的相关请求数（TPS或QPS）。 在kubernetes中，Pod的管理对象RC、Deployment、DaemonSet和Job都是面向无状态的服务， Service也是Kubernetes里面最核心的概念之一，Kubernetes里的每个Service其实就是微服务架构中的一个微服务。 Service定义了一个服务的访问入口地址，前端Pod通过这个入口访问Service下面的一组Pod集群实例， 下面是Kubernetes所提供的微服务网格架构： 通过分析、识别并建模系统中的所有服务为微服务，最终我们的系统由多个提供不同业务能力而又彼此独立的微服务单元所组成。 创建Service： 端口已经被暴漏出来了，而且还分配了一个ClusterIP： 查看该Service的详细信息： targetport属性用来确定提供该服务的容器所暴露的端口号，而port则定义了Service的虚拟端口号， 在Kubernetes中，每个Service都有一个唯一的Cluster IP和唯一的名字，名字是用户自己定义的。 在Kubernetes中，最常见到的IP有三种： 我们创建了一个叫做frontend的deployment： 创建了一个pod，这里是随机命名： 然后启动了一个叫做tomcat-demo的容器： frontend这个deployment负责保证pod保持在期望的状态。 现在我们又创建了一个service对象： Nodeport为tomcat-service启动了31002这个外部的监听端口，自然而然的将其访问引入到了容器内部。 Kubernetes中的Volume与容器中的Volume在概念和用途上面比较类似，但是还是有差异之处。 Volume的使用比较简单，只需要在Pod中定义，然后在容器中进行引用就可以了。 emptyDir类型的volume是Pod分配到Node时创建的。 hostPath为在Pod上挂载宿主机上的文件文件或者目录，常用于日志文件存储或者直接访问docker的文件系统 使用谷歌公有云提供的永久磁盘（PD）存放Volume数据，PD上的内容会被永久保存，当Pod被删除时，PD只是被卸载，但不会被删除。 与.gcePersistentDisk类似使用亚马逊提供的永久存储保存数据 使用NFS网络文件系统提供的共享目录存储数据，需要在系统中部署一个NFS Server。 还有iscsi、flocker、glusterfs、rbd、gitRepo、secret Volume是定义在Pod上的，属于“计算资源”的一部分。 PV常见的accessModes类型： 如果某个Pod想申请某种类型的PV，则首先需要定义一个PersistentVolumeClaim（PVC）对象： 然后在Pod的volumes中引用上述PVC即可： PVC是针对于Pod来准备的，因为PV能够被很多的对象使用，只有pod在使用的时候才需要先定义PVC。 Namespace是Kubernetes系统中非常重要的核心概念， 集群启动之后，会创建一个名为“default”的Namespace，如果没有指定Namespace，那么创建的资源自将自动归属到default下面。 Annotation与Label类似，也使用key/value键值对的形式进行定义。 kubernetes基本概念和术语 标签：stat EAP self back idp 用户 主机 理解 前端 原文地址：https://www.cnblogs.com/yangmingxianshen/p/12635690.html
从这个角度上来说，Kubernetes是一个高度自动化的资源控制系统，它通过对比etcd中保存的“资源期望状态”和当前环境的“资源实际状态”，
以此来实现自动控制和自动纠错的功能。1.Master
它负责整个集群的控制和管理，几乎所有的kubectl的命令都是同时Master节点来执行的。
Master节点也可以参与实际任务的执行，但是并不建议这样做，因为master节点必须保证高可用，
一旦master节点宕机，那么整个集群都会处于停滞状态。生产环境建议使用3台独立的服务器作为Master节点。
Master节点的主要组件包括：APIServer、Controller-Manager、Scheduler，还有kubelet、kubectl、etcd等组件。
这些组件会以进程的形式展开。
APIServer：整个集群的唯一入口，也是连接etcd的唯一入口，所有对资源对象进行的操作都必须通过这个组件来展开。
所有组件的操作也必须通过APIServer这个组件来实现。
Controller-Manager：所有资源对象的自动化控制中心，比如自动启动和删除容器来维护容器的数量。
Scheduler：负责资源调度，也就是将Pod分配到具体的Node上。2.Node
Node节点是Kubernetes的工作负载节点，每个Node节点都会被Master分配一些工作任务，
当Node节点宕机的时候其上的工作任务会被转移到其它节点上去。
Node节点可以在运行期间动态的加入到Kubernetes集群中。
在默认情况下，Node节点上的kubelet组件会自动注册到master节点，
一旦被纳入到集群的范围，Kubelet就会定期向master节点汇报自身的情况。比如CPU内存的使用情况。
如果master在一定时间之内没有收到Node节点的报备信息，Node节点就会被标记为不可用，
随后master节点就会进行“工作负载转移”的自动化流程。root@VM-16-6-ubuntu:~/test# kubectl get nodes
NAME STATUS ROLES AGE VERSION
vm-0-3-ubuntu Ready
root@VM-16-6-ubuntu:~# kubectl describe node/vm-0-3-ubuntu
Name: vm-0-3-ubuntu #主机名称
Roles:
3.Replication Controller
即声明某种pod的数量在任意时刻都符合某个预期值。RC的定义至少包括以下几个部分：
Pod的数量，即replicas
用于删选pod的Label Selector，即selector
用于生成pod的模板，即templateapiVersion: v1
kind: ReplicationController #资源对象的类型
metadata: #rc的元数据
name: mysql
spec: #rc的相关属性定义
replicas: 1 #pod数量
selector:
app: mysql #给pod定义标签
template: #根据此模板创建pod
metadata:
labels:
app: mysql #pod的标签，对应于selector的标签
spec: #pod的相关属性
containers: #容器的相关属性定义，属性值是一个数组
- name: mysql #容器名
image: mysql #使用的镜像名称
ports:
- containerPort: 3306 #端口号，可能会有多个端口，使用数组作为值
env:
- name: MYSQL_ROOT_PASSWORD
value: "123456"
如果目标数量不等于期望值，那么就会执行相应的增加或删除操作，这就实现了应用集群的高可用性。
通过kubectl scale和kubectl apply可以修改pod的副本数量。
当我们需要更新一个服务的时候，可以使用滚动升级，就是当前容器逐个停止，新的服务容器逐个启动，不改变pod的副本数量。
在1.2版本之后，Replica Set和Deployment这个两个资源对象逐渐取代了RC。
Replica Set是RC的升级版，基本上可以替代RC，只是功能更加强大，
比如支持基于集合的Label Selector，RC只支持等式的Selector。
Replica Set主要被Deployment这个更高层次的对象所使用，从而形成一整套Pod创建、删除、更新的编排机制。
当我们使用deployment的时候，无需关心和维护Replica Set。
Replica Set和deployment实现了自动扩容和伸缩的功能。4.Deployment
Deployment内部是使用Replica Set来实现的，之前说过Replica Set是对RC的一次升级，唯一的区别是支持基于集合的Select Label。
Deployment与RC的相似度非常高，最大的升级是随时知道当前Pod部署的进度。
一个Pod的创建、调度、绑定节点及在目标Node上启动对应的容器这一过程需要一定的时间。
Deployment和Replica Set以及RC的定义非常类似。下面是一个简单的示例：apiVersion: extensions/v1beta1
kind: Deployment #资源对象的类型
metadata:
name: frontend #这个对象的名称，通过kubectl get deployment可以获取
spec: #deployment与RC一样，至少由replicas、selector、template组成
replicas: 1
selector: #deployment使用Replica Set，因此支持基于集合的Selector Label
matchLabels:
tier: frontend
matchExpressions:
- {key: tier, operator: In, values: [frontend]}
template:
metadata:
labels:
app: app-demo
tier: frontend #这个需要与Selector对应
spec:
containers: #容器的一些属性定义
- name: tomcat-demo
image: tomcat
imagePullPolicy: IfNotPresent
ports:
- containerPort: 8080
[root@VM_16_6_centos chapter01]# kubectl create -f tomcat-deployment.yaml
deployment "frontend" created
[root@VM_16_6_centos chapter01]# kubectl get deployment
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
frontend 1 1 1 1 5s
DESIRED：Pod的期望数量
CURRENT：Pod的当前数量，Pod的数量会逐步等于DESIRED的值。
UP-TO-DATE：最新版本的Pod数量，在版本升级中，已经进行升级了的Pod数量
AVAILABLE：当前集群中可用的Pod的数量。
如果你感觉Deployment与RC并没有什么区别，那么可以查看以下RC。[root@VM_16_6_centos chapter01]# kubectl get rc
NAME DESIRED CURRENT READY AGE
mysql 3 3 3 9h
这就是deployment与RC最大的不同之处。[root@VM_16_6_centos chapter01]# kubectl get rs
NAME DESIRED CURRENT READY AGE
frontend-141477217
[root@VM_16_6_centos chapter01]# kubectl get pods|grep frontend
frontend-141477217-94ltm 1/1 Running 0 6m
[root@VM_16_6_centos chapter01]# docker ps|grep front
0f2f83d4b8d9 tomcat "catalina.sh run" 9 minutes ago Up 9 minutes k8s_tomcat-demo.b9a602ba_frontend-141477217-94ltm_default_2d3f9e82-9cc0-11e9-a763-52540095a842_eb119b9f
160304a783ba registry.access.redhat.com/rhel7/pod-infrastructure:latest "/pod" 9 minutes ago Up 9 minutes k8s_POD.24f70ba9_frontend-141477217-94ltm_default_2d3f9e82-9cc0-11e9-a763-52540095a842_506a66db
5.pod
每个Pod在创建的时候默认都会创建一个pause容器，这个容器用来共享网络和文件。
除了pause容器之外，每个Pod还包含一个或多个紧密相关的业务容器。
需要注意的是Pod存储的并不是一个或多个相同的容器，而是业务紧密相关的一组容器。
这样Pause容器就非常好的解决了一个pod内多个容器之间的通信和文件共享的问题。
如果是Pod存储的是相同类型的容器，这些容器之间是不需要进行通信，更多的是和外部的通信。
Kubernetes会为每一个Pod分配一个IP。Pod中所有的容器共享这一个IP。
Kubernetes在设计之初，就要求不同Node上的容器能够直接进行通信，kubernetes的网络方案有非常多种，之后会有说明。
Kubernetes中Pod一般分为普通Pod和静态Pod（static pod）.
静态Pod使用来为了维护集群而创建，比如你修改了集群的配置文件，静态pod会进行定期检查，这样就会自动更新配置。
静态Pod并不会存储在etcd中，而是存放在某个Node的一个文件中，并且只在此Node上启动运行。
普通Node一旦创建之后就会被存储到etcd中，然后被scheduler调度到某个具体的Node上进行绑定，
然后该Node上的kubelet组件就会进行容器的创建工作。apiVersion: v1
kind: Pod
metadata:
name: myweb
labels:
name: myweb
spec:
containers:
- name: myweb1
image: kubeguide/tomcat-app:v1
ports:
- containerPort: 8010
env:
- name: MYSQL_SERVICE_HOST
value: ‘mysql‘
- name: MYSQL_SERVICE_PORT
value: ‘3307‘
[root@VM_16_6_centos chapter01]# kubectl create -f myweb-pod.yaml
pod "myweb" created
[root@VM_16_6_centos chapter01]# kubectl get pods|grep myweb
myweb 1/1 Running 0 4m
从下面的Event中我们可以看出，经历了pull、create和start这个三个过程。
当然还可以查看到一些容器的详细信息。[root@VM_16_6_centos chapter01]# kubectl describe pods/myweb
Name: myweb
Namespace: default
Node: 127.0.0.1/127.0.0.1
Start Time: Tue, 02 Jul 2019 20:43:33 +0800
Labels: name=myweb
Status: Running
IP: 172.17.0.6
Controllers:
当然在Pod里面还可以进行资源配额的限制。6.Label
Label可以附加到各种资源对象上，比如Node、Service、Pod、RC等。
一个资源对象可以绑定任意多个Label，一个Label也可以绑定到任意个资源对象上去。
Label通常在资源对象定义时确定，也可以在资源对象创建之后动态添加或者删除。
我们可以给指定的资源对象绑定一个或者多个不同的Label来实现多维度的资源分组。
Label对象之所非常重要，这是因为Label是不同资源对象之间进行关联、查询和筛选的方式。
之前说过RC只支持基于等式的筛选，而RS支持基于集合形式的筛选。
RC的定义方式：replicas: 1
selector:
app: mysql
template:
metadata:
labels:
app: mysql
selector:
mathLabels:
app: myweb
matchExpressions:
- {key: tier, operator: In, values: [frontend]}
- {key: environment, operator: NotIn, Value: [dev]}
kube-controller进程通过资源对象RC上定义的Selector Label来查找pod，然后与replicas的数量对比，以此维护期望值。
kube-proxy通过Service的Selector Label来选择对应的Pod，自动建立起每个Service到对应Pod的请求转发路由表，实现自动负载均衡的功能。7.Horizontal Pod Autoscaler
但是这种手动操作的方式显然并不是很多人所期待的。
更多人希望系统能够根据当前负载的变化情况自动触发水平扩展或缩容的行为，希望这个过程完全是自动化、智能化的。
Kubernetes在1.1版本中首次发布了Horizontal Pod Autoscaling（Pod横向自动扩容，简称HPA）。
在1.2版本中HPA被升级为稳定版本（apiVersion:autoscaling/v1），但是依然保留了旧版本（apiVersion:extensions/v1betal）。
从1.6版本开始，对根据应用自定义指标进行自动扩容和缩容的功能进行增强，API版本为autoscaling/v2alphal。
每一个yaml或者json文件都会指定apiVersion，其实这是指定调用那个APIService的接口来处理这个任务。
因为可能对于同一种该资源类型可能会有不同的处理方式。
HPA与之前的RC、Deployment一样也属于一种kubernetes资源对象。
通过追踪分析RC控制的所有目标Pod的负载变化情况，来确定是否需要针对性的调整目标pod的副本数，这是HPA的实现的原理。
HPA可以有以下两种方式来衡量Pod负载的度量指标：
CPUUtilizationPercentage
CPUUtilizationPercentage是一个算术平均值，即目标Pod所有副本自身的CPU利用率的平均值。
一个Pod自身的CPU利用率是该Pod当前CPU的使用量除以它的Pod Request的值。
比如某个时刻CPUUtilizationPercentage的值超过了预设值，则意味着当前的Pod的数量不足以支撑接下来的请求，此时则需要进行动态扩容。
当请求高峰时段过去后，Pod的CPU利用率又会降下来，此时对应的Pod副本数又会自动降低到一个合理的水平。
CPUUtilizationPercentage计算过程中使用到的Pod的CPU使用通常是1min内的平均值。目前通过查询Heapster扩展组件来得到这个值。
如果你没有定义Pod的Request的值，则无法使用CPUUtilizationPercentage来实现横向自动扩容的能力。
下面是一个HPA的简单示例：apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
name: php-apache
namespace: default
spec:
maxReplicas: 10 #扩容或缩容Pod数量的约束
minReplicas: 1
scaleTargetRef:
kind: Deployment
name: php-apache
targetCPUUtilizationPercentage: 90 #当CPU的占用率超过90%的时候自动触发扩容行为
8.StatefulSet
因为Pod是非持久性的，随时可能被删除，是无法长期存储有状态服务的数据的。
在现实业务中，最常用到的有状态的服务是数据库类的服务，比如MySQL集群、MongoDB集群。
这些应用集群有一些共同点：
每个节点都有固定的ID，通过这个ID，集群中的成员可以相互发现并通信。
集群的规模比较固定，集群的规模不能随意变动。
集群的每个节点都有状态，通常会将持久化的数据永久存储。
如果某个节点无法正常访问，那么集群的功能将会受到一定的影响。
如果你使用RC/Deployment来控制Pod，那么Pod的名字是随机产生的，IP也不是固定的，
这样你根本无法给每一个Pod分配一个固定的IP。
Kubernetes为了兼顾这种有状态的服务，在1.4版本中引入了PetSet这个新的资源对象。
在1.5版本中将其变更为StatefulSet，StatefulSet从本质上来说是RC/Deployment的一个变种，只是改变了一些特性：
StatefulSet控制的每个Pod都有稳定、唯一的网络标识，可以用来发现集群内的其它成员。
StatefulSet控制的Pod的启动顺序是受控制的。
StatefulSet里的Pod采用稳定的持久化存储卷，通过PV/PVC来实现，删除pod时默认不会删除与StatefulSet相关的存储卷（保证数据安全）
StatefulSet除了要与PV卷捆绑使用以存储Pod的状态数据，还要与Headless Service配合使用，
即在每个StatefulSet的定义中要声明它属于哪一个Headless Service。
Headless Service与普通Service的区别在于它没有Cluster IP，
如果解析Headless Service的DNS域名，则返回的是该Service对应的全部Pod的Endpoint列表。
StatefulSet在Headless Service的基础上又为StatefulSet控制的每个Pod实例创建了一个DNS域名。9.Service
（1）概论
之前我们所说的RC、Deployment、Pod其实都是为Service来服务的。
下面是对Pod、RC和Service的关系说明图：
Service与Pod集群之间通过Label Selector来实现关联。
RC用来保证Service的服务能力和服务质量永远保持在预期的标准。
服务之间通过TCP/IP进行通信，从而形成了我们强大而又灵活的服务网格，拥有了强大的分布式能力、弹性扩展能力、容错能力。
每个Pod都会被分配一个单独的IP，与container的Port来组成Endpoint来被客户端访问。
多个Pod组成一个集群，那么客户端是如何来进行访问的了？一般是通过负载均衡来进行转发。
在Kubernetes中，每个Node上都有一个kube-proxy组件来实现自动的负载均衡，
kube-proxy负责将对Service的请求转发到后端的某个Pod实例上，并在内部实现服务的负载均衡和会话保持机制。
在Kubernetes中，Service不是共用一个负载均衡器的IP地址，而是每个Service分配一个全局唯一的虚拟IP地址。
这个IP被称为Cluster IP，这样每个服务就变成了具备唯一IP地址的“通信节点”，服务的调用就变成了最基础的TCP网络通信问题。
Pod的EndPoint会随着Pod的销毁和重建而发生改变，因为Pod的IP地址会在这个过程中发生改变。
而Service一旦被创建之后，就会被分配一个唯一的Cluster IP，在整个Service的生命周期内，Cluster IP都不会发生改变。
许多时候，我们可以直接将Service暴漏出去，这样访问Service的名称就可以访问到对应的服务。
下面是一个Service创建的简单实例：apiVersion: v1
kind: Service #定义资源对象的类型
metadata:
name: tomcat-service #该service的名称
spec:
ports:
- port: 8091 #对外的服务端口号
selector:
tier: frontend #通过这个Lable筛选Pod
[root@VM_16_6_centos chapter01]# kubectl create -f tomcat-service.yaml
service "tomcat-service" created
[root@VM_16_6_centos chapter01]# kubectl get service
NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes 10.254.0.1
[root@VM_16_6_centos chapter01]# kubectl get svc tomcat-service -o yaml
apiVersion: v1
kind: Service
metadata:
creationTimestamp: 2019-07-03T11:41:44Z
name: tomcat-service
namespace: default
resourceVersion: "633043"
selfLink: /api/v1/namespaces/default/services/tomcat-service
uid: 887daf77-9d87-11e9-895d-52540095a842
spec:
clusterIP: 10.254.165.154
ports:
- port: 8091
protocol: TCP
targetPort: 8091
selector:
tier: frontend
sessionAffinity: None
type: ClusterIP
status:
loadBalancer: {}
如果没有定义targetPort，则默认targetPort与Port相同。（2）Kuberbetes的服务发现机制
在实际中，我们不可能通过IP来定位Service对象，更多的是通过name，那么Service 的Cluster IP与name是如何关联和定义的了？
早期的时候，kubernetes通在每个Pod启动的时候，自动注入环境变量，通过访问变量就可以找到对应的Cluster IP。
后来Kubernetes通过Add-On增值包的方式引入DNS系统，将服务名作为DNS的域名，这样就可以通过服务名来建立通信了。（3）外部系统访问Service的问题
Node IP:Node节点的IP，这是一个真实存在的物理IP，通过这个IP就可以直接访问到Node这个服务器。
Pod IP：Pod的IP地址，每个Pod的IP其实是Pause容器的IP，这个一个容器IP，
这是容器在创建的过程中，docker0虚拟网桥随机分配的一个IP。这个IP是可以被访问的，可以ping通，可以看作是一个虚拟IP。
Cluster IP：Service的IP，更像一个“虚假”的IP，虚拟IP至少还能够使用，而Cluster IP不能直接使用。
Cluster IP仅仅作用于Service这个对象，由Kubernetes管理和分配。
Cluster IP只能结合Service Port组成一个具体的通信端口，单独的Cluster IP不具备通信的能力，
并且Kubernetes属于集群内的封闭空间，集群之外的节点如果要访问这个通信端口，则需要进行额外的操作。
Cluster IP属于集群内部的地址，无法在集群外部直接使用这个地址。
在微服务中，外部或内部应用会直接访问Service的服务，那么客户该如何来进行访问了？
采用NodePort是解决上述问题的最直接、最有效、最常用的做法。
NodePort的实现方式是在Kubernetes集群里的每个Node上为需要外部访问的Service开启一个对应的TCP监听端口。
我们可以通过一个完整的例子来展示：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
[root@VM_16_6_centos chapter01]# kubectl get deployment
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
frontend 1 1 1 1 18m
[root@VM_16_6_centos chapter01]# kubectl get pod
NAME READY STATUS RESTARTS AGE
frontend-141477217-pm1m9 1/1 Running 0 19m
[root@VM_16_6_centos chapter01]# docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
bbce24a9ea39 tomcat "catalina.sh run" 19 minutes ago Up 19 minutes k8s_tomcat-demo.b9a602ba_frontend-141477217-pm1m9_default_1308260d-9d91-11e9-895d-52540095a842_b0445ecc
e2b768eea56c registry.access.redhat.com/rhel7/pod-infrastructure:latest "/pod" 19 minutes ago Up 19 minutes k8s_POD.24f70ba9_frontend-141477217-pm1m9_default_1308260d-9d91-11e9-895d-52540095a842_8687e42c
apiVersion: v1
kind: Service
metadata:
name: tomcat-service
spec:
type: NodePort
ports:
- port: 8080
nodePort: 31002
selector:
tier: frontend
[root@VM_16_6_centos chapter01]# kubectl get svc
NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes 10.254.0.1
之后我们就可以访问这个Tomcat服务了。10.Volume
Kubernetes中的Volume被定义在Pod上，然后被pod中的一个或者多个容器挂载到相应的目录下面。
Volume的生命周期与Pod的生命周期相同，与容器的生命周期无关。
下面是volume的简单实例：apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: deployment-example
spec:
volumes: #在pod中定义了一个volumes
- name: detavol #name和emptyDir都是定义的该volume的属性
emptyDir: {}
replicas: 2
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.10
volumeMounts: #将volumes挂载到容器中
- mountPath: /mydata-data #挂载到那个目录
name: detavol #挂载哪一个volume
Pod中的多个容器通过共享一个volume，就是实现容器间文件共享的问题，
这样就可以将容器中数据保存到一个目录，最后实现永久性存储。
不仅如此，通过Volume还可以实现容器配置文件集中化配置和管理，这个功能通过ConfigMap来进行实现。
Volume常见类型：（1）emptyDir
它的初始内容空，并且无须指定宿主机上对应的文件，当Pod从Node上移除时，emptyDir中的数据会永久被删除。（2）hostPath
（3）gcePersistentDisk
（4）awsElasticBlockStore
volumes:
- name: test-volume
awsElasticBlockStore:
volumeID: aws:///
（5）NFS
volumes:
- name: nfs
nfs:
#改为你的NFS服务器地址，该volume绑定在某一个Pod上面，作用对象是该Pod上的一个或多个容器
server: nfs-server.localhost
path: “/”
（6）其它类型的Volume
11.Persistent Volume
实际上，“网络存储”是相对于“计算资源”而存在的一种实体资源。
PV可以理解成Kubernetes集群中的某个网络存储中对应的一块存储，它与Volume类似，但又有所区别：
PV只能是网络存储，不属于任何Node，但可以在每个Node上访问。
PV并不是定义在Pod上，而是独立于Pod之外定义
PV的作用对象是Node，当然就可以作用Pod。
下面是一个NFS类型PV的一个yaml定义文件，声明了需要5Gi的存储空间:apiVersion: v1
kind: PersistentVolume
metadata:
name: pv0003 #PV的名称属性
spec:
capacity: #PV的需求
storage: 5Gi
accessModes: #模式
- ReadWriteOnce
nfs: #nfs的路径和地址
path: /somepath
server: 172.17.0.2
ReadWriteOnce：读写权限，只能被单个Node挂载
ReadOnlyMany：只读权限，允许被多个Node挂载
ReadWriteMany：读写权限，允许被多个Node挂载apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: myclaim
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 8Gi
volumes：
- name: mypd
persistenVolumeClaim:
claimName: myclaim
volume是在Pod内应用，而PV是外部的网络存储资源。
PV有以下几种状态：
Available：空闲状态
Bound：已经绑定到某个PVC上
Released：对应的PVC已经删除，但资源还没有被集群回收
File：PV自动回收失败12.Namespace
Namespace在很多情况下用于实现多用户的资源隔离。
Namespace通过将集群内部的资源对象“分配”到不同namespace中，形成逻辑上分组的不同项目、小组或用户组，
便于不同的分组在共享使用整个集群的资源的同时还能被分别管理。[root@VM_16_6_centos ~]# kubectl get namespaces
NAME STATUS AGE
default Active 7d
kube-system Active 7d
13.Annotation
不同的是Label具有严格的命名规范，它定义的是Kubernetes对象的元数据（Metadata），并且用于Label Selector。
而Annotation则是用户任意定义的“附加”信息，以便于外部工具进行查找，
很多时候，Kubernetes的模块自身会通过Annotation的方式标记资源对象的一些特殊信息。