kubernetes使用（1.25）
内核是AMD、ARM、
$ arch
uname -a
注：x86_64,x64,AMD64基本上是同一个东西
K8S 核心概念
Kubernetes有很多核心概念，我们先看下几个核心的概念。其他概念可以看一下我的安装文档
Deployment
Deployment负责创建和更新应用程序的实例。创建Deployment后，Kubernetes Master 将应用程序实例调度到集群中的各个节点上。如果托管实例的节点关闭或被删除，Deployment控制器会将该实例替换为群集中另一个节点上的实例。这提供了一种自我修复机制来解决机器故障维护问题。
Pod
Pod相当于逻辑主机的概念，负责托管应用实例。包括一个或多个应用程序容器（如 Docker），以及这些容器的一些共享资源（共享存储、网络、运行信息等）。
Service
Service是一个抽象层，它定义了一组Pod的逻辑集，并为这些Pod支持外部流量暴露、负载均衡和服务发现。
尽管每个Pod 都有一个唯一的IP地址，但是如果没有Service，这些IP不会暴露在群集外部。Service允许您的应用程序接收流量。Service也可以用在ServiceSpec标记type的方式暴露，type类型如下：
- ClusterIP（默认）：在集群的内部IP上公开Service。这种类型使得Service只能从集群内访问。
- NodePort：使用NAT在集群中每个选定Node的相同端口上公开Service。使用 : 从集群外部访问Service。是ClusterIP的超集。
- LoadBalancer：在当前云中创建一个外部负载均衡器(如果支持的话)，并为Service分配一个固定的外部IP。是NodePort的超集。
- ExternalName：通过返回带有该名称的CNAME记录，使用任意名称（由spec中的externalName指定）公开Service。不使用代理。
NameSpace
NameSpace用于对资源进行分类，上述的service,deployment,pod在kubernetes中都是资源的一种，以安装的kubernets-dashboard为例，会创建一个kubernets-dashboard的命名空间，空间中包含了其相关的service,deployment,pod等信息
kubectl命令使用
kubectl是apiserver的客户端工具，工作在命令行下，能够连接apiserver实现各种增删改查等操作 kubectl官方使用文档：https://kubernetes.io/zh/docs/reference/kubectl/overview/
https://kubectl.docs.kubernetes.io/references/kubectl/annotation/
https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands
资源
kubeenetes中service,deployment,pod等都被认作是资源，很多命令会涉及到资源的简写(当然也可以使用全称)，例如service 会被简写为svc
这是官方的对照文档
https://kubernetes.io/zh-cn/docs/reference/kubectl/#resource-types
常用的资源简写
资源包括pod (po)-容器， service (svc)-服务，deployment(deploy)-部署， nodes（no）-节点，serviceaccounts（sa) -用户
namespace
NameSpace用于对资源进行分类,我们所有命令执行都是在默认的default命名空间上操作
如果要操作特定命名空间的资源，使用
-n <命名空间名称>
查看帮助
所有的命令都可以添加 -h参数查看帮助，例如
kubectl get -h
kubectl apply -h
kubectl run
对容器pod层面的操作，当然这似乎没什么用，因为端口和ip都是容器内部的网络，没有映射到外部，似乎可以添加hostPort映射到宿主机端口
# 创建一个部署了nginx的容器
kubectl run nginx2 --image=nginx
# 创建一个部署了nginx的容器 并且暴露端口31000
kubectl run nginx3 --image=nginx --port=31000
kubectl create
创建命令，可以创建 部署、账号，登录令牌，命名空间，角色等等资源，据题查看官方文档
# 应用编排文件
kubectl create -f **.yaml
# 创建一次部署
kubectl create deployment nginx --image=nginx
# 创建一个 kubernetes-dashboard命名空间的账号账号
kubectl create serviceaccount admin -n kubernetes-dashboard
# 创建一个有效的登录令牌
kubectl create token admin-user --duration 14400m -n kubernetes-dashboard
kubectl expose
# 创建一个service,内部端口是89,--type=NodePort表示映射到随机的宿主机端口，似乎没有指定宿主机端口的参数
# 执行这条命令前需要有对应的deployment
kubectl expose deployment nginx --port=80 --type=NodePort
kubectl get
用于查看kubernetes的资源详情
# 获取集群的节点
kubectl get nodes
kubectl get no
# 获取指定命名空间的pod列表
kubectl get pods -n kubernetes-dashboard
# 支持展示多种资源列表
kubectl get pod,svc,deploy -o wide
# 展示多有命名空间下的这些资源
kubectl get pod,svc,deploy --all-namespaces
# 获取集群角色列表
kubectl get clusterroles
# 资源pod的配置以yaml格式进行展示
kubectl get pod nginx‐deploy‐7db697dfbd‐2qh7v ‐o yaml
kubectl exec
在容器中执行命令。
# 查看容器环境变量
kubectl exec nginx-76d6c9b8c-lznd5 -- env
# 列出容器内部根目录文件列表
kubectl exec nginx-76d6c9b8c-lznd5 -- ls
# 进入容器内部， exit退出容器
kubectl exec -it nginx-76d6c9b8c-lznd5 -- sh
kubectl exec -it my-mysql-c6bbfd47c -- sh
kubectl delete
用于删除资源
# 以下两条命令都是删除pod, 需要注意的是，deployment 生成的pod的删除需要删除对应的deployment,否则kubeenetes会再次帮我们创建对应容器
kubectl delete pod/nginx2
kubectl delete pod nginx2
# 删除服务
kubectl delete svc nginx
# 删除部署
kubectl delete deploy nginx
# 删除集群角色绑定关系
kubectl delete clusterrolebindings login-on-dashboard-with-cluster-admin
# 强制删除
--force --grace-period=0
kubectl scale
指定副本的个数，deployment就变成了三个了，用于扩容和缩容
kubectl scale --replicas=3 deployment nginx
kubectl describe
查看资源的详细信息
# 当前角色的详情
kubectl describe clusterroles cluster-admin
# 查看某个pod的详细信息，配置末尾包含events，可以用来排查pod启动异常的原因
kubectl describe pod/nginx-76d6c9b8c-lznd5
# 查看某个部署的详情
kubectl describe deployment nginx
kubectl logs
# 从 Pod <pod-name> 开始流式传输日志。这类似于 'tail -f' Linux 命令。
kubectl logs -f <pod-name>
# 查看api-server 日志
kubectl logs -f -n kube-system kube-apiserver-k8s-master
kubectl set
修改资源的配置和环境变量
# 修改某个部署使用的镜像版本
kubectl set image deployment my‐tomcat tomcat=tomcat:8.0.41‐jre8‐alpine
# 有如下选项
Available Commands:
env Update environment variables on a pod template
image Update the image of a pod template
resources Update resource requests/limits on objects with pod templates
selector Set the selector on a resource
serviceaccount Update the service account of a resource
subject Update the user, group, or service account in a role binding or cluster role binding
版本回滚：
查看历史版本
# 查看某个部署的历史版本
kubectl rollout history deploy nginx
回滚到上一个版本
kubectl rollout undo deployment my-tomcat #--to-revision 参数可以指定回退的版本
clusterrole 和 role
定义的针对资源的访问权限，role针对某一个nameSpace, clusterrole 针对整个集群
标签的使用
通过给资源添加Label，可以方便地管理资源（如Deployment、Pod、Service等）。
查看Deployment中所包含的Label
通过标签查询pod
kubectl get pods -l app=nginx
通过标签查询service
kubectl get svc -l app=nginx
kubectl get services -l app=nginx
给Pod添加Label
kubectl label pod/nginx-76d6c9b8c-lznd5 version=v1
查看Pod的详细信息，可以查看Label信息：
kubectl describe pod/nginx-76d6c9b8c-lznd5
通过标签删除服务
kubectl delete service -l app=test-service
总结
kubectl create deployment #创建一个deployment来管理创建的容器
kubectl get #显示一个或多个资源，可以使用标签过滤，默认查看当前名称空间的资源
kubectl expose #将一个资源暴露为一个新的kubernetes的service资源，资源包括pod (po)， service (svc)， replicationcontroller (rc)，deployment(deploy)， replicaset (rs)
kubectl describe #显示特定资源或资源组的详细信息
kubectl scale #可以对Deployment, ReplicaSet, Replication Controller, 或者StatefulSet设置新的值，可以指定一个或多个先决条件
kubectl set #更改现有的应用程序资源
kubectl rollout #资源回滚管理
Deployment更新策略
Deployment控制器支持两种更新策略——滚动更新（rollingUpdate）和重建更新（Recreate）。这两种更新策略差异如下：
1、重建更新。
重建更新指的是先全部删除已有的Pod对象，然后创建新版本的Pod对象。这种更新方式，最大的弊端是在更新过程中，运行的服务要有一定时间的中断。但是有点在于这种方式的更新，没有出现新、老版本的Pod共存，并且共同提供服务的阶段。但是，相比于其有点，其缺点尤为明显。因此，在生产环境中，我们几乎很少使用重建更新这一种更新策略。使用的大多是滚动更新。
2、滚动更新。
在删除一部分老旧版本的Pod的同时，创建新版本的Pod资源。这种更新方式的好处在于，可以维持服务的正常提供，服务运行不会中断。但是这样做的问题在于，会存在一段时间，新版本的Pod和旧版本的Pod同时提供服务，客户端接收的服务可能来源于老版本的Pod，也可能来源于新版本的Pod，这将会导致服务上的差异性。事实上，相对比与其缺点，滚动更新策略的优点更加明显，即业务连续不中断，并且新老版本Pod并存可以使得提前检验新版本Pod的可用性，如果发现更新后服务出现问题，更是可以提前发现，提前处理。同时，滚动更新的缺点也可以通过分区域更新等方式来进行解决。因此，我们最常用的更新策略就是滚动更新，并且滚动更新也是Deployment控制器的默认更新策略。
NodePort和LoadBalancer
参考 ：https://blog.csdn.net/qq_41337034/article/details/109517493
containerPort、hostPort和service的port、targetPort、nodePort
参考 ：https://blog.csdn.net/DLWH_HWLD/article/details/125040980
资源清单
之前我们直接用命令创建deployment，pod，service这些资源，其实在k8s中，我们一般都会使用yaml格式的文件来创建符合我们预期期望的资源，这样的yaml文件我们一般称为资源清单
了解docker compose的 ,可以理解为资源的编排文件
资源清单yaml的格式
apiVersion: group/apiversion # 如果没有给定group名称，那么默认为croe，可以使用kubectl api-versions 获取当前k8s版本上所有的apiVersion版本信息(每个版本可能不同)
kind: #资源类别
metadata： #资源元数据
name
namespace #k8s自身的namespace
lables
annotations #主要目的是方便用户阅读查找
spec:期望的状态（disired state）
status：当前状态，本字段由kubernetes自身维护，用户不能去定义
#配置清单主要有五个一级字段，其中status字段用户不能定义，由k8s自身维护
我们可以使用命令应用资源清单
# create仅仅支持创建，二次执行会报错，apply会感知到资源清单的变化，然后对资源进行调整
kubectl apply -f calico.yaml
kubectl create -f calico.yaml
资源清单示例
编排文件生成网址：https://www.kubebiz.com/
官网资源文件属性：https://kubernetes.io/zh-cn/docs/reference/kubernetes-api/
# 创建一个namespace
apiVersion: v1
kind: Namespace
metadata:
name: my-nginx
---
# 在my-space 下创建一个deployment
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-nginx
namespace: my-space
spec: selector:
replicas: 1
# 部署的选择器，可能是用于定位部署后的pod,必须和template一致
selector:
matchLabels:
run: my-nginx
# 用于描述可能被创建的容器
template:
metadata:
labels:
run: my-nginx
# 容器的配置
spec:
containers:
- name: my-nginx
image: nginx
ports:
- containerPort: 80
单个配置的解释
# 如果需要查看某个配置的解释
kubectl explain Deployment.spec
Secret
Secret是用于保存单独的机密数据，以key：value的方式存储，其中机密数据可以是用户名密码等数据，secret定义好之后可以被其他资源文件引用，使用 Secret 意味着你不需要在应用程序代码中包含机密数据。
大白话：就是密码不直接和应用程序放在一起，而是单独放置，然后部署的时候可以对单独存放的密码配置进行引用，
官方文档：https://kubernetes.io/zh-cn/docs/concepts/configuration/secret/
K8S 高级特性
K8S中还有一些高级特性有必要学习下，比如弹性扩缩应用(见上文)、滚动更新(见上文)、配置管理、存储卷、网关路由等。
在学习这些高级特性之前有必要再看几个K8S的核心概念：
ReplicaSet
ReplicaSet确保任何时间都有指定数量的Pod副本在运行。通常用来保证给定数量的、完全相同的Pod的可用性。建议使用Deployment来管理ReplicaSet，而不是直接使用ReplicaSet。
ConfigMap
ConfigMap是一种API对象，用来将非机密性的数据保存到键值对中。使用时，Pod可以将其用作环境变量、命令行参数或者存储卷中的配置文件。使用ConfigMap可以将你的配置数据和应用程序代码分开。
官方文档 ：https://kubernetes.io/zh-cn/docs/concepts/configuration/configmap/
示例
apiVersion: v1
kind: ConfigMap
metadata:
name: game-demo
data:
# 类属性键；每一个键都映射到一个简单的值
player_initial_lives: "3"
ui_properties_file_name: "user-interface.properties"
# 类文件键
game.properties: |
enemy.types=aliens,monsters
player.maximum-lives=5
user-interface.properties: |
color.good=purple
color.bad=yellow
allow.textmode=true
示例使用
volumes代表容器外部配置，这里是configmap配置，volumeMounts标识容器内部配置，两个结合就是将容器外部的配置映射到容器内部
还有就是在环境变量中引用了
apiVersion: v1
kind: Pod
metadata:
name: configmap-demo-pod
spec:
containers:
- name: demo
image: alpine
command: ["sleep", "3600"]
env:
# 定义环境变量
- name: PLAYER_INITIAL_LIVES # 请注意这里和 ConfigMap 中的键名是不一样的
valueFrom:
configMapKeyRef:
name: game-demo # 这个值来自 ConfigMap
key: player_initial_lives # 需要取值的键
- name: UI_PROPERTIES_FILE_NAME
valueFrom:
configMapKeyRef:
name: game-demo
key: ui_properties_file_name
volumeMounts:
- name: config
mountPath: "/config"
readOnly: true
volumes:
# 你可以在 Pod 级别设置卷，然后将其挂载到 Pod 内的容器中
- name: config
configMap:
# 提供你想要挂载的 ConfigMap 的名字
name: game-demo
# 来自 ConfigMap 的一组键，将被创建为文件
items:
- key: "game.properties"
path: "game.properties"
- key: "user-interface.properties"
path: "user-interface.properties"
Volume
官方文档 ：https://kubernetes.io/zh-cn/docs/concepts/storage/volumes/
Volume指的是存储卷，包含可被Pod中容器访问的数据目录。容器中的文件在磁盘上是临时存放的，当容器崩溃时文件会丢失，同时无法在多个Pod中共享文件，通过使用存储卷可以解决这两个问题。
常用的存储卷有如下几种：
- configMap：configMap卷提供了向Pod注入配置数据的方法。ConfigMap对象中存储的数据可以被configMap类型的卷引用，然后被Pod中运行的容器化应用使用。
- emptyDir：emptyDir卷可用于存储缓存数据。当Pod分派到某个Node上时，emptyDir卷会被创建，并且Pod在该节点上运行期间，卷一直存在。当Pod被从节点上删除时emptyDir卷中的数据也会被永久删除。
- hostPath：hostPath卷能将主机节点文件系统上的文件或目录挂载到你的Pod中。在Minikube中的主机指的是Minikube所在虚拟机。
- local：local卷所代表的是某个被挂载的本地存储设备，例如磁盘、分区或者目录。local卷只能用作静态创建的持久卷，尚不支持动态配置。
- nfs：nfs卷能将NFS（网络文件系统）挂载到你的Pod中。
- persistentVolumeClaim：persistentVolumeClaim卷用来将持久卷（PersistentVolume）挂载到Pod中。持久卷（PV）是集群中的一块存储，可以由管理员事先供应，或者使用存储类（Storage Class）来动态供应，持久卷是集群资源类似于节点。
持久卷概念
持久卷（PersistentVolume，PV） 是集群中的一块存储，可以由管理员事先制备， 或者使用存储类（Storage Class）来动态制备。 持久卷是集群资源，就像节点也是集群资源一样。PV 持久卷和普通的 Volume 一样， 也是使用卷插件来实现的，只是它们拥有独立于任何使用 PV 的 Pod 的生命周期。 此 API 对象中记述了存储的实现细节，无论其背后是 NFS、iSCSI 还是特定于云平台的存储系统。
持久卷申领（PersistentVolumeClaim，PVC） 表达的是用户对存储的请求。概念上与 Pod 类似。 Pod 会耗用节点资源，而 PVC 申领会耗用 PV 资源。Pod 可以请求特定数量的资源（CPU 和内存）；同样 PVC 申领也可以请求特定的大小和访问模式 （例如，可以要求 PV 卷能够以 ReadWriteOnce、ReadOnlyMany 或 ReadWriteMany 模式之一来挂载，参见访问模式）。
官方示例：https://kubernetes.io/zh-cn/docs/tasks/configure-pod-container/configure-persistent-volume-storage/
pv和pvc使用
pv负责申请一块存储区域，可以指定访问模式和容量，pvc根据storageClassName去和pv进行绑定（动态绑定），应该是一对一的关系，pod中通过pvc来申请外部的存储区域。一个pvc可以被多个pod使用，取决于pvc的访问模式。
pv创建
apiVersion: v1
kind: PersistentVolume #资源类型 pv
metadata:
name: task-pv-volume
labels:
type: local
spec:
storageClassName: manual # PersistentVolume 中定义了 StorageClass 的名称为 manual。 它将用于将 PersistentVolumeClaim 的请求绑定到此 PersistentVolume。StorageClass可以不构建
capacity:
storage: 10Gi # 限定卷容量的大小
accessModes:
- ReadWriteOnce # 卷可以被单个节点以读写方式安装
hostPath: # 卷类型
path: "/mnt/data" # 宿主机目录
# 获取pv信息
kubectl get pv task-pv-volume
pvc创建
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: task-pv-claim
spec:
storageClassName: manual
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 3Gi
# selector: # 静态绑定pv
# matchLabels:
# name: pv1
pod中使用pvc
apiVersion: v1
kind: Pod
metadata:
name: task-pv-pod
spec:
volumes:
- name: task-pv-storage
persistentVolumeClaim: # 这里通过pvc的名称去使用对应的pvc
claimName: task-pv-claim
containers:
- name: task-pv-container
image: nginx
ports:
- containerPort: 80
name: "http-server"
volumeMounts:
- mountPath: "/usr/share/nginx/html"
name: task-pv-storage
容量
一般而言，每个 PV 卷都有确定的存储容量。 容量属性是使用 PV 对象的 capacity 属性来设置的。 参考词汇表中的量纲（Quantity） 词条，了解 capacity 字段可以接受的单位。
目前，存储大小是可以设置和请求的唯一资源。 未来可能会包含 IOPS、吞吐量等属性。
访问模式
PersistentVolume 卷可以用资源提供者所支持的任何方式挂载到宿主系统上。 如下表所示，提供者（驱动）的能力不同，每个 PV 卷的访问模式都会设置为对应卷所支持的模式值。 例如，NFS 可以支持多个读写客户，但是某个特定的 NFS PV 卷可能在服务器上以只读的方式导出。 每个 PV 卷都会获得自身的访问模式集合，描述的是特定 PV 卷的能力。
访问模式有：
-
ReadWriteOnce卷可以被一个节点以读写方式挂载。 ReadWriteOnce 访问模式也允许运行在同一节点上的多个 Pod 访问卷。
-
ReadOnlyMany卷可以被多个节点以只读方式挂载。
-
ReadWriteMany卷可以被多个节点以读写方式挂载。
-
ReadWriteOncePod卷可以被单个 Pod 以读写方式挂载。 如果你想确保整个集群中只有一个 Pod 可以读取或写入该 PVC， 请使用 ReadWriteOncePod 访问模式。这只支持 CSI 卷以及需要 Kubernetes 1.22 以上版本。
这篇博客文章 Introducing Single Pod Access Mode for PersistentVolumes 描述了更详细的内容。
在命令行接口（CLI）中，访问模式也使用以下缩写形式：
- RWO - ReadWriteOnce
- ROX - ReadOnlyMany
- RWX - ReadWriteMany
- RWOP - ReadWriteOncePod
回收策略
persistentVolumeReclaimPolicy
当PV不再被使用了之后，对其处理方式目前支持三种策略：
Retain（保留） 保留数据，需要管理员手工清理数据
Recycle（回收） 清除PV中的数据，效果先当于rm -rf /thevolume/*
Delete（删除） 与PV相连的后端存储完成volume的删除操作，当然这常见于云服务商的存储服务
pv 状态（status）
一个PV的生命周期中，可能会处于4种不同的阶段：
Avaliable（可用）：表示可用状态，还未被任何PVC绑定
Bound（已绑定）：表示PV已经被PVC绑定
Released（已释放）：表示PVC被删除，但是资源还未被集群重新声明
Failed（失败）： 表示该PV的自动回收失败
关键配置：
Pod的volume关键字段如下：
spec.volumes：提供怎样的数据卷
spec.containers.volumeMounts：挂载到容器的什么路径
emptyDir 配置示例
apiVersion: v1
kind: Pod
metadata:
name: test-pd
spec:
containers:
- image: registry.k8s.io/test-webserver
name: test-container
volumeMounts:
- mountPath: /cache
name: cache-volume
volumes:
- name: cache-volume
emptyDir: {}
hostpath简易示例
官方文档;https://kubernetes.io/zh-cn/docs/concepts/storage/volumes/#hostpath
hostPath对应的目录不存在，会自行创建的配置
apiVersion: v1
kind: Pod
metadata:
name: test-webserver
spec:
containers:
- name: test-webserver
image: registry.k8s.io/test-webserver:latest
volumeMounts:
- mountPath: /var/local/aaa
name: mydir
- mountPath: /var/local/aaa/1.txt
name: myfile
volumes:
- name: mydir
hostPath:
# 确保文件所在目录成功创建。
path: /var/local/aaa
type: DirectoryOrCreate
- name: myfile
hostPath:
path: /var/local/aaa/1.txt
type: FileOrCreate
nfs
nfs 卷能将 NFS (网络文件系统) 挂载到你的 Pod 中。 不像 emptyDir 那样会在删除 Pod 的同时也会被删除，nfs 卷的内容在删除 Pod 时会被保存，卷只是被卸载。 这意味着 nfs 卷可以被预先填充数据，并且这些数据可以在 Pod 之间共享。
NFS (Network File System)即网络文件系统，NFS允许一个系统在网络上与他人共享目录和文件。通过使用NFS，用户和程序可以像访问本地文件一样访问远端系统上的文件。
**NFS至少有两个主要部分：**一台服务器和一台(或者更多)客户机。当用户希望使用远程文件时，只要用“mount”命令就可以把远程文件系统挂在自己的文件系统之下，使远程的文件像本地计算机上的文件—样可以被访问。
官方示例：https://github.com/kubernetes/examples/tree/master/staging/volumes/nfs
其他示例：https://www.cnblogs.com/lvzhenjiang/p/15375746.html
官方实例是通过镜像安装nfs,nfs配置pv映射到外部目录，同时配置一个nginx用于测试，但是里面的镜像是在是找不到，坑
1、安装nfs服务端
#1、用于安装nfs客户端和nfs服务端
yum install -y nfs-utils
#rpcbind是nfs中进行消息通知的服务，这里启动 nfs-server rpcbind两个服务，设置开机自启
[root@k8s-node1 ~]# systemctl enable nfs-server rpcbind --now
Created symlink from /etc/systemd/system/multi-user.target.wants/nfs-server.service to /usr/lib/systemd/system/nfs-server.service.
# 2、创建nfs共享目录、授权，读写权限应该就可以了，不用777
mkdir -p /data/nfs-volume && chmod -R 777 /data/nfs-volume
# 3、配置共享目录和共享规则，如果其中已经有其他规则，使用vim进行编辑
$ cat > /etc/exports << EOF
# 限制只有47.100.56.197才可以访问，可以配置网段
# rw 有读写权限
# no_root_squash 客户机用root访问该共享文件夹时，不映射root用户
/data/nfs-volume/nacos/mysql-master *(insecure,rw,async,no_root_squash)
/data/nfs-volume/nacos/mysql-slave *(insecure,rw,async,no_root_squash)
/data/nfs-volume/nacos/nfs-share *(insecure,rw,async,no_root_squash)
EOF
4、验证规则
# 更新全部共享规则
exportfs -r
# 查看共享了哪些目录
exportfs -v
# 安装nfs-server的服务器上执行，61.171.5.6是安装nfs的ip
showmount -e 61.171.5.6
Export list for 61.171.5.6:
/data/nfs-volume 61.171.5.6,43.143.136.203,47.100.56.197
nfs的共享权限说明
ro 该主机对该共享目录有只读权限
rw 该主机对该共享目录有读写权限
root_squash 客户机用root用户访问该共享文件夹时，将root用户映射成匿名用户
no_root_squash 客户机用root访问该共享文件夹时，不映射root用户
all_squash 客户机上的任何用户访问该共享目录时都映射成匿名用户
anonuid 将客户机上的用户映射成指定的本地用户ID的用户
anongid 将客户机上的用户映射成属于指定的本地用户组ID
sync 资料同步写入到内存与硬盘中
async 资料会先暂存于内存中，而非直接写入硬盘
insecure 允许从这台机器过来的非授权访问
2、nfs端口放通
一、NFS服务占用端口
由于nfs服务需要开启 mountd,nfs,nlockmgr,portmapper,rquotad这5个服务，将这5个服务的端口加到iptables里面而nfs 和 portmapper两个服务是固定端口的，nfs为2049，portmapper为111。其他的3个服务是用的随机端口。
mountd：它是RPC安装守护进程，主要功能是管理NFS的文件系统。当客户端顺利通过nfsd登录NFS服务器后，在使用NFS服务所提供的文件前，还必须通过文件使用权限的验证。它会读取NFS的配置文件/etc/exports来对比客户端权限。
nfs：基本的NFS守护进程，主要功能是管理客户端是否能够登录服务器；
portmapper：主要功能是进行端口映射工作。当客户端尝试连接并使用RPC服务器提供的服务（如NFS服务）时，portmap会将所管理的与服务对应的端口提供给客户端，从而使客户可以通过该端口向服务器请求服务。
放通端口：2049 、111 、TCP/UDP两种模式，可能还要放通服务端口
# 显示本地系统中注册到rpcbind协议版本2的所有RPC服务*
rpcinfo -p
vim /etc/sysconfig/nfs
RQUOTAD_PORT=32001
LOCKD_TCPPORT=32002
LOCKD_UDPPORT=32002
MOUNTD_PORT=32003
STATD_PORT=32004
# 先关闭服务
systemctl stop rpcbind.service
systemctl stop rpcbind.socket
#，再重启服务
service rpcbind start
service nfs start
# 测试服务正常
showmount -e
常用目录
/etc/exports NFS服务的主要配置文件
/usr/sbin/exportfs NFS服务的管理命令
/usr/sbin/showmount 客户端的查看命令
/var/lib/nfs/etab 记录NFS分享出来的目录的完整权限设定值
/var/lib/nfs/xtab 记录曾经登录过的客户端信息
3、安装nfs客户端
#1、用于安装nfs客户端和nfs服务端
yum install -y nfs-utils
# 2、启动rpcbind程序，设置开机自启
systemctl enable rpcbind --now
/3、 61.171.5.6是安装nfs的ip
showmount -e 61.171.5.6
# 创建挂载目录，
mkdir /opt/nfs-volume
# 进行挂载
mount -t nfs 61.171.5.6:/data/nfs-volume /opt/nfs-volume
# 查看磁盘占用的空间，用于查看挂载是否生效
df -h
# 在 /opt/nfs-volume/ 目录下创建一个文件，nfs服务端目录下文件已经同步
# 客户端开机自动挂载(未测试)
$ cat >> /etc/fstab << EOF
192.168.99.204:/data/nfs-volume /opt/nfs-volume defaults,_netdev 0 0
EOF
# 卸载挂载
umount /opt/nfs-volume
# 占用这个目录的进程
fuser -m -v /opt/nfs-volume
静态构建pv,pvc
nfs-client-provisioner 动态构架pv,pvc ：https://www.jianshu.com/p/b11f83039320
https://blog.csdn.net/weixin_58400622/article/details/122788933
pv
apiVersion: v1
kind: PersistentVolume
metadata:
name: nfs-pv001
labels:
pv: nfs-pv001
spec:
capacity:
storage: 500Mi
accessModes:
- ReadWriteOnce
persistentVolumeReclaimPolicy: Retain # 回收策略
storageClassName: nfs
nfs:
path: /data/nfs-volume # 确保对应的目录已经在共享目录下创建
server: 61.171.5.6
pvc
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: nfs-pvc001
namespace: default
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 100Mi
storageClassName: nfs
selector:
matchLabels:
pv: nfs-pv001
部署一个nginx测试
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-nginx
namespace: default
spec:
replicas: 1
selector:
matchLabels:
run: my-nginx
template:
metadata:
labels:
run: my-nginx
spec:
containers:
- name: my-nginx
image: nginx
ports:
- containerPort: 80
volumeMounts:
- name: nfs
mountPath: /usr/share/nginx/html
volumes:
- name: nfs
persistentVolumeClaim:
claimName: nfs-pvc001
# 部署报错，似乎是服务端配置的共享规则的ip问题，可能由于iptables中的配置影响到了，我这里直接将共享规则的ip改为了*
Warning FailedMount 2m53s (x18 over 23m) kubelet MountVolume.SetUp failed for volume "nfs-pv001" : mount failed: exit status 32
完了之后测试挂载，将静态资源放到对应文件夹下，测试是否可以访问到，可以增加pv，pvc,挂载配置文件目录，未测试
Helm
官方文档:https://helm.sh/zh/docs/intro/install/
Helm 是一个用于管理预配置 Kubernetes 资源包的工具。这些包被称为“Helm 图表”。
使用 Helm 来：
- 查找和使用打包为 Kubernetes 图表的流行软件
- 将你自己的应用程序共享为 Kubernetes 图表
- 为你的 Kubernetes 应用程序创建可重现的构建
- 智能管理你的 Kubernetes 清单文件
- 管理 Helm 包的发布
版本对应关系请看changelog
安装流程
- 下载 需要的版本
- 解压(
tar -zxvf helm-v3.0.0-linux-amd64.tar.gz) - 在解压目中找到
helm程序，移动到需要的目录中(mv linux-amd64/helm /usr/local/bin/helm)
策略资源
用于限制资源使用的内存，cpu,流量等，示例请百度
官方文档：https://kubernetes.io/zh-cn/docs/reference/kubernetes-api/policy-resources/
ingress
官网：https://kubernetes.github.io/ingress-nginx/deploy/
什么是Ingress？
通常情况下，service和pod的IP仅可在集群内部访问。集群外部的请求需要通过负载均衡转发到service在Node上暴露的NodePort上，然后再由kube-proxy将其转发给相关的Pod。
Service 是 K8S 服务的核心，屏蔽了服务细节，统一对外暴露服务接口，真正做到了“微服务”。举个例子，我们的一个服务 A，部署了 3 个备份，也就是 3 个 Pod；对于用户来说，只需要关注一个 Service 的入口就可以，而不需要操心究竟应该请求哪一个 Pod。优势非常明显：一方面外部用户不需要感知因为 Pod 上服务的意外崩溃、K8S 重新拉起 Pod 而造成的 IP 变更，外部用户也不需要感知因升级、变更服务带来的 Pod 替换而造成的 IP 变化，另一方面，Service 还可以做流量负载均衡。
但是，Service 主要负责 K8S 集群内部的网络拓扑。集群外部需要用 Ingress 。
Ingress 是整个 K8S 集群的接入层，复杂集群内外通讯。
安装Ingress
介绍页面 ：https://github.com/kubernetes/ingress-nginx/blob/main/docs/deploy/index.md
安装参考地址：http://tnblog.net/hb/article/details/7429
进入页面https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.4.0/deploy/static/provider/cloud/deploy.yaml，将里面内容复制，替换image地址后应用即可，一下是我记录下的内容
首先镜像还是下载不下来，执行docker pull命令、镜像替换从dcokerhub上找名称和版本相同的镜像
kind: Service 用于ingress被外部访问，需要修改添加nodeport
apiVersion: v1
kind: Namespace
metadata:
labels:
app.kubernetes.io/instance: ingress-nginx
app.kubernetes.io/name: ingress-nginx
name: ingress-nginx
---
apiVersion: v1
automountServiceAccountToken: true
kind: ServiceAccount
metadata:
labels:
app.kubernetes.io/component: controller
app.kubernetes.io/instance: ingress-nginx
app.kubernetes.io/name: ingress-nginx
app.kubernetes.io/part-of: ingress-nginx
app.kubernetes.io/version: 1.4.0
name: ingress-nginx
namespace: ingress-nginx
---
apiVersion: v1
kind: ServiceAccount
metadata:
labels:
app.kubernetes.io/component: admission-webhook
app.kubernetes.io/instance: ingress-nginx
app.kubernetes.io/name: ingress-nginx
app.kubernetes.io/part-of: ingress-nginx
app.kubernetes.io/version: 1.4.0
name: ingress-nginx-admission
namespace: ingress-nginx
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
labels:
app.kubernetes.io/component: controller
app.kubernetes.io/instance: ingress-nginx
app.kubernetes.io/name: ingress-nginx
app.kubernetes.io/part-of: ingress-nginx
app.kubernetes.io/version: 1.4.0
name: ingress-nginx
namespace: ingress-nginx
rules:
- apiGroups:
- ""
resources:
- namespaces
verbs:
- get
- apiGroups:
- ""
resources:
- configmaps
- pods
- secrets
- endpoints
verbs:
- get
- list
- watch
- apiGroups:
- ""
resources:
- services
verbs:
- get
- list
- watch
- apiGroups:
- networking.k8s.io
resources:
- ingresses
verbs:
- get
- list
- watch
- apiGroups:
- networking.k8s.io
resources:
- ingresses/status
verbs:
- update
- apiGroups:
- networking.k8s.io
resources:
- ingressclasses
verbs:
- get
- list
- watch
- apiGroups:
- ""
resourceNames:
- ingress-controller-leader
resources:
- configmaps
verbs:
- get
- update
- apiGroups:
- ""
resources:
- configmaps
verbs:
- create
- apiGroups:
- coordination.k8s.io
resourceNames:
- ingress-controller-leader
resources:
- leases
verbs:
- get
- update
- apiGroups:
- coordination.k8s.io
resources:
- leases
verbs:
- create
- apiGroups:
- ""
resources:
- events
verbs:
- create
- patch
- apiGroups:
- discovery.k8s.io
resources:
- endpointslices
verbs:
- list
- watch
- get
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
labels:
app.kubernetes.io/component: admission-webhook
app.kubernetes.io/instance: ingress-nginx
app.kubernetes.io/name: ingress-nginx
app.kubernetes.io/part-of: ingress-nginx
app.kubernetes.io/version: 1.4.0
name: ingress-nginx-admission
namespace: ingress-nginx
rules:
- apiGroups:
- ""
resources:
- secrets
verbs:
- get
- create
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
labels:
app.kubernetes.io/instance: ingress-nginx
app.kubernetes.io/name: ingress-nginx
app.kubernetes.io/part-of: ingress-nginx
app.kubernetes.io/version: 1.4.0
name: ingress-nginx
rules:
- apiGroups:
- ""
resources:
- configmaps
- endpoints
- nodes
- pods
- secrets
- namespaces
verbs:
- list
- watch
- apiGroups:
- coordination.k8s.io
resources:
- leases
verbs:
- list
- watch
- apiGroups:
- ""
resources:
- nodes
verbs:
- get
- apiGroups:
- ""
resources:
- services
verbs:
- get
- list
- watch
- apiGroups:
- networking.k8s.io
resources:
- ingresses
verbs:
- get
- list
- watch
- apiGroups:
- ""
resources:
- events
verbs:
- create
- patch
- apiGroups:
- networking.k8s.io
resources:
- ingresses/status
verbs:
- update
- apiGroups:
- networking.k8s.io
resources:
- ingressclasses
verbs:
- get
- list
- watch
- apiGroups:
- discovery.k8s.io
resources:
- endpointslices
verbs:
- list
- watch
- get
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
labels:
app.kubernetes.io/component: admission-webhook
app.kubernetes.io/instance: ingress-nginx
app.kubernetes.io/name: ingress-nginx
app.kubernetes.io/part-of: ingress-nginx
app.kubernetes.io/version: 1.4.0
name: ingress-nginx-admission
rules:
- apiGroups:
- admissionregistration.k8s.io
resources:
- validatingwebhookconfigurations
verbs:
- get
- update
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
labels:
app.kubernetes.io/component: controller
app.kubernetes.io/instance: ingress-nginx
app.kubernetes.io/name: ingress-nginx
app.kubernetes.io/part-of: ingress-nginx
app.kubernetes.io/version: 1.4.0
name: ingress-nginx
namespace: ingress-nginx
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: ingress-nginx
subjects:
- kind: ServiceAccount
name: ingress-nginx
namespace: ingress-nginx
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
labels:
app.kubernetes.io/component: admission-webhook
app.kubernetes.io/instance: ingress-nginx
app.kubernetes.io/name: ingress-nginx
app.kubernetes.io/part-of: ingress-nginx
app.kubernetes.io/version: 1.4.0
name: ingress-nginx-admission
namespace: ingress-nginx
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: ingress-nginx-admission
subjects:
- kind: ServiceAccount
name: ingress-nginx-admission
namespace: ingress-nginx
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
labels:
app.kubernetes.io/instance: ingress-nginx
app.kubernetes.io/name: ingress-nginx
app.kubernetes.io/part-of: ingress-nginx
app.kubernetes.io/version: 1.4.0
name: ingress-nginx
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: ingress-nginx
subjects:
- kind: ServiceAccount
name: ingress-nginx
namespace: ingress-nginx
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
labels:
app.kubernetes.io/component: admission-webhook
app.kubernetes.io/instance: ingress-nginx
app.kubernetes.io/name: ingress-nginx
app.kubernetes.io/part-of: ingress-nginx
app.kubernetes.io/version: 1.4.0
name: ingress-nginx-admission
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: ingress-nginx-admission
subjects:
- kind: ServiceAccount
name: ingress-nginx-admission
namespace: ingress-nginx
---
apiVersion: v1
data:
allow-snippet-annotations: "true"
kind: ConfigMap
metadata:
labels:
app.kubernetes.io/component: controller
app.kubernetes.io/instance: ingress-nginx
app.kubernetes.io/name: ingress-nginx
app.kubernetes.io/part-of: ingress-nginx
app.kubernetes.io/version: 1.4.0
name: ingress-nginx-controller
namespace: ingress-nginx
---
apiVersion: v1
kind: Service
metadata:
labels:
app.kubernetes.io/component: controller
app.kubernetes.io/instance: ingress-nginx
app.kubernetes.io/name: ingress-nginx
app.kubernetes.io/part-of: ingress-nginx
app.kubernetes.io/version: 1.4.0
name: ingress-nginx-controller
namespace: ingress-nginx
spec:
externalTrafficPolicy: Local
ipFamilies:
- IPv4
ipFamilyPolicy: SingleStack
ports:
- appProtocol: http
name: http
port: 82
protocol: TCP
targetPort: http
nodePort: 30400
- appProtocol: https
name: https
port: 443
protocol: TCP
targetPort: https
nodePort: 30443
selector:
app.kubernetes.io/component: controller
app.kubernetes.io/instance: ingress-nginx
app.kubernetes.io/name: ingress-nginx
type: NodePort
---
apiVersion: v1
kind: Service
metadata:
labels:
app.kubernetes.io/component: controller
app.kubernetes.io/instance: ingress-nginx
app.kubernetes.io/name: ingress-nginx
app.kubernetes.io/part-of: ingress-nginx
app.kubernetes.io/version: 1.4.0
name: ingress-nginx-controller-admission
namespace: ingress-nginx
spec:
ports:
- appProtocol: https
name: https-webhook
port: 443
targetPort: webhook
selector:
app.kubernetes.io/component: controller
app.kubernetes.io/instance: ingress-nginx
app.kubernetes.io/name: ingress-nginx
type: ClusterIP
---
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app.kubernetes.io/component: controller
app.kubernetes.io/instance: ingress-nginx
app.kubernetes.io/name: ingress-nginx
app.kubernetes.io/part-of: ingress-nginx
app.kubernetes.io/version: 1.4.0
name: ingress-nginx-controller
namespace: ingress-nginx
spec:
minReadySeconds: 0
revisionHistoryLimit: 10
selector:
matchLabels:
app.kubernetes.io/component: controller
app.kubernetes.io/instance: ingress-nginx
app.kubernetes.io/name: ingress-nginx
template:
metadata:
labels:
app.kubernetes.io/component: controller
app.kubernetes.io/instance: ingress-nginx
app.kubernetes.io/name: ingress-nginx
spec:
containers:
- args:
- /nginx-ingress-controller
- --publish-service=$(POD_NAMESPACE)/ingress-nginx-controller
- --election-id=ingress-controller-leader
- --controller-class=k8s.io/ingress-nginx
- --ingress-class=nginx
- --configmap=$(POD_NAMESPACE)/ingress-nginx-controller
- --validating-webhook=:8443
- --validating-webhook-certificate=/usr/local/certificates/cert
- --validating-webhook-key=/usr/local/certificates/key
env:
- name: POD_NAME
valueFrom:
fieldRef:
fieldPath: metadata.name
- name: POD_NAMESPACE
valueFrom:
fieldRef:
fieldPath: metadata.namespace
- name: LD_PRELOAD
value: /usr/local/lib/libmimalloc.so
image: dyrnq/ingress-nginx-controller:v1.4.0
imagePullPolicy: IfNotPresent
lifecycle:
preStop:
exec:
command:
- /wait-shutdown
livenessProbe:
failureThreshold: 5
httpGet:
path: /healthz
port: 10254
scheme: HTTP
initialDelaySeconds: 10
periodSeconds: 10
successThreshold: 1
timeoutSeconds: 1
name: controller
ports:
- containerPort: 81
name: http
protocol: TCP
- containerPort: 443
name: https
protocol: TCP
- containerPort: 8443
name: webhook
protocol: TCP
readinessProbe:
failureThreshold: 3
httpGet:
path: /healthz
port: 10254
scheme: HTTP
initialDelaySeconds: 10
periodSeconds: 10
successThreshold: 1
timeoutSeconds: 1
resources:
requests:
cpu: 100m
memory: 90Mi
securityContext:
allowPrivilegeEscalation: true
capabilities:
add:
- NET_BIND_SERVICE
drop:
- ALL
runAsUser: 101
volumeMounts:
- mountPath: /usr/local/certificates/
name: webhook-cert
readOnly: true
dnsPolicy: ClusterFirst
nodeSelector:
kubernetes.io/os: linux
serviceAccountName: ingress-nginx
terminationGracePeriodSeconds: 300
volumes:
- name: webhook-cert
secret:
secretName: ingress-nginx-admission
---
apiVersion: batch/v1
kind: Job
metadata:
labels:
app.kubernetes.io/component: admission-webhook
app.kubernetes.io/instance: ingress-nginx
app.kubernetes.io/name: ingress-nginx
app.kubernetes.io/part-of: ingress-nginx
app.kubernetes.io/version: 1.4.0
name: ingress-nginx-admission-create
namespace: ingress-nginx
spec:
template:
metadata:
labels:
app.kubernetes.io/component: admission-webhook
app.kubernetes.io/instance: ingress-nginx
app.kubernetes.io/name: ingress-nginx
app.kubernetes.io/part-of: ingress-nginx
app.kubernetes.io/version: 1.4.0
name: ingress-nginx-admission-create
spec:
containers:
- args:
- create
- --host=ingress-nginx-controller-admission,ingress-nginx-controller-admission.$(POD_NAMESPACE).svc
- --namespace=$(POD_NAMESPACE)
- --secret-name=ingress-nginx-admission
env:
- name: POD_NAMESPACE
valueFrom:
fieldRef:
fieldPath: metadata.namespace
image: dyrnq/kube-webhook-certgen:v20220916-gd32f8c343
imagePullPolicy: IfNotPresent
name: create
securityContext:
allowPrivilegeEscalation: false
nodeSelector:
kubernetes.io/os: linux
restartPolicy: OnFailure
securityContext:
fsGroup: 2000
runAsNonRoot: true
runAsUser: 2000
serviceAccountName: ingress-nginx-admission
---
apiVersion: batch/v1
kind: Job
metadata:
labels:
app.kubernetes.io/component: admission-webhook
app.kubernetes.io/instance: ingress-nginx
app.kubernetes.io/name: ingress-nginx
app.kubernetes.io/part-of: ingress-nginx
app.kubernetes.io/version: 1.4.0
name: ingress-nginx-admission-patch
namespace: ingress-nginx
spec:
template:
metadata:
labels:
app.kubernetes.io/component: admission-webhook
app.kubernetes.io/instance: ingress-nginx
app.kubernetes.io/name: ingress-nginx
app.kubernetes.io/part-of: ingress-nginx
app.kubernetes.io/version: 1.4.0
name: ingress-nginx-admission-patch
spec:
containers:
- args:
- patch
- --webhook-name=ingress-nginx-admission
- --namespace=$(POD_NAMESPACE)
- --patch-mutating=false
- --secret-name=ingress-nginx-admission
- --patch-failure-policy=Fail
env:
- name: POD_NAMESPACE
valueFrom:
fieldRef:
fieldPath: metadata.namespace
image: dyrnq/kube-webhook-certgen:v20220916-gd32f8c343
imagePullPolicy: IfNotPresent
name: patch
securityContext:
allowPrivilegeEscalation: false
nodeSelector:
kubernetes.io/os: linux
restartPolicy: OnFailure
securityContext:
fsGroup: 2000
runAsNonRoot: true
runAsUser: 2000
serviceAccountName: ingress-nginx-admission
---
apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
labels:
app.kubernetes.io/component: controller
app.kubernetes.io/instance: ingress-nginx
app.kubernetes.io/name: ingress-nginx
app.kubernetes.io/part-of: ingress-nginx
app.kubernetes.io/version: 1.4.0
name: nginx
spec:
controller: k8s.io/ingress-nginx
---
apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
metadata:
labels:
app.kubernetes.io/component: admission-webhook
app.kubernetes.io/instance: ingress-nginx
app.kubernetes.io/name: ingress-nginx
app.kubernetes.io/part-of: ingress-nginx
app.kubernetes.io/version: 1.4.0
name: ingress-nginx-admission
webhooks:
- admissionReviewVersions:
- v1
clientConfig:
service:
name: ingress-nginx-controller-admission
namespace: ingress-nginx
path: /networking/v1/ingresses
failurePolicy: Fail
matchPolicy: Equivalent
name: validate.nginx.ingress.kubernetes.io
rules:
- apiGroups:
- networking.k8s.io
apiVersions:
- v1
operations:
- CREATE
- UPDATE
resources:
- ingresses
sideEffects: None
根据配置文件中service配置的端口，测试一下服务，这里需要说明的是器http的访问不知道为啥访问不通
https://61.171.5.6:30443
问题处理
describe命令查看events发现back-off
通过logs -f查看容器内部日志
1、端口占用
port 80 is already in use. Please check the flag --http-port
删除了占用的deployment，你可以修改yaml中端口号
2、没有全新创建证书
unexpected error storing fake SSL Cert: could not create PEM certificate file /etc/ingress-controller/ssl/default-fake-certificate.pem: open /etc/ingress-controller/ssl/default-fake-certificate.pem: permission denied
# 无语，这么改
chmod -R 777 /var/lib/docker
3、
似乎没影响，服务正常启动，只是刚启动的时候报错，对应的secret也在ingress-nginx命名空间下找到了
MountVolume.SetUp failed for volume "webhook-cert" : secret "ingress-nginx-admission" not found
成功截图
转发规则
官方更多示例：https://kubernetes.io/zh-cn/docs/concepts/services-networking/ingress/
创建两个service用于演示
kubectl create deployment nginx --image=nginx
kubectl expose deployment nginx --port=89
kubectl create deployment nginx2 --image=nginx
kubectl expose deployment nginx2 --port=86
配置ingress访问规则（就是类似配置nginx的代理转发配置），让ingress将域名tomcat.tuling.com转发给后端的tomcat-service-yaml 服务，新建一个文件ingress-tomcat.yaml，内容如下：
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: nginx-ingress
annotations:
ingress.kubernetes.io/ssl-redirect: "false"
spec:
ingressClassName: nginx
rules:
- host: kube.sry1201.cn
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: nginx
port:
number: 89
kubectl get ing
证书配置
kubectl -n default create secret tls ks-fblsj-cn-secret --key key证书所在目录 --cert crt证书所在目录
kubectl -n kubernetes-dashboard create secret tls kubernetes-dashboard-secret --key /app/ingress/kube.sry1201.cn_nginx/kube.sry1201.cn.key --cert /app/ingress/kube.sry1201.cn_nginx/kube.sry1201.cn_bundle.crt
总而言之，配置之后无法访问，无语，
K8s Ingress、Ingress Controller 和 Ingress Class
http://events.jianshu.io/p/78e27347076c
地址重写
地址重写：https://github.com/kubernetes/ingress-nginx/blob/main/docs/examples/rewrite/README.md
关联信息
- 关联的主题：
- 上一篇：
- 下一篇：
- image: 20221101/1
- 转载自：
![[附源码]计算机毕业设计JAVA圆梦山区贫困学生助学系统](https://img-blog.csdnimg.cn/487a2afd23324c34b53c4a239af39c79.png)
![Java高效率复习-数据类型和运算符[Java]](https://img-blog.csdnimg.cn/8c3c57ae91894564a25fcee1b2e5971d.png)