kubernetes的资源

资源对象表

资源	缩写	说明
cluster		集群
componentstatu ses	cs	组件对象状态
configmaps	cm	ConfigMap是k8s配置管理工具
daemonsets	ds	DaemonSet管理node节点运行Pod
deployments	deploy	K8S控制器
endpoints	ep	Endpoints是实现服务的端点集合
events	ev	记录集群运行时的各种事件
ingress	ing	API对象，边缘路由功能
nodes	no	节点
namespaces	ns	命名空间
pods	po	获取Pod信息
replicasets	rs	用户指定数量的Pod副本
cronjob		周期性任务控制，不需要持续在后台运行
services	svc	各种服务

API（Application programming interface）

进程之间数据通信的接口，分为程序内部接口（函数的参数传递）

程序间的数据转换·数据调用，是通过网络进行数据传输。URL（统一资源定位符）

yaml文件

序列化

将程序运行内存中的数据类型（int，float，string，list，dict，object）转换为String（字符串）文件类型，方便数据的传输和存储。

XML、JSON、YAML

反序列化

将文本、字符串转换为内存中支持存储的数据类型的一种方式。

Yaml学习的步骤

1. 能看懂
   • 了解常用的属性名和参数
2. 能改
   • 通过修改官方文档的案例实现基础功能
3. 根据需要生成或创建yaml文件

必选字段

apiVersion: v1       #必选，版本号，例如v1
kind: Pod              #必选，资源类别
metadata:             #必选，元数据
name: string       #必选，Pod名称

spec:                    #必选，Pod中容器的详细定义
containers:         #必选，Pod中容器列表
  - name: string     #必选，容器名称
   image: string     #必选，容器的镜像名称

非必要字段

imagePullPolicy: [Always | Never | IfNotPresent]    
#获取镜像的策略 Alawys表示下载镜像 IfnotPresent表示优先使用本地镜像，否则下载镜像，Nerver表示仅使用本地镜像

pod

Pod 的资源控制器类型

1. ReplicationController 与 ReplicaSet
   • 在新版本的 Kubernetes 中建议使用 Replicaset 来取代Deployment
2. Deployment
   • Deployment 为 Pod 和 Replicaset 提供了一个声明式定义 declarative 方法，用来替代以前的ReplicationController 来方便的管理应用
3. DaemonSet
   • DoernonSet 确保全部(或者一些) Node 上运行一个 Pod 的副本，当有 Node 加入集群时，也会为他们新增一个 Pod
4. StateFulSet（适用于有状态服务）
   • StatefulSet 作为 Controller 为 Pod 提供唯-的标识。 它可以保证部署和 scale 的顺序 StatefulSet 是为了解决有状态服务的问题(对应 Deployments 和 ReplicaSets 是为无状态服务而设计)
   • #有状态和无状态可以查看下面的解释
5. Job 与 cronJob
   • Job 负责批处理任务，即仅执行一次的任务，它保证批处理任务的一个或多个 Pod 成功结束， Cron Job 管理基于时间的 Job ，其作用与计划任务类似。

无状态服务和有状态服务

1. 无状态
   • 例如：nginx是一种无状态服务，主要特点是不会产生重要数据
2. 有状态
   • 例如：MySQL是有状态的服务，会产生重要数据，涉及到数据共享，数据同步等一系列问题

资源控制器之DaemonSet

DaemonSet 确保全部(或者一些) Node上运行一个 Pod 的副本，当有 Node 加入集群时，也会为他们新增一个 Pod，当有 Node 从集群移除时，这些 Pod 也会被回收。删除 DaemonSet 将会删除它创建的所有 Pod 。

vim daemonset.yaml

apiVersion: apps/v1
kind: DaemonSet
metadata:
name: deamonset
labels:
 app: daemonset
spec:
selector:
 matchLabels:
   name: deamonset
template:
 metadata:
   labels:
     name: deamonset
 spec:
   containers:
      - name: daemonset
        image: docker.io/nginx

资源控制器之Deployment

