云原生-k8s核心概念（pod，deploy，service，ingress，configmap，volume）

Gitee-k8s学习
云原生实战-kubernetes核心实战

namespace

Namespace是kubernetes系统中的一种非常重要资源，它的主要作用是用来实现多套环境的资源隔离或者多租户的资源隔离

Pod

Pod可以认为是容器的封装，一个Pod中可以存在一个或者多个容器。

Deployment

kubernetes很少直接控制Pod，一般都是通过Pod控制器来完成的。Pod控制器用于pod的管理，确保pod资源符合预期的状态，当pod的资源出现故障时，会尝试进行重启或重建pod。

deployment：pod控制器，控制一组标签相同的pod，使Pod拥有多副本，自愈，扩缩容，滚动更新，版本回退等能力

service

Service可以看作是一组同类Pod对外的访问接口。同类pod指的是标签相同的pod
即可以通过pod的ip访问pod，一组同类的pod统一对外提供一个ip地址叫service ip，访问service ip，然后请求轮询给到service下的各个pod


svc两种模式，ClusterIP默认是集群内ip才能访问，
下面为例子，在master节点上可以通过pod ip访问pod，也可以通过访问service，让service将请求轮询打到同一label的pod上

NodePort-SVC

如果希望将Service暴露给集群外部使用，那么就要使用到另外一种类型的Service，称为NodePort类型。NodePort的工作原理其实就是将service的端口映射到Node的一个端口上，然后就可以通过NodeIp:NodePort来访问service了

如下图：和下下图，集群内任意一个Nodeip:NodePort，
外部访问通过NodePort，打到对应的Nodeport类型的service上（service port），然后service将请求分给service下统一label的pod，每个pod有自己的port，在配置文件中叫targetport

ingress

ingress：kubernetes中的一个对象，作用是定义请求如何转发到service的规则
ingress controller：具体实现反向代理及负载均衡的程序，对ingress定义的规则进行解析，根据配置的规则来实现请求转发，实现方式有很多，比如Nginx, Contour, Haproxy等等

如下配置，hello.atguigu.com这个域名直接访问到hello-server这个service，然后根据service的配置文件轮询分配给同一个label的pod。

apiVersion: networking.k8s.io/v1
kind: Ingress  
metadata:name: ingress-host-bar
spec:ingressClassName: nginxrules:- host: "hello.atguigu.com"http:paths:- pathType: Prefixpath: "/"backend:service:name: hello-serverport:number: 8000- host: "demo.atguigu.com"http:paths:- pathType: Prefixpath: "/nginx"  # 把请求会转给下面的服务，下面的服务一定要能处理这个路径，不能处理就是404backend:service:name: nginx-demo  ## java，比如使用路径重写，去掉前缀nginxport:number: 8000

如下图，ingress域名映射service ip，记得写到hosts文件里面

我们可以通过域名:port访问到，下图

 path: "/nginx"  # 把请求会转给下面的服务，下面的服务一定要能处理这个路径，不能处理就是404

path实际处理中就是这样

ingress的一些高级应用，比如路径重写，流量限制等在看文档理解https://kubernetes.github.io/ingress-nginx/

存储Volume（原生方式数据挂载+PV+PVC）

在前面已经提到，容器的生命周期可能很短，会被频繁地创建和销毁。那么容器在销毁时，保存在容器中的数据也会被清除。这种结果对用户来说，在某些情况下是不乐意看到的。为了持久化保存容器的数据，kubernetes引入了Volume的概念。

Volume是Pod中能够被多个容器访问的共享目录，它被定义在Pod上，然后被一个Pod里的多个容器挂载到具体的文件目录下，kubernetes通过Volume实现同一个Pod中不同容器之间的数据共享以及数据的持久化存储。Volume的生命容器不与Pod中单个容器的生命周期相关，当容器终止或者重启时，Volume中的数据也不会丢失。

kubernetes的Volume支持多种类型，比较常见的有下面几个：

简单存储：EmptyDir、HostPath、NFS
高级存储：PV、PVC
配置存储：ConfigMap、Secret

如上图左边，比如pod内/data目录期望挂载到主机的/a目录，这样我们直接在主机上修改/a目录的内容，就相当于修改pod内部的/data目录内容
这样的挂载方式是docker的方式，现在用k8s如果用这种方式挂载会有问题，比如pod崩溃以后，deploy会起一个新的pod，这个新的pod可能在新的节点上，新的节点目录存储挂载到原来的/tmp目录，但是原来的/tmp目录在三号机器，现在新映射的/tmp在二号机器，原来三号机器的/tmp内容在二号机器没有。。。所以期望就算pod转移到其他机器，原来的数据挂载还在。

所以k8s解决方案是，抽象出存储层，都存在存储层上，这样数据就不会丢失。（比如NFS）

简单存储-NFS（网络文件系统）

