作用:和其他框架一样比如nacos,Namespace 主要作用是实现多套系统的资源隔离或者多租户的资源隔离
场景:默认情况下,kubernetes集群中所有的pod是可以相互访问的,为了隔离两个pod,可以将这两个pod划分到不同的Namespace中
使用:可以通过k8s的授权机制,将不同的Namespace交给不同的租户进行管理,这样就实现了多租户的资源隔离
常见Namespace
default 默认的Namespace,所有未指定Namespace的对象都会被分配到default kube-node-lease 集群节点之间的心跳维护 kube-public 此命名空间会被所有的用户访问 kube-system 所有由k8s系统创建的资源都处于这个命名字空间
常用命令
kubectl 命令使用Namespace
kubectl get namespace 简写 kubectl get ns 获取指定命名空间 kubectl get namespace default 查看命名空间的详情 kubectl describe ns default 创建命名空间 kubectl create ns dev 指定命名空间的输出格式 kubectl get ns default -o wide/json/yaml 删除命名空间 kubectl delete ns dev
yaml 创建Namespace
新建devns.yaml --- apiVersion: v1 kind: Namespace metadata: name: dev --- kubectl create -f ns-dev.yamlPod
1.pod是kubernetes的基本模块 ,它是kubenetes 对象模型中创建或部署的最小和最简单的单元
2.pod可以认为是容器的封装,一个pod可以存在一个或者多个容器
Pod的yaml 文件
apiVersion: v1 #必选，版本号，例如v1
kind: Pod #必选，资源类型，例如 Pod
metadata: #必选，元数据
name: string #必选，Pod名称
namespace: string #Pod所属的命名空间,默认为"default"
labels: #自定义标签列表
- name: string
spec: #必选，Pod中容器的详细定义
containers: #必选，Pod中容器列表
- name: string #必选，容器名称
image: string #必选，容器的镜像名称
imagePullPolicy: [ Always|Never|IfNotPresent ] #获取镜像的策略
command: [string] #容器的启动命令列表，如不指定，使用打包时使用的启动命令
args: [string] #容器的启动命令参数列表
workingDir: string #容器的工作目录
volumeMounts: #挂载到容器内部的存储卷配置
- name: string #引用pod定义的共享存储卷的名称，需用volumes[]部分定义的的卷名
mountPath: string #存储卷在容器内mount的绝对路径，应少于512字符
readOnly: boolean #是否为只读模式
ports: #需要暴露的端口库号列表
- name: string #端口的名称
containerPort: int #容器需要监听的端口号
hostPort: int #容器所在主机需要监听的端口号，默认与Container相同
protocol: string #端口协议，支持TCP和UDP，默认TCP
env: #容器运行前需设置的环境变量列表
- name: string #环境变量名称
value: string #环境变量的值
resources: #资源限制和请求的设置
limits: #资源限制的设置
cpu: string #Cpu的限制，单位为core数，将用于docker run --cpu-shares参数
memory: string #内存限制，单位可以为Mib/Gib，将用于docker run --memory参数
requests: #资源请求的设置
cpu: string #Cpu请求，容器启动的初始可用数量
memory: string #内存请求,容器启动的初始可用数量
lifecycle: #生命周期钩子
postStart: #容器启动后立即执行此钩子,如果执行失败,会根据重启策略进行重启
preStop: #容器终止前执行此钩子,无论结果如何,容器都会终止
livenessProbe: #对Pod内各容器健康检查的设置，当探测无响应几次后将自动重启该容器
exec: #对Pod容器内检查方式设置为exec方式
command: [string] #exec方式需要制定的命令或脚本
httpGet: #对Pod内个容器健康检查方法设置为HttpGet，需要制定Path、port
path: string
port: number
host: string
scheme: string
HttpHeaders:
- name: string
value: string
tcpSocket: #对Pod内个容器健康检查方式设置为tcpSocket方式
port: number
initialDelaySeconds: 0 #容器启动完成后首次探测的时间，单位为秒
timeoutSeconds: 0 #对容器健康检查探测等待响应的超时时间，单位秒，默认1秒
periodSeconds: 0 #对容器监控检查的定期探测时间设置，单位秒，默认10秒一次
successThreshold: 0
failureThreshold: 0
securityContext:
privileged: false
restartPolicy: [Always | Never | OnFailure] #Pod的重启策略
nodeName: #设置NodeName表示将该Pod调度到指定到名称的node节点上
nodeSelector: obeject #设置NodeSelector表示将该Pod调度到包含这个label的node上
imagePullSecrets: #Pull镜像时使用的secret名称，以key：secretkey格式指定
- name: string
hostNetwork: false #是否使用主机网络模式，默认为false，如果设置为true，表示使用宿主机网络
volumes: #在该pod上定义共享存储卷列表
- name: string #共享存储卷名称 （volumes类型有很多种）
emptyDir: {} #类型为emtyDir的存储卷，与Pod同生命周期的一个临时目录。为空值
hostPath: string #类型为hostPath的存储卷，表示挂载Pod所在宿主机的目录
path: string #Pod所在宿主机的目录，将被用于同期中mount的目录
secret: #类型为secret的存储卷，挂载集群与定义的secret对象到容器内部
scretname: string
items:
- key: string
path: string
configMap: #类型为configMap的存储卷，挂载预定义的configMap对象到容器内部
name: string
items:
- key: string
path: string
启动和停止
kubectl aplly -f xxx.yaml kubectl delete -f xxx.yaml
查看配置可选项
kubectl explain pod.spec.containers
拉取镜像策略
imagePullPolicy Always 总是从远程仓库拉取 ifNotPresent 优先从本地拉取镜像 Never 只使用本地镜像 不从远程拉取,本地没有就报错
案例( 资源限制 )
apiVersion: v1
kind: Pod
metadata:
name: pod-resoures
namespace: dev
spec:
containers:
- name: nginx # 容器名称
image: nginx:1.17.1 # 容器需要的镜像地址
imagePullPolicy: IfNotPresent # 设置镜像拉取策略
ports: # 端口设置
- name: nginx-port # 端口名称，如果执行，必须保证name在Pod中是唯一的
containerPort: 80 # 容器要监听的端口 （0~65536）
protocol: TCP # 端口协议
resources: # 资源配额
limits: # 限制资源的上限
cpu: "2" # CPU限制，单位是core数
memory: "10Gi" # 内存限制
requests: # 限制资源的下限
cpu: "1" # CPU限制，单位是core数
memory: "1Gi" # 内存限制
容器内的生命周期hook
apiVersion: v1 kind: Pod metadata: name: lifecycle-dev namespace: dev spec: containers: - name: lifecycle-demo-container image: nginx:1.19 lifecycle: postStart: # 容器启动之前执行 exec: command: ["/bin/sh", "-c", "echo Hello from the postStart handler > /usr/share/message"] preStop:# 容器被终止之前执行 exec: command: ["/usr/sbin/nginx","-s","quit"]pod生命周期
pod的创建->初始化容器->运行主容器-> 启动后钩子 ->结束前钩子 ->pod终止
pod五态Pending: Pod 已经被K8s接受,但是有容器尚未创建
Running: 该pod已经绑定到了一个节点上,Pod中所有的容器都被创建,至少有一个容器正在运行,或者正在处于启动和重启状态
Succeeded:所有pod都已经创建成功,而且不会在重启
Failed:因为有一个或者多个容器失败,Pod中所有的容器都终止
Unkonwn:无法获取Pod的状态
创建和终止流程创建:
->提交信息给ApiServer
->ApiServer在etcd上填写注册信息,并返回确认给客户端
->ApiServer开始反映etcd中Pod对象的变化,其他组件使用Watch机制来跟踪检查ApiServer上的变动
->Scheduler发现有新的Pod 开始为Pod分配主机,并将信息更新到ApiServer
->Node节点上的kubelet发现有pod调读过来,开始调读容器,并返回结果给ApiServer
->ApiServer将收到的Pod状态信息存入etcd
终止:
->用户向ApiServer发送删除Pod对象的指令
->API Server中的Pod对象信息会随着时间的推移而更新，在宽限期内（默认30s），Pod被视为dead。
->将Pod标记为terminating状态。
->kubelete在监控到Pod对象转为terminating状态的同时启动Pod关闭过程。
->端点控制器监控到Pod对象的关闭行为时将其从所有匹配到此端点的service资源的端点列表中移除。
->如果当前Pod对象定义了preStop钩子处理器，则在其标记为terminating后会以同步的方式启动执行。
->Pod对象中的容器进程收到停止信号。
->宽限期结束后，如果Pod中还存在运行的进程，那么Pod对象会收到立即终止的信号。
->kubectl请求API Server将此Pod资源的宽限期设置为0从而完成删除操作，此时Pod对于用户已经不可用了。
容器探测 健康检查目前有三种探针:
livenessProve :存活性探测,决定是否 用来检测容器是否真的运行,即探活.如果检测失败 kubelet就会停掉容器,容器后面的操作就会收到其重启策略影响
readinessProbe: 常常用于指示容器是否可以对外提供正常的服务请求,即就绪,比如nginx容器在reload配置的时候无法对外提供http服务
startupProbe(1.6版本新增加 1.8版本后变为beta):添加启动超时时间 (次数*间隔时间)如果超时,和livenessProve 一样 kubelet就会停掉容器,容器后面的操作就会收到其重启策略影响
常见探测方式
exec命令：在容器内执行一次命令，如果命令执行的退出码为0，则认为程序正常，否则不正常。
apiVersion: v1
kind: Pod
metadata:
name: pod-liveness-exec
namespace: dev
labels:
user: xudaxian
spec:
containers: # 容器配置
- name: nginx
image: nginx:1.17.1
imagePullPolicy: IfNotPresent
ports:
- name: nginx-port
containerPort: 80
protocol: TCP
livenessProbe: # 存活性探针
exec:
command: ["/bin/cat","/tmp/hello.txt"] # 执行一个查看文件的命令，必须失败，因为根本没有这个文件
tcpSocket：将会尝试访问一个用户容器的端口，如果能够建立这条连接，则认为程序正常，否则不正常。
apiVersion: v1
kind: Pod
metadata:
name: pod-liveness-tcpsocket
namespace: dev
labels:
user: xudaxian
spec:
containers: # 容器配置
- name: nginx
image: nginx:1.17.1
imagePullPolicy: IfNotPresent
ports:
- name: nginx-port
containerPort: 80
protocol: TCP
livenessProbe: # 存活性探针
tcpSocket:
port: 8080 # 尝试访问8080端口，必须失败，因为Pod内部只有一个Nginx容器，而且只是监听了80端口
httpGet：调用容器内web应用的URL，如果返回的状态码在200和399之前，则认为程序正常，否则不正常。
apiVersion: v1
kind: Pod
metadata:
name: pod-liveness-httpget
namespace: dev
labels:
user: xudaxian
spec:
containers: # 容器配置
- name: nginx
image: nginx:1.17.1
imagePullPolicy: IfNotPresent
ports:
- name: nginx-port
containerPort: 80
protocol: TCP
livenessProbe: # 存活性探针
httpGet: # 其实就是访问http://127.0.0.1:80/hello
port: 80 # 端口号
scheme: HTTP # 支持的协议，HTTP或HTTPS
path: /hello # URI地址
host: 127.0.0.1 # 主机地址
其他探测方式
initialDelaySeconds # 容器启动后等待多少秒执行第一次探测 timeoutSeconds # 探测超时时间。默认1秒，最小1秒 periodSeconds # 执行探测的频率。默认是10秒，最小1秒 failureThreshold # 连续探测失败多少次才被认定为失败。默认是3。最小值是1 successThreshold # 连续探测成功多少次才被认定为成功。默认是1重启策略
k8s 中定义了如下三种重启策略,可以通过spec.restartPolicy 字段在pod中进行设置
-
- Always：容器失效时，自动重启该容器，默认值。
-
- OnFailure：容器终止运行且退出码不为0时重启。
-
- Never：不论状态如何，都不重启该容器。
kube-scheduler作为k8s的调度器,他的主要任务是给新创建pod或者是未被调度的pod挑选一个合适的节点供pod运行
一般是由scheduler组件采用算法计算而出 这个过程是不受人工控制的,但是在实际使用中,并不满足需求
对此k8s提出了四种调度方式
1.自动调度 运行在哪个node节点完全由scheduler 计算得出
2.定向调度: NodeName NodeSelector
3.亲和性调度: NodeAffinity PodAffinity PodAntiAffinity
4.污点(容忍)调度 :taints toleration
总的来说调度一般分为两步 第一 过滤一些不满足条件的节点 这个过程也成为predict 其次排序打分 priority
定向调度:
nodeName
apiVersion: v1
kind: Pod
metadata:
name: pod-nodename
namespace: dev
spec:
containers: # 容器配置
- name: nginx
image: nginx:1.17.1
imagePullPolicy: IfNotPresent
ports:
- name: nginx-port
containerPort: 80
protocol: TCP
nodeName: k8s-node1 # 指定调度到k8s-node1节点上
nodeSelector
将pod调度到指定标签的Node节点上,他是通过了K8s的MatchNodeSelector 调度进行label匹配,找出目标node,从而达到一个筛选节点的目的
apiVersion: v1
kind: Pod
metadata:
name: pod-nodeselector
namespace: dev
spec:
containers: # 容器配置
- name: nginx
image: nginx:1.17.1
imagePullPolicy: IfNotPresent
ports:
- name: nginx-port
containerPort: 80
protocol: TCP
nodeSelector:
nodeenv: pro # 指定调度到具有nodeenv=pro的Node节点上
如果没有满足条件的Node，那么Pod将不会被运行，即使在集群中还有可用的Node列表也不行，这就限制了它的使用场景。
亲和性调度:
-
Affinity主要分为三类：
-
- nodeAffinity（node亲和性）：以Node为目标，解决Pod可以调度到那些Node的问题。
-
- podAffinity（pod亲和性）：以Pod为目标，解决Pod可以和那些已存在的Pod部署在同一个拓扑域中的问题。
-
- podAntiAffinity（pod反亲和性）：以Pod为目标，解决Pod不能和那些已经存在的Pod部署在同一拓扑域中的问题。
关于亲和性和反亲和性的使用场景的说明：
-
亲和性：如果两个应用频繁交互，那么就有必要利用亲和性让两个应用尽可能的靠近，这样可以较少因网络通信而带来的性能损耗。
-
反亲和性：当应用采用多副本部署的时候，那么就有必要利用反亲和性让各个应用实例打散分布在各个Node上，这样可以提高服务的高可用性。
污点和容忍
其实我们也可以站在Node的角度上，通过在Node上添加污点属性，来决定是否运行Pod调度过来。
Node被设置了污点之后就和pod之间存在一种互斥的关系,从而拒绝pod调度进来,甚至可以将已经存在的pod驱逐出去
污点的格式为：key=value:effect
种类有
-
- PreferNoSchedule：kubernetes将尽量避免把Pod调度到具有该污点的Node上，除非没有其他节点可以调度。
-
- NoSchedule：kubernetes将不会把Pod调度到具有该污点的Node上，但是不会影响当前Node上已经存在的Pod。
-
- NoExecute：kubernetes将不会把Pod调度到具有该污点的Node上，同时也会将Node上已经存在的Pod驱逐。
设置污点
kubectl taint node xxx key=value:PreferNoSchedule
去除污点
kubectl taint node xxx key:PreferNoSchedule-
去除所有
kubectl taint node xxx key-
容忍
污点就是拒绝，容忍就是忽略，Node通过污点拒绝Pod调度上去，Pod通过容忍忽略拒绝
容忍的详细配置:
FIELDS: key # 对应着要容忍的污点的键，空意味着匹配所有的键 value # 对应着要容忍的污点的值 operator # key-value的运算符，支持Equal和Exists（默认） effect # 对应污点的effect，空意味着匹配所有影响 tolerationSeconds # 容忍时间, 当effect为NoExecute时生效，表示pod在Node上的停留时间
案例
tolerations: # 容忍
- key: "tag" # 要容忍的污点的key
operator: Equal # 操作符
value: "myname" # 要容忍的污点的value
effect: NoExecute # 添加容忍的规则，这里必须和标记的污点规则相同
kubectl create -f pod-toleration.yaml
