K8S核心概念学习笔记
一.K8s的核心组件与分层架构
k8sb除了包含控制面板(Master)和节点(Node)外,还包含kubectl命令行工具和dashboard仪表盘。
1.K8s Master节点核心组件
- api-server ：接口服务,基于REST风格开放k8s接口的服务。
- kube-controller-manager ： 控制器管理器:管理各个类型的控制器,针对k8s中的各种资源进行管理。
- cloud-controller-manager : 云控制器:第三方云平台提供的控制器api对接管理功能。
- kube-scheduler : 调度器:负责将pod基于一定算法,将其调用到更合适的节点(服务器)上。
- etcd : 理解为k8s的数据库,键值类型存储的分布式数据库,提供了基于Raft算法实现自主的集群高可用
(老版本:基于内存 新版本:持久化存储)
2.K8s Node 节点核心组件
- kubelet ： 负责pod的生命周期、存储、网络
- kube-proxy ; 网络代理负责Service的服务发现负载均衡(4层负载)
- pod容器组 : pod中可以包含单个容器也可以包含多个容器
- container-runtime : 容器运行时环境:docker、containerd、CRL-O
二、K8s核心概念
1.服务的分类:有状态和无状态
- 无状态
- 代表应用 : Nginx,Apache
- 优点
- 对客户端透明,无依赖关系,可以高效实现扩容、迁移
- 缺点
- 不能存储数据,需要额外的数据服务支撑
- 有状态
- 代表应用 ：redis,mysql
- 优点
- 可以独立存储数据,实现数据管理
- 缺点
- 集群环境下需要实现主从、数据同步、备份、扩容复杂。
2.资源和对象与对象规约和状态
资源和对象
kubernetes中所有内容都被抽象为"资源",如pod、Service、Node等都是资源。"对象"就是资源的实例,是持久化的实体,如某个具体的pod、某个具体的Node,Kubernetes使用这些实体去表示整个集群的状态。
规约和状态
"spec “是"规约”、"规格"的意思,spec是必要的,它描述了对象的期望状态,当创建kubernetes对象时,必须提供对象的规约,用来描述该对象的期望状态,以及关于对象的一些基本信息(例如名称)。
status表示对象的实际状态,该属性由k8s自己维护,k8s会通过一系列的控制器对对应对象进行管理,让对象尽可能的让实际状态与期望状态重合。
资源的分类
资源可以分为元数据资源、集群资源、命名空间资源
(1) 元数据型资源:
- HPA:
Pod自动扩容:可以根据CPU使用率或自定义指标(metrics)自动对Pod进行扩/缩容。
- 控制管理器每隔30s(可以通过-horizoptal-pod-autoscaler-sync-period修改)查询metrics的资源使用情况。
- 支持三种metrics类型
- 预定义metrics(比如pod的cpu)以利用率的方式计算
- 自定义的pod metrics,以原始值(raw value)的方式计算
- 自定义的object metrics
- 支持两种metrics查询方式:Heapster和自定义的REST API
- 支持多metrics
- PodTemplete
Pod Templete是关于Pod的定义,但是被包含在其他的Kubernetes对象中(例如Deployment,StatefulSet,DaemonSet等控制器),控制器通过Pod Templete信息来创建Pod。
- LimitRange
可以对集群内Request和Limits的设置做一个全局的统一的限制,相当于批量设置了某一个范围内(某个命名空间)的Pod的资源使用限制。
(2) 集群级资源:
- Namespace
- Node
- ClusterRole:集群角色(相当于只是声明了一个角色)
- ClusterRoleBinding:集群角色绑定,将声明的角色绑定到某个集群级的数据上。
（3）命名空间级资源
1)工作负载型
a.Pod
Pod(容器组)是Kubernetes中最小的可部署单元,一个Pod(容器组)包含了一个应用程序容器(某些情况下是多个容器)、存储资源、一个唯一的网络IP地址,以及一些确定容器该如何运行的选项,Pod容器组代表了Kubernetes中一个独立的应用程序运行实例,该实例可能由单个容器或者几个紧耦合在一起的容器组成。
Docker是Kubernetes Pod中使用最广泛的容器引擎;
Kubernetes Pod同时也支持其他类型的容器引擎。
kubernetes集群中的Pod存在如下两种使用途径:
- 一个Pod中只运行一个容器。"one-container-per-pod"是Kubernetes中最常见的使用方式。此时,您可以认为pod容器组是该容器的wrapper,Kubernetes通过Pod管理容器,而不是直接管理容器。
- 一个Pod中运行多个需要互相协作的容器,您可以将多个紧密耦合、共享资源且始终在一起运行的容器编排在同一个Pod中,可能的情况有:
- 副本(replicas)
一个Pod可以被复制成多份,每一份可以被称之为一个"副本",这些"副本"除了一些描述性的信息(Pod的名字、uid等)不一样外,其他信息都是一样的,例如Pod内部的容器、容器数量、容器里面运行的应用等的这些信息都是一样的,这些副本提供同样的功能。
Pod的控制器通常包含一个名为"replicas"的属性,"replicas"属性则制定了特定Pod的副本数量,当当前集群中该Pod的数量与该属性指定的不一致时,k8s会采取一些策略去使得当前状态满足配置的要求。
为什么要有Pod,直接使用容器不好吗?
- 控制器
适用无状态服务的控制器
ReplicationController(RC)
RC是Kubernetes系统中的核心概念之一,简单来说,RC可以保证在任意时间运行Pod的副本数量,能够保证Pod总是可用的。如果实际Pod数量比指定的多那就结束掉多余的,如果实际数量比指定的少就新启动一些Pod,当Pod失败,被删除或者挂掉后,RC都会去自动创建新的Pod来保证副本数量,所以即使只有一个Pod,我们也应该使用RC来管理我们的Pod。可以说,通过ReplicationController,kubernetes实现了Pod的高可用性。
ReplicaSet(RS)
RS是对RC的升级,与RC没有本质的区别,并且RS支持集合式的selector
Deployment
Deployment 为 Pod 和 Replica Set 提供声明式更新。是ReplicaSet的加强版本。
Deployment具有仪下4种功能:
- 创建ReplicaSet / Pod
- 滚动升级 / 回滚
-
平滑扩容和缩容
-
暂停与恢复Deployment(当有变动之后默认是自动滚动升级,可以通过暂停与恢复操作,全部改动完成之后再进行统一升级)
适用于有状态服务的控制器
StatefulSet
主要特点: -
稳定的持久化存储
-
稳定的网络标志
-
有序部署,有序扩展
-
有序收缩,有序删除
组成:
- Headless Service
- volumeClaim Template
注意事项
- kubernetes v1.5版本以上才支持
- 所有pod的Volume必须使用persistentVolume或者管理员实现创建好
- 为了保证数据安全删除StatefulSet时不会删除Volume
- StatefulSet需要一个Headless Service来定义DNS domain,需要在StatefulSet之前创建好。
守护进程
DaemonSet
DaemonSet保证在每个Node上都运行一个容器副本,常用来部署一些集群的日志、监控或者其他系统管理应用。典型的应用包括:
- 日志收集:比如fluentd,logstash等
- 系统监控:比如 Prometheus Node Exporter，collectd，New Relic agent，Ganglia gmond 等
- 系统程序:比如 kube-proxy, kube-dns, glusterd, ceph 等
任务 / 定时任务
Job:一次性任务,运行完成后pod销毁,不再重新启动新容器。
CronJob:CronJob是在Job基础上加上了定时功能。
2) 服务发现
Service和Ingress
Service:实现k8s集群内部网络调用、负载均衡(四层负载)
Ingress:实现将k8s内部服务暴露给外网访问的服务(七层负载)
)
3) 存储
Volume:数据卷,共享pod中容器使用的数据,用来放持久化的数据,比如数据库数据。
CSI(Container Storage Interface):CSI是一个行业标准接口规范,旨在将任意存储系统暴露给容器化应用程序。
4) 特殊类型配置
ConfigMap:用来放配置,与Secret是类似的,只是ConfigMap放的是明文的数据,Secret是密文存放。
Secret
Secret有三种类型:
- Service Account:用来访问kubernetes API,由Kubernetes自动创建,并且会自动挂载到pod的/run/secrets/kubernetes.io/serviceaccount目录中
- Opaque:base64编码格式化的Secret,用来存储密码、密钥等。
- kubernetes.io / dockerconfigjson:用来存储私有docker registry的认证信息。
DownwardAPI:downwardAPI不是为了存放容器的数据也不是用来进行容器和宿主机的数据交换的,而是让pod里的容器能够直接获取到这个pod对象本身的一些信息。
downwardAPI提供了两种方式用于将pod的信息注入到容器内部:
- 环境变量:用于单个变量,可以将pod信息和容器信息直接注入容器内部。
- volume挂载:将pod信息生成文件,直接挂载到容器内部中去。
5) 其他
Role和RoleBinding同集群级的ClusterRole和ClusterRoleBinding作用一样,只不过Role和RoleBinding作用于命名空间级。
三、k8s集群搭建
1.搭建方案
2.命令行工具kubectl的使用
内容较多,暂未补充~
1.资源操作
四、k8s资源清单
暂未补充,计划超链接到另一个文章单独描述~
五、深入Pod
1.Pod配置文件
apiVersion: v1 #api文档版本
kind: Pod #资源对象类型,也可以配置为像Deployment、StatefulSet这一类的对象
metadata: #pod相关的元数据,用于描述pod的数据
name: nginx-demo #pod的名称
labels: #定义pod的标签
type: app #自定义label标签,名字为type,值为app
test: 1.0.0 #自定义label标签,描述pod版本号
namespace: 'default' #命名空间的配置
spec: #期望pod按照这里面的描述进行创建
containers: #对于pod中的容器描述
- name: nginx #容器的名称
image: nginx:1.7.9 #指定容器的镜像
imagePullPolicy: ifNotParesent #镜像拉取策略,指定如果本地有就用本地的,如果没有就拉取远程的
command: #指定容器启动时执行的命令
- nginx
- -g
- 'daemon off;' #nginx -g 'daemon off;'
workingDir: /usr/lshare/nginx/html #定义容器启动后的工作目录
ports:
- name: http #端口名称
containerPort: 80 #描述容器内要暴露什么端口
protocol: TCP #描述该端口是基于哪种协议通信的
env: #环境变量
- name: JVM_OPTS #环境变量名称
value: '-Xms128m -Xmx128m' #环境变量的值
resources:
requests: #最少需要多少资源
cpu: 100m #限制cpu最少使用0.1个核心
memory: 128Mi #限制内存最少使用128兆
limits: #最多可以用多少资源
cpu: 200m #限制cpu最多使用0.2个核心
memory: 256Mi #限制最多使用256兆
restartPolicy: OnFailure #重启策略,只有失败的情况才会重启
2.探针
1.探针的类型
- StartupProbe:
k8s 1.16版本新增的探针,用于判断应用程序是否已经启动了。
当配置了StartupProbe后,会闲禁用其他探针,直到StartupProbe成功后,其他探针才会继续。
作用: 由于有时候不能准确预估应用一定是多长时间启动成功,因此配置另外两个方式不方便配置初始化时长来检测,而配置了StartupProbe后,只有应用启动成功了,才会执行另外两种探针,可以更加方便的结合使用另外两种探针使用。
startupProbe:
httpGet:
path: /api/path
port: 80
- LivenessProbe:
用于探测容器中的应用是否运行,如果探测失败,kubelet会根据配置的重启策略进行重启,若没有配置,默认就认为容器启动成功,不会执行重启策略。
livenessProbe:
failureThreshold: 5
httpGet:
path: /health
port: 8080
scheme: HTTP
initialDelaySeconds: 60
periodSeconds: 10
successThreshold: 1
timeoutSeconds: 5
- ReadinessProbe:
用于探测容器内的程序是否健康,它的返回值如果返回success,那么就认为该容器已经完全启动,并且该容器是可以接收外部流量的。
readinessProbe:
failureThreshold: 3
httpGet:
path: /ready
port: 8181
shceme: HTTP
periodSeconds: 10
successThreshold: 1
timeoutSeconds: 1
2.探针的探测方式
- ExecAction
在容器内部执行一个命令,如果返回值为0,则任务容器是健康的。
livenessProbe:
exec:
command:
- cat
- /health
- TCPSocketAction
通过tcp连接监测容器内端口是否开放,如果开放则证明该容器健康。
livenessProbe:
tcpSocket:
port: 80
- HTTPGetAction
生产环境用的较多的方式,发送HTTP请求到容器内的应用程序,如果接口返回的状态码在200~400之间,则认为容器健康。
livenessProbe:
failureThreshold: 5
httpGet:
path: /health
port: 8080
scheme: HTTP
httpHeader:
- name: xxx
value: xxx
3.参数配置
initialDelaySeconds: 60 #初始化时间
timeoutSeconds: 2 #超时时间
periodSeconds: 5 #监测间隔时间
successThreshold: 1 #检查1次成功就表示成功
failureThreshold: 2 #检测失败2次就表示失败
3.生命周期
Pod退出流程
- Endpoint删除pod的ip地址。
- pod变为Terminating状态。
变为删除中的状态后,会给pod一个宽限期,让pod去执行一些清理或销毁的操作。
配置参数:
#作用于pod中的所有容器
terminationGracePeriodSeconds: 30
containers:
- xxx
- 执行preStop的指令。
PreStop的应用
- 注册中心下线
- 数据清理
- 数据销毁
生命周期流程图
一般情况下,不使用postStart,因为postStart阶段不可阻塞,无法确定postStart和command谁先执行,因此,容器启动之前的操作一般放到pod初始化阶段进行处理。
六、资源调度
1.Label和Selector
1.标签(Label)
- 配置文件
在各类资源的metadata.labels中进行配置
- kubectl命令行
- 临时创建label:kubectl label po <资源名称> app=hello
- 修改已经存在的标签 kubectl label po <资源名称> app=hello2 --overwrite
- selector按照label单值查找节点: kubectl get po -A -l app=hello
- 查看所有节点的labels: kubectl get po --show-labels
2.选择器(Selector)
- 配置文件
在各对象的配置spec.selector或其他可以写selector的属性中编写。
- kubectl命令行
#匹配单个值，查找 app=hello 的 pod
kubectl get po -A -l app=hello
#匹配多个值
kubectl get po -A -l 'k8s-app in (metrics-server,kubernetes-dashboard)'
#查找version!=1 and app=nginx的pod信息
kubectl get po -l version!=1,app=nginx
#不等值+语句
kubectl get po -A -l version!=1,'app in (busybox,nginx)'
2.Deployment
1.功能
1.创建
创建一个 deployment
kubectl create deploy nginx-deploy --image=nginx:1.7.9
或执行
kubectl create -f xxx.yaml --record
–record 会在annotation中记录当前命令创建或升级了资源
查看部署信息
kubectl get deployments
查看rs
kubectl get rs
查看pod以及展示标签,可以看到是关联的哪个rs
kubectl get pods --show-labels
2.滚动更新
修改nginx版本号
kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1
或者通过kubectl edit deploy nginx-deploy 进行修改
查看滚动更新的过程
kubectl rollout status deploy <deployment_name>
多个滚动更新并行的情况
假设当前有5个nginx1.7.9版本,你想将版本更新为1.9.1,当更新成功第三个以后,你马上又将期望更新的版本为1.9.2,那么此时会立马删除之前的三个,并且立马开启更新1.9.2的任务
3.回滚
默认情况下,kubernetes会在系统中保存前两次的Deployment的rollout历史记录,以便你可以随时会退(你可以修改revision history limit来更改保存的revision数)。
获取revision的列表
kubectl rollout history deploy nginx-deploy
查看revision的详细信息
kubectl rollout history deploy nginx-deploy --revision=2
回退上一个版本
kubectl rollout undo deploy nginx-deploy
回退到指定的revision
kubectl rollout undo deploy nginx-deploy --to-revision=2
可以通过设置spec.revisionHistoryLimit来指定deployment保留多少revision,如果设置为0,则不允许deployment回退了。
4.扩容缩容
通过kubectl scale --replicas=xx 命令可以进行自动扩容 / 缩容,以及通过kubectl edit 编辑replicas也可以实现扩容 / 缩容。
扩容与缩容只是直接创建副本数,没有更新pod template因此不会创建新的rs。
5.暂停与恢复
暂停deployment滚动更新,知道下次恢复后才会继续进行滚动更新。
kubectl rollout pause deployment
恢复deployment滚动更新
kubectl rollout resume deployment
2.配置文件
apiVersion: apps/v1 #deployment api版本
kind: Deployment #资源类型为deployment
metadata: #元信息
labels: #标签
app: nginx-deploy #具体的key:value配置形式
name: nginx-deploy
namespace: default
spec:
replicas: 1 #期望副本数
revisionHistoryLimit: 10 #进行滚动更新后,保留的历史版本数
selector: #选择器,用于找到匹配的RS
matchLabel: #按照标签匹配
app: nginx-deploy #匹配的标签key/value
strategy: #更新策略
rollingUpdate: #滚动更新
maxSurge: 25% #进行滚动更新时,更新的个书最多可以超过期望副本数的个数/比例
maxUnavailable: 25% #进行滚动更新时,最大不可用比例,表示在所有副本数中,最多可以有多少个不更新成功。
type: RollingUpdate #更新类型,采用滚动更新
template: #pod模板
metadata: #pod的元信息
labels: #pod的标签
app: nginx-deploy
spec: #pod期望信息
containers: #pod的容器
- image: nginx:1.7.9 #镜像
imagePullPolicy: IfNotPresent #拉取策略
name: nginx #容器名称
restartPolicy: Always #重启策略
terminationGracePeriodSecond: 30 #删除操作最多宽限多长时间
3.StatefulSet
1.功能
1.创建
kubectl create -f web.yaml
查看service和statefulSet
kubectl get svc nginx
kubectl get sts web
查看pvc信息
kubectl get pvc
2.扩容缩容
- 第一种方式
kubectl scale sts web --replicas=5
- 第二种方式
kubectl patch sts web -p ‘{“spec”:{“replicas”:3}}’
3.镜像更新
kubectl patch sts web --type=‘json’ -p=‘[{“op”: “replace”, “path”: “/spec/template/spec/containers/0/image”, “value”:“nginx:1.9.1”}]’
- RollingUpdate
StatefulSet也可以采用滚动更新策略,同样是修改pod template属性后会触发更新,但是由于pod是有序的,在StatefulSet中更新时是基于pod的顺序倒序更新的。
灰度发布 / 金丝雀发布(类似于农药体验服)**
利用滚动更新中的partition属性,可以实现简易的灰度发布的效果
例如我们有5个pod,如果当前partition设置为3,那么此时滚动更新时,只会更新那些序号>=3的pod
利用该机制,我们可以通过控制partition的值,来决定只更新其中一部分pod,确认没有问题后再逐渐增大更新的pod数量,最终实现全部pod更新。
- OnDelete
只有在pod被删除时会进行更新操作
4.删除
级联删除:删除StatefulSet时会同时删除pods
kubectl delete sts web
非级联删除:删除StatefulSet时不会删除pods,删除sts后,pods就没人管了,此时再删除pod不会重建的。
kubectl delete sts web --cascade=false
StatefulSet删除后pvc还会保留着,数据不再使用的话也需要删除。
kubectl delete pvc www-web-0 www-web-1
2.配置文件
---
apiVersion: v1
kind: Service
metadata:
name: nginx
labels:
app: nginx
spec:
ports:
- port: 80
name: web
clusterIP: None
selector:
app: nginx
---
apiVersion: apps/v1
kind: StatefulSet #StatefulSet 类型的资源
metadata:
name:web #StatefulSet 对象的名称
spec:
serviceName: "nginx" #使用哪个service来管理dns
replicas:2
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.7.9
ports: #容器内部要暴露的端口
- containerPort: 80 #具体暴露的端口号
name: web #该配置端口的名字
volumeMounts: #加载数据卷
- name: www #指定加载哪个数据卷
mountPath: /usr/share/nginx/html #加载到容器中的哪个目录
volumeClaimTemplates: #资源卷模板
- metadata: #数据卷描述
name: www #数据卷的名称
annotations: #数据卷的注解
volume.alpha.kubernetes.io/storage-class: anything
spec:
accessModes:["ReadWriteOnce"] #访问方式
resources:
requests:
storage: 1Gi #需要1G的存储资源
4.DaemonSet
1.指定Node节点
- nodeSelector
先为Node打上标签
kubectl label no svc <标签键>=<标签值>
然后再daemonSet配置中设置nodeSelector
spec:
template:
spec:
nodeSelector:
<标签键>: <标签值>
- nodeAffinity
- podAffinity
2.滚动更新
不建议使用默认的RollingUpdate作为滚动更新的策略,建议使用OnDelete模式,这样可以避免频繁更新 ds。
3.配置文件
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: fluentd
spec:
selector:
matchLabels:
app: logging
template:
metadata:
labels:
app: logging
id: fluentd
name: fluentd
spec:
containers:
- name: fluentd-es
image: agilestacks / fluentd-elasticsearch:v1.3.0
env:
- name: FLUENTD_ARGS
value: -qq
volumeMounts:
- name: containers
mountPath: /var/lib/docker/containers
- name: varlog
mountPath: /varlog
volumes:
- hostPath:
path: /var/lib/docker/containers
name: containers
- hostPath:
path: /varlog
name: varlog
当有新的node产生时,ds会通过nodeSelector属性进行匹配,node中会自动添加一个包含ds的Pod。
5.HPA 自动扩容/缩容
1.开启指标服务
下载metrics-server组件配置文件
wget https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml -O metrics-server-components.yaml
修改镜像地址为国内的地 址
首先通过命令 grep images <文件名> 查看该文件中的镜像地址
之后通过命令修改镜像地址为国内的地址,如果镜像地址不同,则将下面红色标注的镜像地址替换掉。
sed -i ‘s/k8s.gcr.io/metrics-server/registry.cn-hangzhou.aliyuncs.com/google_containers/g’ metrics-server-components.yaml
最后修改容器的tls配置,不验证tls,在containers的args参数中增加 --kubelet-insecure-tls参数
2.cpu、内存指标监控
实现cpu或内存的监控,首先有个前提条件是该对象必须配置了resources.requests.cpu或者resources.requests.memonry才可以,可以配置当cpu/memory达到上述配置的百分比后,进行扩容或缩容。
创建一个HPA:
- 先准备好一个有做资源限制的deployment
- 执行命令 kubectl autoscale deploy nginx-deploy --cpu-percent=20 --min=2 --max=5
- 通过kubectl get hpa 可以获取HPA信息。
测试方法:找到对应服务的service,编写循环测试脚本提升内存和cpu负载
while true;do wget -q -O http://ip:port > /dev/null;done
3.自定义metrics
自定义指标需要满足以下条件:
- 控制管理器开启-horizontal-pod-autoscaler-use-rest-clients
- 控制管理器的-apiserver指向 API Server Aggregator
- 在API Server Aggregator中注册自定义的metrics API
七、服务发布
1.Service(负责东西流量的通信)
1.Service实现内部服务的访问
1.Service、Pod与Endpoint之间的关系和原理
2.配置文件
apiVersion: v1
kind: Service # 资源类型为Service
metadata:
name: nginx-svc # Service 名字
labels:
app: nginx # Service 自己本身的标签
spec:
selector: # 匹配哪些Pod会被该service代理
app: nginx-deploy
ports: # 端口映射
- port: 80 # service 自己的端口,在使用内网ip访问时使用
targetPort: 80 # 目标pod的端口
name: web # 为端口起个名字
type: NodePort # 随机启动一个端口(30000-32767),映射到ports中的端口,该端口是直接绑定在node上的,且集群中的每一个node都会绑定这个端口。
# 也可以用于将服务器暴露给外部访问,但是这种方式实际生产环境不推荐,效率较低,而且Service是四层负载。
2.Service实现外部服务的访问
1.为什么要实现Service代理外部服务的访问,这样做有什么样的好处?
- 跨环境一致性： 在不同的开发、测试和生产环境中，应用通常需要访问到同一类型但实际部署位置可能不同的外部服务，如数据库、API网关、第三方服务等。通过Service，可以在每个环境中为这些外部服务定义一个内部一致的服务名，使得应用程序代码只需关注这个服务名而无需关心具体的访问地址或端口变化。
- 简化迁移与配置管理： 当项目从非容器化环境迁移到k8s集群时，或者在不同环境间进行部署迁移时，如果所有依赖的外部服务都使用了统一的服务发现机制（即通过Service来访问），那么只需要更改Service背后的endpoint配置即可，不需要修改大量应用的配置文件或代码逻辑，极大地降低了迁移成本和复杂度。
- 易维护性与扩展性： 由于所有的环境共享相同的访问服务命名约定，当需要更换或升级外部服务时，运维团队仅需更新对应的Service资源，而不是逐个通知每个应用去调整它们对远程服务的连接参数。这不仅简化了维护流程，也为未来的架构扩展提供了便利，例如可以方便地引入服务网格技术进行更精细的流量控制和治理。
2.Service代理外部服务配置文件
---
apiVersion: v1
kind: Service # 资源类型为Service
metadata:
name: nginx-svc # Service 名字
labels:
app: nginx # Service 自己本身的标签
spec:
selector: # 匹配哪些Pod会被该service代理
app: nginx-deploy
ports: # 端口映射
- port: 80 # service 自己的端口,在使用内网ip访问时使用
targetPort: 80 # 目标pod的端口
name: web # 为端口起个名字
type: NodePort # 随机启动一个端口(30000-32767),映射到ports中的端口,该端口是直接绑定在node上的,且集群中的每一个node都会绑定这个端口。
# 也可以用于将服务器暴露给外部访问,但是这种方式实际生产环境不推荐,效率较低,而且Service是四层负载。
---
3.Service访问外部服务原理图
4.Service反向代理外部域名配置文件
apiVersion: v1
kind: Service
metadata:
labels:
app: wolfcode-external-domain
name: wolfcode-external-domain
spec:
type: ExternalName
externameName: www.baidu.com
5.Service的常用类型
- ClusterIP
只能在集群内部使用,不配置类型的话默认就是ClusterIP
- ExternalName
返回定义的CNAME别名,可以配置为域名
- NodePort
会在所有安装了kube-proxy的节点都绑定一个端口,此端口可以代理至对应的pod,集群外部可以使用任意节点ip + NodePort的端口号访问到集群中对应Pod中的服务。
当类型设置为NodePort后,可以在ports配置中添加nodePort配置指定端口,需要在30000-32767范围内,如果不指定会随机指定端口
此类型可以实现外网映射,但是不推荐这样使用!!!
- LoadBalancer
使用云服务商(阿里云、腾讯云等)提供的负载均衡器服务
2.Ingress(负责南北流量的通信)
1.安装Ingress-nginx
- 安装helm
- 下载二进制文件
wget https://get.helm.sh/helm-v3.2.3-linux-amd64.tar.gz
- 解压
tar -zxvf <压缩包名>
- 将解压目录下的helm程序移动到usr/local/bin下
- 添加阿里云helm仓库
- 添加helm仓库
- 添加仓库
helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
- 查看仓库列表
helm repo list
- 搜索ingress-nginx
helm search repo ingress-nginx
- 下载包
helm pull ingress-nginx/ingress-nginx
- 配置参数
将下载好的安装包解压
tar xf ingress-nginx-xxx.tgz
解压后,进入解压完成的目录
cd ingress-nginx
修改values.yaml
镜像地址：修改为国内镜像
registry: registry.cn-hangzhou.aliyuncs.com
image: google_containers/nginx-ingress-controller
image: google_containers/kube-webhook-certgen
tag: v1.3.0
hostNetwork: true
dnsPolicy: ClusterFirstWithHostNet
修改部署配置的 kind: DaemonSet
nodeSelector:
ingress: “true” # 增加选择器，如果 node 上有 ingress=true 就部署
将 admissionWebhooks.enabled 修改为 false
将 service 中的 type 由 LoadBalancer 修改为 ClusterIP，如果服务器是云平台才用 LoadBalancer
- 创建Namespace
为ingress专门创建一个namespace
kubectl create ns ingress-nginx
- 安装Ingress
为需要部署ingress的节点上加标签(不建议在master上部署,默认有污点)
kubectl label node ingress=true
安装ingress-nginx
helm install ingress-nginx ./ingress-nginx -n ingress-nginx
2.Ingress基本使用
apiVersion: networking.k8s.io/v1
kind: ingress # 资源类型为Ingress
metadata:
name: nginx-ingress
annotations:
kubernetes.io/ingress.class:"nginx"
nginx.ingress.kubernetes.io/rewrite-target: /
spec:
rules: # ingress 规则配置,可以配置多个
- host: k8s.mytest.cn # 域名配置,可以使用通配符 *
http:
paths: # 相当于nginx的location配置,可以配置多个
- pathType: Prefix # 路径类型.按照路径类型进行匹配ImplementationSpecific需要指定IngressClass,具体匹配规则以IngressClass中的规则为准。Exact：精确匹配,URL需要与path完全匹配上,且区分大小写的。Prefix:以/作为分隔符来进行前缀匹配
backend:
service:
name: nginx-svc # 代理到哪个Service
port:
number: 80 # service的端口
path: /api # 等价于nginx中的location的路径前缀匹配
如果想配置多个域名或者多个路径匹配,分别增加多个host和多个pathType即可。
八、配置与存储
1.配置管理
1.ConfigMap
一般用于去存储Pod中应用所需的一些配置信息,或者环境变量,将配置与Pod分开,避免因为修改配置导致还需要重新构建镜像与容器。
1.ConfigMap的构建
最常用的ConfigMap构建方式有三种:
- 根据文件夹中的所有文件创建ConfigMap
kubectl create cm --from-file=<文件夹路径>
- 根据文件创建ConfigMap
kubectl create cm --from-file=<文件别名1(默认跟文件名相同)>=<文件的路径1> --from-file=<文件别名2(默认跟文件名相同)>=<文件的路径2>
- 根据自定义键值对创建ConfigMap
kubectl create cm --from-literal=key1=value1 --from-literal=key2=value2
2.ConfigMap的使用
1.映射CofigMap中的键值到容器中。
apiVersion: v1
kind: Pod
metadata:
name: test-env-pod
spec:
containers:
- name: env-test
images: alpine
command: ["/bin/sh","-c","env;sleep 3600"]
imagePullPolicy: IfNotPresent
env:
- name: JAVA_VM_OPTS
valueFrom:
configMapKeyRef:
name: test-env-config
key: JAVA_OPTS_TEST
- name: APP
valueFrom:
configMapKeyRef:
name: test-env-config
key: APP_NAME
restartPolicy: Never
2.映射ConfigMap中的文件到容器中。
apiVersion: v1
kind: Pod
metadata:
name: test-configfile-pod
spec:
containers:
- name: config-test
images: alpine
command: ["/bin/sh","-c","sleep 3600"]
imagePullPolicy: IfNotPresent
env:
- name: JAVA_VM_OPTS
valueFrom:
configMapKeyRef:
name: test-env-config
key: JAVA_OPTS_TEST
- name: APP
valueFrom:
configMapKeyRef:
name: test-env-config
key: APP_NAME
volumeMounts:
- name: db-config
mountPath: "/usr/local/mysql/conf"
readOnly: true
volumes:
- name: db-config
configMap:
name: test-dir-config
items:
- key: "db.properties"
path: "db.properties"
restartPolicy: Never
2.Secret
与ConfigMap类似,用于存储配置信息,但是主要用于存储敏感信息、需要加密的信息、Secret可以提供数据加密,解密功能。
在创建Secret时,要注意如果要加密的字符中,包含了有特殊字符,需要使用转义符转义,例如$转义后为$,也可以对待特殊字符使用单引号描述,这样就不需要转义。
1.Secret的构建
- 创建一个给Docker registry使用的secret
kubectl create secret docker-registry NAME --docker-username=user --docker-password=password --docker-email=email [–docker-server=string]
- 创建一个从公共文件、文件夹或者自定义值的secret
kubectl create secret generic NAME [–file-file=[key=]source] [–from-literal=key1=value1]
- 创建一个TLS的secret
kubectl create secret tls NAME --cert=公钥地址 --key=私钥地址
3.SubPath的使用
使用ConfigMap或Secret挂载到目录的时候,会将容器中源目录给覆盖掉,此时我们可能只想覆盖目录中的某一个文件,但是这样的操作会覆盖整个文件,因此需要使用到SubPath
配置方式:
- 定义volumes时需要增加items属性,配置key和path,且path的值不能从 / 开始
- 容器内的volumeMounts中增加subPath属性,该值与volumes中item.path的值相同。
……
containers:
……
volumeMounts:
- mountPath: /etc/nginx/nginx.conf # 挂载到哪里
name:config-volume # 使用哪个configmap 或 secret
subPath: /etc/nginx/nginx.conf # 与volumes[0].items.path相同
volumes:
- configMap:
name: nginx-conf # configMap 名字
items: # subPath 配置
key: nginx.conf # configMap中的文件名
path: etc/nginx/nginx.conf #subPath路径
4.配置的热更新
配置文件的热更新通常分为以下几种情况:
- 默认方式:会更新,更新周期是更新时间 + 缓存时间
- subPath:不会更新
- 变量形式:如果pod中的一个变量是从configmap或secret中得到,同样也是不会更新的。
对于subPath的方式,可以取消subPath的使用,将配置文件挂载到一个不存在的目录,避免目录的覆盖,然后再利用软连接的形式,将该文件链接到目标位置。如果目标位置文件原本就有文件,可以执行删除命令,将默认的文件删除即可。
1.通过edit命令直接修改configmap
kubectl edit cm
2.通过replace替换
kubectl create cm --from-file= --dry-run -o yaml | kubectl replace -f-
–dry-run参数的意思是打印yaml文件,但不会将该文件发送给apiserver,再结合 -o yaml输出yaml文件就可以得到一个配置好但是没有发给apiserver的文件,之后再结合replace监听控制台输出得到yaml数据即可实现替换。
5.不可变的Secret和ConfigMap
对于一些敏感服务的配置文件,在线上有时是不允许修改的,此时在配置configmap时可以设置immutable:true来禁止修改。
2.持久化存储
1.Volumes
1.HostPath
将节点上的文件或目录挂载到Pod上,此时该目录会变成持久化存储目录,即使Pod被删除后重启,也可以重新加载到该目录,该目录下的文件不会丢失。
apiVersion: v1
kind: Pod
metadata:
name:test-volumes-pd
spec:
containers:
- image: nginx:1.7.9
name: nginx-volume
volumeMounts:
- mountPath: /test-pd # 挂载到容器的哪个目录
name: test-volume # 挂载哪个volume
volumes:
- name: test-volume
hostPath:
path: /data # 节点中的目录
type: DirectoryOrCreate # 检查类型,在挂载前对挂载目录做什么检查操作,有多种选项,默认为空字符串,不做任何检查。
类型:
空字符串: 默认类型, 不做任何检查
DirectoryOrCreate: 如果给定的path不存在,就创建一个775的空目录
Directory: 这个目录必须存在
FileOrCreate: 如果给定的文件不存在,则创建一个空文件,权限为644
FIle:这个文件必须存在
Socket:UNIX套接字,必须存在
CharDevice:字符设备,必须存在
BlockDevice:块设备,必须存在
2.EmptyDir
EmptyDir主要用于一个Pod中不同的Container共享数据使用的,由于只是在Pod内部使用,因此与其他Volume比较大的区别是,当Pod如果被删除了,那么emptyDir也会被删除。
存储介质可以是任意类型,如SSD、磁盘或网络存储。可以将emptyDir.medium设置为Memory让k8s使用tmpfs(内存支持文件系统),速度比较快,但是重启tmpfs节点时,数据会被清除,且设置的大小会计入到Container的内存限制中。
apiVersion: v1
kind: Pod
metadata:
name: test-empty-pd
spec:
containers:
- image: alpine
name: nginx-empty-dir1
command: ["bin/sh","-c","sleep 3600;"]
volumeMounts:
- mountPath: /cache
name: cache-volume
- image: alpine
name: nginx-empty-dir2
command: ["bin/sh","-c","sleep 3600;"]
volumeMounts:
- mountPath: /opt
name: cache-volume
emptyDir:{}
2.NFS挂载
nfs卷能将NFS(网络文件系统)挂载到你的Pod中。不像emptyDir那样会在删除Pod的同时也被删除,nfs卷的内容在删除Pod时会被保存,卷只是被卸载。这意味着nfs卷可以被预先填充数据,并且这些数据可以在Pod之间共享。
1.安装nfs
- 安装nfs
yum install nfs-utils -y
- 启动nfs
systemctl start nfs-server
- 查看nfs版本
cat /proc/fs/nfsd/versions
- 创建共享目录
mkdir -p <你自己的共享目录>
- 设置共享目录export
vim /export
<你自己的共享目录> <网段>(rw,sync,no_subtree_check,no_root_squash)
- 重新加载
exportfs -f
systemctl reload nfs-server
- 到其他节点安装nfs-utils并加载测试
mkdir -p <你自己的测试目录>
mount -t nfs :<要挂载的目录>
2…配置文件
apiVersion: v1
kind: Pod
metadata:
name: test-pd
spec:
containers:
- image: nginx
name: test-container
volumeMounts:
- mountPath: <将挂载的文件存放的地址>
name: test-volume
volumes:
- name: test-volume
nfs:
server: <ip地址> # 网络存储服务地址
path: <挂载的地址> # 网络存储路径
readOnly: true # 是否只读
3.PV与PVC
1.生命周期
- 构建
- 静态构建
集群管理员创建若干PV卷,这些卷对象带有真实存储的细节信息,并且对集群用户可用(可见)。PV卷对象存在于Kubernetes API中,可供用户消费(使用)。
- 动态构建
如果集群中已经有的PV无法满足PVC的需求,那么集群会根据PVC自动构建一个PV,该操作是通过StorageClass实现的。
- 绑定
当用户创建一个PVC对象后,主节点会监测新的PVC对象,并且寻找与之匹配的PV卷,找到PV卷后将二者绑定在一起。
如果找不到对应的PV,则需要看PVC是否设置StorageClass来决定是否动态创建PV,若没有配置,PVC就会一直处于未绑定状态,直到有与之匹配的PV后才会申领绑定关系。
- 使用
Pod将PVC当作存储卷来使用,集群会通过PVC找到绑定的PV,并为Pod挂载该卷。
Pod一旦使用PVC绑定PV后,为了保护数据,避免数据丢失问题,PV对象会收到保护,在系统中无法删除。
- 回收策略
- 保留(Retain)
- 删除(Delete)
- 回收(Recycle)
2.PV
1.状态
Available:空闲,未被绑定。
Bound:已经被PVC绑定。
Released:PVC被删除,资源已回收,但是PV未被重新使用。
Failed:自动回收失败。
2.配置文件
apiVersion: v1
kind: persistentVolume
metadata:
name: pv0001
spac:
capacity:
storage: 5Gi # pv的容量
volumeMode: Filesystem # 存储类型为文件系统
accessModes: # 访问模式: ReadWriteMany、ReadWriteOnce、ReadOnlyMany
- ReadWriteMany # 可被单节点读写
persistentVolumeReclaimPolicy: Retain # 回收策略
storageClassName: slow # 创建PV的存储类名,需要与pvc的相同
mountOptions: # 加载配置
- hard
- nfsvers=4.1
nfs:
path: /home/nfs/rw/test-pv # 存储路径
server: <你的ip地址> # nfs服务地址
3.PVC
配置文件
pod绑定pvc
containers:
......
volumeMounts:
- mountPath: /tmp/pvc
name: nfs-pvc-test
volumes:
- name: nfs-pvc-test
persistentVolumeClaim:
claimName: nfs-pvc # pvc 的名称
-----------------------------------------
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: nfs-pvc
spec:
accessModes:
- ReadWriteMany # 权限需要与对应的 pv 相同
volumeMode: Filesystem
resources:
requests:
storage: 5Gi # 资源可以小于 pv 的，但是不能大于，如果大于就会匹配不到 pv
storageClassName: slow # 名字需要与对应的 pv 相同
# selector: # 使用选择器选择对应的 pv
# matchLabels:
# release: "stable"
# matchExpressions:
# - {key: environment, operator: In, values: [dev]}
4.StorageClass
k8s中提供了一套自动创建pv的机制,就是基于StorageClass进行的,通过StorageClass可以实现仅仅配置pvc,然后交由StorageClass根据pvc的需求动态创建pv。
1.制备器(Provisioner)
每个StorageClass都有一个制备器(Provisioner),用来决定使用哪个卷插件制备pv。
2.NFS动态制备案例
1.nfs-provisioner
apiVersion: apps/v1
kind: Deployment
metadata:
name: nfs-client-provisioner
namespace: kube-system
labels:
app: nfs-client-provisioner
spec:
replicas: 1
strategy:
type: Recreate
selector:
matchLabels:
app: nfs-client-provisioner
template:
metadata:
labels:
app: nfs-client-provisioner
spec:
serviceAccountName: nfs-client-provisioner
containers:
- name: nfs-client-provisioner
image: registry.cn-beijing.aliyuncs.com/pylixm/nfs-subdir-external-provisioner:v4.0.0
volumeMounts:
- name: nfs-client-root
mountPath: /persistentvolumes
env:
- name: PROVISIONER_NAME
value: fuseim.pri/ifs
- name: NFS_SERVER
value: <ip地址>
- name: NFS_PATH
value: /home/nfs/rw
volumes:
- name: nfs-client-root
nfs:
server: <ip地址>
path: /home/nfs/rw
2.StorageClass配置
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: managed-nfs-storage
namespace: kube-system
provisioner: fuseim.pri/ifs # 外部制备器提供者,编写为提供者的名称
parameters:
archiveOnDelete: "false" # 是否存档,false表示不存档,会删除oldPath下面的数据,true表示存档,会重命名路径
reclaimPolicy: Retain # 回收策略,默认为Delete 可以配置为Retain。
volumeBindingMode: Immediate # 默认为Immediate,表示创建PVC立即进行绑定,只有azuredisk和AWSelasticblockstore支持其他值。
3.RBAC配置
apiVersion: v1
kind: ServiceAccount
metadata:
name: nfs-client-provisioner
namespace: kube-system
---
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: nfs-client-provisioner-runner
namespace: kube-system
rules:
- apiGroups: [""]
resources: ["persistentvolumes"]
verbs: ["get", "list", "watch", "create", "delete"]
- apiGroups: [""]
resources: ["persistentvolumeclaims"]
verbs: ["get", "list", "watch", "update"]
- apiGroups: ["storage.k8s.io"]
resources: ["storageclasses"]
verbs: ["get", "list", "watch"]
- apiGroups: [""]
resources: ["events"]
verbs: ["create", "update", "patch"]
---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: run-nfs-client-provisioner
namespace: kube-system
subjects:
- kind: ServiceAccount
name: nfs-client-provisioner
namespace: kube-system
roleRef:
kind: ClusterRole
name: nfs-client-provisioner-runner
apiGroup: rbac.authorization.k8s.io
---
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: leader-locking-nfs-client-provisioner
namespace: kube-system
rules:
- apiGroups: [""]
resources: ["endpoints"]
verbs: ["get", "list", "watch", "create", "update", "patch"]
---
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: leader-locking-nfs-client-provisioner
namespace: kube-system
subjects:
- kind: ServiceAccount
name: nfs-client-provisioner
namespace: kube-system
roleRef:
kind: Role
name: leader-locking-nfs-client-provisioner
apiGroup: rbac.authorization.k8s.io
4.PVC处于Pending状态的解决方案
- 配置SelfLink
修改apiserver配置文件
vim /etc/kubernetes/manifests/kube-apiserver.yaml
spec:
containers:
- command:
- kube-apiserver
- --feature-gates=RemoveSelfLink=false # 新增该行
......
修改后重新应用该配置
kubectl apply -f /etc/kubernetes/manifests/kube-apiserver.yaml
- 更换不需要SelfLink的provisioner
将provisioner修改为如下镜像之一即可
gcr.io/k8s-staging-sig-storage/nfs-subdir-external-provisioner:v4.0.0
registry.cn-beijing.aliyuncs.com/pylixm/nfs-subdir-external-provisioner:v4.0.0
5.PVC测试配置
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: auto-pv-test-pvc
spec:
accessModes:
- ReadWriteMany
resources:
requests:
storage: 300Mi
storageClassName: managed-nfs-storage
九、高级调度
1.CronJob计划任务
1.cron表达式
# ┌───────────── 分钟 (0 - 59)
# │ ┌───────────── 小时 (0 - 23)
# │ │ ┌───────────── 月的某天 (1 - 31)
# │ │ │ ┌───────────── 月份 (1 - 12)
# │ │ │ │ ┌───────────── 周的某天 (0 - 6)（周日到周一；在某些系统上，7 也是星期日）
# │ │ │ │ │ 或者是 sun，mon，tue，web，thu，fri，sat
# │ │ │ │ │
# │ │ │ │ │
# * * * * *
2.配置文件
apiVersion: batch/v1
kind: CronJob
metadata:
name: cron-job-test
spec:
concurrencyPolicy: Allow # 并发调度策略：Allow 允许并发调度，Forbid：不允许并发执行，Replace：如果之前的任务还没执行完，就直接执行新的，放弃上一个任务
failedJobsHistoryLimit: 1 # 保留多少个失败的任务
successfulJobsHistoryLimit: 3 # 保留多少个成功的任务
suspend: false # 是否挂起任务,若为true则该任务不会执行
# startingDeadlineSeconds: 30 # 间隔多长时间检测失败的任务并重新执行，时间不能小于 10
schedule: "* * * * *"
jobTemplate:
spec:
template:
spec:
containers:
- name: busybox
image: busybox:1.28
imagePolicy: IfNotPresent
command:
- /bin/sh
- -c
- date; echo Hello from the Kubernetes cluster
restartPolicy: OnFailure
2.初始化容器InitContainer
在真正的容器启动之前,先启动initContainer,在初始化容器中完成真实容器所需要的初始化操作,完成后再启动真实的容器。
相对于 postStart 来说，首先 InitController 能够保证一定在 EntryPoint 之前执行，而 postStart 不能，其次 postStart 更适合去执行一些命令操作，而 InitController 实际就是一个容器，可以在其他基础容器环境下执行更复杂的初始化功能。
在pod创建的模板中配置initContainers参数:
spec:
container:
........
initContainers:
- image: nginx
imagePullPolicy: IfNotPresent
command: ["sh", "-c", "echo 'inited;' >> ~/.init"]
name: init-test
3.污点和容忍
1.污点(Taint)
污点:是标注在节点(Node)上的,当我们在一个节点上打上污点以后k8s会认为尽量不要将pod调度到该节点上,除非该pod上面表示可以容忍该污点,且一个节点可以打多个污点,此时 则需要pod容忍所有污点才会被调度到该节点。
# 为节点打上污点
kubectl taint node k8s-matser key=value:NoSchedule
# 移除污点
kubectl taint node k8s-master key=value:NoSchedule-
#查看污点
kubectl describe no k8s-master
污点的影响:
NoSchedule:不能容忍的pod不能被调度到该节点上,但是已经存在的节点不会被驱逐。
NoExecute:不能容忍的节点会被立即清除,能容忍且没有配置tolerationSeconds属性,则可以一直运行,设置了tolerationSeconds:3600属性,则该pod还能继续在该节点运行3600秒。
2.容忍(Toleration)
容忍:是标注在pod上的,当pod被调度时,如果没有配置容忍,则该pod不会被调度到有污点的节点上,只有该pod上标注了满足某个节点的所有污点,则会被调度到这些节点。
#pod的spec下面配置容忍
tolerations:
- key: "污点的key"
value: "污点的value"
offect: "NoSchedule" # 污点产生的影响
operator: "Equal" # 表示value与污点的value要相等,也可以设置为Exists表示存在key即可,此时可以不用配置value
4.亲和力(Affinity)
1.NodeAffinity
1.RequiredDuringSchedulingIgnoredDuringExecution(硬亲和力)
硬亲和力:即支持必须部署在指定节点上,也支持必须不部署在指定节点上。
2.PreferredDuringSchedulingIgnoredDuringExecution(软亲和力)
软亲和力:尽量部署在满足条件的节点上,或尽量不要部署在被匹配的节点上。
3.匹配类型
1.in
部署在满足条件的节点上
2.Notin
匹配不在条件中的节点，实现节点反亲和性
3.Exists
只要存在 key 名字就可以，不关心值是什么
4.DoesNotExist
匹配指定 key 名不存在的节点，实现节点反亲和性
5.Gt
value 为数值，且节点上的值小于指定的条件
6.Lt
value 为数值，且节点上的值大于指定条件
4.模板文件
apiVersion: v1
kind: Pod
metadata:
name: with-node-affinity
spec:
affinity: # 亲和力配置
nodeAffinity: # 节点亲和力
requiredDuringSchedulingIgnoredDuringExecution: # 节点必须匹配下方配置
nodeSelectorTerms: # 选择器
- matchExpressions: # 匹配表达式
- key: topology.kubernetes.io/zone # 匹配 label 的 key
operator: In # 匹配方式，只要匹配成功下方的一个 value 即可
values:
- antarctica-east1 # 匹配的 value
- antarctica-west1 # 匹配的 value
preferredDuringSchedulingIgnoredDuringExecution: # 节点尽量匹配下方配置
- weight: 1 # 权重[1,100]，按照匹配规则对所有节点累加权重，最终之和会加入优先级评分，优先级越高被调度的可能性越高
preference:
matchExpressions: # 匹配表达式
- key: another-node-label-key # label 的 key
operator: In # 匹配方式，满足一个即可
values:
- another-node-label-value # 匹配的 value
- weight: 20
......
containers:
- name: with-node-affinity
image: pause:2.0
2.Pod
1.PodAffinity
2.PodAntiAffinity
3.模板文件
apiVersion: v1
kind: Pod
metadata:
name: with-pod-affinity
spec:
affinity: # 亲和力配置
podAffinity: # pod 亲和力配置
requiredDuringSchedulingIgnoredDuringExecution: # 当前 pod 必须匹配到对应条件 pod 所在的 node 上
- labelSelector: # 标签选择器
matchExpressions: # 匹配表达式
- key: security # 匹配的 key
operator: In # 匹配方式
values: # 匹配其中的一个 value
- S1
topologyKey: topology.kubernetes.io/zone
podAntiAffinity: # pod 反亲和力配置
preferredDuringSchedulingIgnoredDuringExecution: # 尽量不要将当前节点部署到匹配下列参数的 pod 所在的 node 上
- weight: 100 # 权重
podAffinityTerm: # pod 亲和力配置条件
labelSelector: # 标签选择器
matchExpressions: # 匹配表达式
- key: security # 匹配的 key
operator: In # 匹配的方式
values:
- S2 # 匹配的 value
topologyKey: topology.kubernetes.io/zone
containers:
- name: with-pod-affinity
image: pause:2.0
十、身份认证与权限
1.认证
所有 Kubernetes 集群有两类用户：由 Kubernetes 管理的Service Accounts （服务账户）和（Users Accounts） 普通账户。
普通账户是假定被外部或独立服务管理的，由管理员分配 keys，用户像使用 Keystone 或 google 账号一样，被存储在包含 usernames 和 passwords 的 list 的文件里。
需要注意：在 Kubernetes 中不能通过 API 调用将普通用户添加到集群中。
- 普通帐户是针对（人）用户的，服务账户针对 Pod 进程。
- 普通帐户是全局性。在集群所有namespaces中，名称具有惟一性。
- 通常，群集的普通帐户可以与企业数据库同步，新的普通帐户创建需要特殊权限。服务账户创建目的是更轻量化，允许集群用户为特定任务创建服务账户。
- 普通帐户和服务账户的审核注意事项不同。
- 对于复杂系统的配置包，可以包括对该系统的各种组件的服务账户的定义。
2.授权(RBAC)
1.Role
代表一个角色，会包含一组权限，没有拒绝规则，只是附加允许。它是 Namespace 级别的资源，只能作用与 Namespace 之内。
查看已有的角色信息
kubectl get role -n ingress-nginx -oyaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
labels:
app.kubernetes.io/name: ingress-nginx
app.kubernetes.io/part-of: ingress-nginx
name: nginx-ingress
namespace: ingress-nginx
roles:
- apiGroups:
- ""
resources:
- configmaps
- pods
- secrets
- namespaces
verbs:
- get
- apiGroups:
- ""
resourceNames:
- ingress-controller-label-nginx
resources:
- configmaps
verbs:
- get
- update
- apiGroups:
- ""
resources:
- configmaps
verbs:
- create
2.ClusterRole
功能与 Role 一样，区别是资源类型为集群类型，而 Role 只在 Namespace
查看某个集群角色的信息
kubectl get clusterrole view -oyaml
3.RoleBinding
Role 或 ClusterRole 只是用于制定权限集合，具体作用与什么对象上，需要使用 RoleBinding 来进行绑定。
作用于 Namespace 内，可以将 Role 或 ClusterRole 绑定到 User、Group、Service Account 上。
查看 rolebinding 信息
kubectl get rolebinding --all-namespaces
查看指定 rolebinding 的配置信息
kubectl get rolebinding <role_binding_name> --all-namespaces -oyaml
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
......
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name nginx-ingress-role
subjects:
- kind: ServiceAccount
name: nginx-ingress-serviceaccount
namespace: ingress-nginx
4.ClusterRoleBinding
与 RoleBinding 相同，但是作用于集群之上，可以绑定到该集群下的任意 User、Group 或 Service Account
更新时间:2024.02.19,笔记内容持续更新中~,
🐧:3495879676
欢迎各位大牛前来指导,同样欢迎各位小白一起内卷~
491
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