Deployment 为 Pod 和 ReplicaSet 提供了一个声明式定义(declarative)方法，用来替代以前的ReplicationController 来方便的管理应用.

Deployment 应用示例：

vim deploy.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
name: my-nginx
spec:
selector:
 matchLabels:
   app: web-nginx
replicas: 3
template:
 metadata:
   labels:
     app: web-nginx
 spec:
   containers:
        - name: web-nginx
          image: docker.io/nginx
          imagePullPolicy: IfNotPresent
          ports:
          - containerPort: 80

kubectl create -f deploy.yaml --record

–record参数可以记录命令，我们可以很方便的查看每次 revision 的变化

创建完成后，我们可以查看下我们的 Pod 状态：

我们可以通过命令 kubectl scale deployment my-nginx --replicas=5 将副本数量扩容到 5 个：

也可以通过该命令 kubectl scale deployment my-nginx --replicas=2 缩容到 2 个：

这个时候我们注意一下，在缩容的时候，优先删除的是创建时间短的 Pod 。下面我们在来看一下 deployment 的升级与回滚：

升级版本

查看当前的 Pod 当中的 nginx 的版本： kubectl exec Pod-name -it – nginx -v

升级 images 版本： kubectl set image deployment/my-nginx web-nginx=nginx:1.9.1

使用命令 kubectl get rs 命令查看 Pod 的更新过程：

当升级完成后，查看一下当前 Pod 的 nginx 的版本：

通过命令查看 deployment 的历史记录： kubectl rollout history deployment my-nginx

回滚镜像

回滚到之前的版本： kubectl rollout undo deployment --to-revision=1

回滚完成后，查看一下当前 Pod 的 nginx 的版本：

Pod 的健康检查-探针

存活探针（Liveness Probe）：检查失败的话，会直接杀死pod，pod会根据重启策略，来确定是否重启

就绪探针（Readiness Probe）：检查失败的话，会先让pod下线。pod会处于就绪状态，但不会重启。

readinessProbe:     #使用就绪探针
   httpGet:        #使用httpGet检查，获取页面，（200 <= code < 400）,正常，如果不是则为失败。
     port: 80
     path: /index.html
   initialDelaySeconds: 1   #容器初始化成功后几秒再检查
   periodSeconds: 3         #检测周期为3秒

例子：

vim readinessProbe-httpget.yaml

apiVersion: v1
kind: Pod
metadata:
name: readiness-httpget-pod
spec:
containers:
  - name: readiness-httpget-container
    image: docker.io/nginx
    imagePullPolicy: IfNotPresent
    readinessProbe:     #可以更改探测方式： livenessProbe 和 readinessProbe
      httpGet:
        port: 80
        path: /index.html
      initialDelaySeconds: 1
      periodSeconds: 3

然后可以进去之后进行验证

Service（外部访问）

让k8s外部能够访问到pod的网络模式配置器。

• 可以实现四层的负载均衡。
• 具有两种网络模式
  • iptable
  • ipvs（新版本建议使用。）
• 通过标签选择器来实现pod的负载均衡
  • ip和pod名称可以是随机生成的
  • 标签是我们指定的。

Service的服务类型

Service的服务类型可以分为以下几种

• ClusterIP
• NodePort
• LoadBalancer
• ExternalName

ClusterIP

通过集群内部IP公开Service，只能在集群内部访问。但可以使用Ingress或者Gateway来进行公开访问。

• 默认 Service 类型从你的集群中为此预留的 IP 地址池中分配一个 IP 地址。

示例：

vim nginx.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
name: my-nginx
spec:
selector:
matchLabels:
app: web-nginx
replicas: 3
template:
metadata:
labels:
  app: web-nginx
spec:
containers:
        - name: web-nginx
          image: docker.io/nginx
          imagePullPolicy: IfNotPresent
          ports:
          - containerPort: 80

#-----------------------------# 分割线 #--------------------------------------#

vim nginx-svc.yaml

apiVersion: v1
kind: Service
metadata:
  name: myapp
spec:
  type: ClusterIP
  selector:
    app: web-nginx
  ports:
  - name: http
    port: 80
    targetPort: 80

