kubernetes使用（1.25）

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

安装流程

1. 下载 需要的版本
2. 解压(tar -zxvf helm-v3.0.0-linux-amd64.tar.gz)
3. 在解压目中找到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
• 转载自：