以上图来看，其实就是将pod内部的目录，挂载到pod外的节点的目录上
其中/nfs/data是主节点的目录，后续的/bak/data和/nfs/data是同样的内容，是其备份
NFS系统的意思就是/nfs/data /bak/data /bak/data这三个目录数据同步，就算pod在另外一个节点重新启动，数据也不会丢失
即

根据文档在主从节点准备NFS环境

apiVersion: apps/v1
kind: Deployment
metadata:labels:app: nginx-pv-demoname: nginx-pv-demo
spec:replicas: 2selector:matchLabels:app: nginx-pv-demotemplate:metadata:labels:app: nginx-pv-demospec:containers:- image: nginxname: nginxvolumeMounts:- name: htmlmountPath: /usr/share/nginx/htmlvolumes:- name: htmlnfs:server: 172.31.0.4path: /nfs/data/nginx-pv

上述配置其实如下图，将pod内部的/usr/share/nginx/html挂载到节点的/nfs/data/nginx-pv上

PV和PVC

由于kubernetes支持的存储系统有很多，要求客户全都掌握，显然不现实。为了能够屏蔽底层存储实现的细节，方便用户使用， kubernetes引入PV和PVC两种资源对象。

PV（Persistent Volume）是持久化卷的意思，是对底层的共享存储的一种抽象。一般情况下PV由kubernetes管理员进行创建和配置，它与底层具体的共享存储技术有关，并通过插件完成与共享存储的对接。

PVC（Persistent Volume Claim）是持久卷声明的意思，是用户对于存储需求的一种声明。换句话说，PVC其实就是用户向kubernetes系统发出的一种资源需求申请。

• 如上图，PV就是指数据真正存储的地方，如上图，可以提前固定好存储卷的大小，比如1G,20MB，等，NFS是不能限制存储大小的
• PVC就是一个申请，以后pod想用多大空间，先写一个申请书（PVC），比如要1G，那系统就给你开辟一个1G的实际存储空间
• pod删了，可以把pvc删了，只要删了pvc就可以回收空间
• 上图PV池（静态供应）：提前创建一些存储卷放这儿，这些存储集合就叫PV池。静态供应时，比如此时通过PVC，需要1个G的存储空间，这个时候就会从PV池里选择一个能满足需求的最小存储卷分配给它
• 动态供应：就是通过PVC，告诉存储空间需要多大，然后存储空间分配多大。
• pod删除后，连带其PVC一起删除

PV，PVC实战看文档,具体的配置文件和各个参数意思看文档

看上图，创建pvc后，pv中的pv02-1gi的状态变成Bound，看起CLAIM（申请书）就是绑定的nginx-pvc这个pvc
创建pod绑定pvc，

apiVersion: apps/v1
kind: Deployment
metadata:labels:app: nginx-deploy-pvcname: nginx-deploy-pvc
spec:replicas: 2selector:matchLabels:app: nginx-deploy-pvctemplate:metadata:labels:app: nginx-deploy-pvcspec:containers:- image: nginxname: nginxvolumeMounts:- name: htmlmountPath: /usr/share/nginx/htmlvolumes:- name: htmlpersistentVolumeClaim: #这个pod挂载的内容是nginx-pvc这个pvc要用的空间claimName: nginx-pvc 

ConfigMap（配置集,存储在etcd）

ConfigMap是一种比较特殊的存储卷，它的主要作用是用来存储配置信息的
将配置文件挂载出来，方便直接修改

如下图，先创建一个redis.conf(用来创建configmap用)

kubectl create cm redis-conf --from-file=redis.conf

从redis.conf中创建一个configmap,创建完后可以把redis.conf删除了

上图，看configmap的配置文件，一些不重要的信息删除后，提取出主要配置如下

apiVersion: v1
data:    #data是所有真正的数据，key：默认是文件名   value：配置文件的内容redis.conf: |appendonly yes
kind: ConfigMap
metadata:name: redis-confnamespace: default

此时创建一个pod，如下

apiVersion: v1
kind: Pod
metadata:name: redis
spec:containers:- name: redisimage: rediscommand:- redis-server- "/redis-master/redis.conf"  #指的是redis容器内部的位置ports:- containerPort: 6379volumeMounts:- mountPath: /dataname: data- mountPath: /redis-mastername: configvolumes:- name: dataemptyDir: {}- name: configconfigMap:name: redis-confitems:#获取data里面的所有项目- key: redis.confpath: redis.conf

VolumeMounts(卷挂载)
Volume(存储卷)
上述配置对应下图
pod内部的/data目录以name:data的方式存储，name:data对应着volumes中的name，可以看到name为data的volume是EmptyDir

/redis-master目录以configmap的形式配置存储，items:表示获取Configmap的配置文件中的data里面的所有项目，key指的是文件名，如下图箭头

path是redis.conf（可以改名），即把configmap里面的data的数据存入path:redis.conf(注意，这里key和path名字一样，二者可以不一样，比如key名字是abc，这里就是取出abc的值放入redis.conf)

Secret

在kubernetes中，还存在一种和ConfigMap非常类似的对象，称为Secret对象。它主要用于存储敏感信息，例如密码、秘钥、证书等等。