通过curl来查看是否可以正常访问：

curl -I IP地址

为了方便分别当前是哪个 Pod 给我们提供的服务，我们依次将三个 Pod 内 index.html 的文件内容修改为 “1”、“2”、“3”，然后再查看

显示正常即为正确！

NodePort

Service服务通过NodePort来将访问的端口进行指定，避免与原先的服务分配的端口起冲突。

案例：

apiVersion: v1
kind: Service
metadata:
name: my-service
spec:
type: NodePort
selector:
 app.kubernetes.io/name: MyApp
ports:
 # 默认情况下，为了方便起见，`targetPort` 被设置为与 `port` 字段相同的值。
    - port: 80
      targetPort: 80
      # 可选字段
      # 默认情况下，为了方便起见，Kubernetes 控制平面会从某个范围内分配一个端口号
      #（默认：30000-32767）
      nodePort: 30007

验证：

kubectl get svc

出来我们所配置的端口即为正确。

k8s endpoint详解

在 Kubernetes 中，Endpoint 是一种资源对象，用于表示服务的网络终结点。Endpoint 提供了服务的访问地址，允许其他 Pod、Service 或外部实体与服务进行通信。

Endpoint 对象通常与 Service 对象关联，用于定义 Service 的后端 Pod 的网络地址。当创建或更新 Service 时，Kubernetes 控制平面会自动创建或更新相应的 Endpoint 对象，以确保 Service 的后端地址正确更新。

以下是 Endpoint 对象的一些重要字段：

metadata: 包含元数据信息，如名称、命名空间和标签等。

subsets: 定义了一组具有相同服务端口和协议的后端 Pod。

addresses: 指定了每个后端 Pod 的 IP 地址。

ports: 指定了每个后端 Pod 提供的服务端口。

Endpoint 对象的主要作用是维护与 Service 关联的后端 Pod 的网络地址信息。当 Service 需要将流量转发给后端 Pod 时，它会查询与之关联的 Endpoint 对象，从中获取后端 Pod 的 IP 地址和端口信息。

Endpoint 对象通常由 Kubernetes 控制平面自动创建和更新，无需手动操作。但有时可以使用 kubectl 命令或 Kubernetes API 来查看或调整 Endpoint 对象，以便了解 Service 的后端 Pod 的网络配置情况。

Pod的存储

• Configmap：存储明文的配置文件。方便配置文件的共享。以key：value结构进行数据的存储，默认存储在k8s的etcd中
• Secret：加密文件的存储，证书文件、密码文件、token文件等数据的存储
• Volume：支持多种文件系统的数据挂载（nfs、虚拟文件系统、内存文件、xfs、普通目录等）

Configmap

ConfigMap API 给我们提供了向容器中注入配置信息的机制，ConfigMap 可以被用来保存单个属性，也可以用来保存整个配置文件或者 JSON 二进制大对象。

mkdir configmap-test
# 在我们的 configmap-test 文件夹下有两个文件分别为： test-1 与 test-2 里面的内容分别为：

cat test-1 

enemies=aliens
lives=3
enemies.cheat=true
enemies.cheat.level=noGoodRotten
secret.code.passphrase=UUDDLRLRBABAS
secret.code.allowed=true
secret.code.lives=30

cat test-2 

color.good=purple
color.bad=yellow
allow.textmode=true
how.nice.to.look=fairlyNice

# 创建：configmap
kubectl create configmap config-01 --from-file=configmap-test
# --from-file 指定在目录下的所有文件都会被用在 ConfigMap 里面创建一个键值对，键的名字就是文件名，值就是文件的内容

创建完成后查看一下

kubectl get configmaps

生成yaml文件

kubectl get configmaps config-01 -o yaml

apiVersion: v1
data:                              #配置文件的内容
test-1: |                       #  |  的作用启动多行模式
 enemies=aliens
 lives=3
 enemies.cheat=true
 enemies.cheat.level=noGoodRotten
 secret.code.passphrase=UUDDLRLRBABAS
 secret.code.allowed=true
 secret.code.lives=30
test-2: |
 color.good=purple
 color.bad=yellow
 allow.textmode=true
 how.nice.to.look=fairlyNice
kind: ConfigMap
metadata:
creationTimestamp: "2024-05-16T06:45:22Z"
name: config-01
namespace: default
resourceVersion: "20549"
uid: 147abd3d-55d3-4611-89e2-e60d5dcf6fa4

Secret

用于k8s中证书文件、密码、重要数据的存储。保存到etcd中

ssl/tls：https的加密协议。目前主流为tls

1.1、Service Account

kubectl create secret tls tls-secret --key tls.key --cert tls.crt

Service Account 用来访问 Kubernetes API，由 Kubernetes 自动创建，并且会自动挂载到 Pod的/run/secrets/kubernetes.io/serviceaccount 目录中。

kubectl exec kube-proxy-hz44s -n kube-system -it -- /bin/sh
cd /run/secrets/kubernetes.io/serviceaccount

即可查看文件内容

Opaque Secret

1.2.1、创建说明：

Opaque 类型的数据是一个 map 类型，要求 value 是 base64 编码格式：

echo -n "admin" | base64
YWRtaW4=

echo -n "123456789" | base64
MTIzNDU2Nzg5

#-----------------------------# 分割线 #--------------------------------------#

vim secrets.yaml

apiVersion: v1
kind: Secret
metadata:
name: mysecret
type: Opaque
data:
password: MTIzNDU2Nzg5
username: YWRtaW4=

1.2.2、使用方式Opaque Secret

1.2.1、创建说明：

Opaque 类型的数据是一个 map 类型，要求 value 是 base64 编码格式：

echo -n "admin" | base64
YWRtaW4=

echo -n "123456789" | base64
MTIzNDU2Nzg5

#-----------------------------# 分割线 #--------------------------------------#

vim secrets.yaml

apiVersion: v1
kind: Secret
metadata:
name: mysecret
type: Opaque
data:
password: MTIzNDU2Nzg5
username: YWRtaW4=

1.2.2、使用方式

a、将 Secret 挂载到 Volume 中：

apiVersion: v1
kind: Pod
metadata:
name: seret-test
labels:
 name: seret-test
spec:
volumes:
  - name: secrets
    secret:
      secretName: mysecret
  containers:
  - name: db
    image: docker.io/nginx
    volumeMounts:
    - name: secrets
      mountPath: "/etc/secret"
      readOnly: true

a、将 Secret 挂载到 Volume 中：

apiVersion: v1
kind: Pod
metadata:
  name: seret-test
  labels:
    name: seret-test
spec:
  volumes:
  - name: secrets
    secret:
      secretName: mysecret
  containers:
  - name: db
    image: docker.io/nginx
    volumeMounts:
    - name: secrets
      mountPath: "/etc/secret"
      readOnly: true

k8s中Volume的分类

• 普通磁盘：本地文件hostPath、emptyDir
• 网络文件系统：nfs、cephfs、各种网盘
• k8s内部的资源：Secret、Configmap、downwardAPI

emptyDir

默认使用内存作为存储介质。

临时存储，一般用户pod中容器间的数据的交换和分享

生命周期和pod相同，pod创建时，生成emptyDir，pod删除时，会同时销毁emptyDir。

pod容器中删除和重启不会影响到emptyDir

hostPath

将node上的节点上的目录挂载到pod上，但不推荐使用。

会导致pod和node节点强耦合。

• 高内聚：同一个pod或程序只实现一个或一类功能，将相关联的功能组合在一起
• 低耦合：互相之间尽量的减少依赖，能够独立运行。

PV和PVC

PV/PVC是存储的中间层，中间件，是对存储资源的一种抽象，方便pod挂载存储。

• PV对接存储介质（网络存储），设置存储的容量、权限、策略。
• PVC用于pod和PV进行对接，将pod的使用需求写在PVC中，PVC会自动将pod挂载符合的PV

资源扩展、扩容缩

横向（水平）：增加设备或容器的数量，负载均衡。

纵向（垂直）：增加本机性能，加内存，加CPU，增加宽带。