docker学习【9】Kubernetes基础操作
docker学习【9】Kubernetes基础操作
一、资源管理介绍
1、在kubernetes中，所有的内容都抽象为资源，用户需要通过操作资源来管理kubernetes：
- kubernetes的本质上就是一个集群系统，用户可以在集群中部署各种服务，所谓的部署服务，其实就是在kubernetes集群中运行一个个的容器，并将指定的程序跑在容器中。
- kubernetes的最小管理单元是pod而不是容器，所以只能将容器放在
Pod中，而kubernetes一般也不会直接管理Pod，而是通过Pod控制器来管理Pod的。- Pod可以提供服务之后，就要考虑如何访问Pod中服务，kubernetes提供了
Service资源实现这个功能。- 如果Pod中程序的数据需要持久化，kubernetes还提供了各种
存储系统。- 学习kubernetes的核心，就是学习如何对集群上的
Pod、Pod控制器、Service、存储等各种资源进行操作
2、 YAML语言介绍
YAML是一个类似 XML、JSON 的标记性语言。它强调以数据为中心，并不是以标识语言为重点。因而YAML本身的定义比较简单，号称"一种人性化的数据格式语言"。
（1）YAML的语法：
- 大小写敏感
- 使用缩进表示层级关系
- 缩进不允许使用tab，只允许空格( 低版本限制 )
- 缩进的空格数不重要，只要相同层级的元素左对齐即可
- '#'表示注释
（2）YAML支持的几种数据类型
- 纯量：单个的、不可再分的值
- 对象：键值对的集合，又称为映射（mapping）/ 哈希（hash） / 字典（dictionary）
- 数组：一组按次序排列的值，又称为序列（sequence） / 列表（list）
#<1># 纯量, 就是指的一个简单的值，字符串、布尔值、整数、浮点数、Null、时间、日期
# 1 布尔类型
c1: true (或者True)
# 2 整型
c2: 234
# 3 浮点型
c3: 3.14
# 4 null类型
c4: ~ # 使用~表示null
# 5 日期类型
c5: 2018-02-17 # 日期必须使用ISO 8601格式，即yyyy-MM-dd
# 6 时间类型
c6: 2018-02-17T15:02:31+08:00 # 时间使用ISO 8601格式，时间和日期之间使用T连接，最后使用+代表时区
# 7 字符串类型
c7: heima # 简单写法，直接写值 , 如果字符串中间有特殊字符，必须使用双引号或者单引号包裹
c8: line1
line2 # 字符串过多的情况可以拆成多行，每一行会被转化成一个空格
#<2># 对象
# 形式一(推荐):
heima:
age: 15
address: Beijing
# 形式二(了解):
heima: {age: 15,address: Beijing}
yaml
#<3># 数组
# 形式一(推荐):
address:
- 顺义
- 昌平
# 形式二(了解):
address: [零零,散散]
小提示：
1 书写yaml切记
:后面要加一个空格2 如果需要将多段yaml配置放在一个文件中，中间要使用
---分隔3 下面是一个yaml转json的网站，可以通过它验证yaml是否书写正确
3、资源管理方式
-
命令式对象管理：直接使用命令去操作kubernetes资源
kubectl run nginx-pod --image=nginx:1.17.1 --port=80 -
命令式对象配置：通过命令配置和配置文件去操作kubernetes资源
kubectl create/patch -f nginx-pod.yaml -
声明式对象配置：通过apply命令和配置文件去操作kubernetes资源
kubectl apply -f nginx-pod.yaml
| 类型 | 操作对象 | 适用环境 | 优点 | 缺点 |
|---|---|---|---|---|
| 命令式对象管理 | 对象 | 测试 | 简单 | 只能操作活动对象，无法审计、跟踪 |
| 命令式对象配置 | 文件 | 开发 | 可以审计、跟踪 | 项目大时，配置文件多，操作麻烦 |
| 声明式对象配置 | 目录 | 开发 | 支持目录操作 | 意外情况下难以调试 |
4、命令式对象管理
（1）kubectl命令
kubectl是kubernetes集群的命令行工具，通过它能够对集群本身进行管理，并能够在集群上进行容器化应用的安装部署。
kubectl命令的语法如下：
kubectl [command] [type] [name] [flags]
comand：指定要对资源执行的操作，例如create、get、delete
type：指定资源类型，比如deployment、pod、service
name：指定资源的名称，名称大小写敏感
flags：指定额外的可选参数
# 查看所有pod
kubectl get pod
# 查看某个pod
kubectl get pod pod_name
# 查看某个pod,以yaml格式展示结果
kubectl get pod pod_name -o yaml
[root@CentOS8Shaowenhua ~]# kubectl get pod
NAME READY STATUS RESTARTS AGE
nginx-7854ff8877-k4d69 1/1 Running 1 (46m ago) 40h
[root@CentOS8Shaowenhua ~]# kubectl get pod nginx-7854ff8877-k4d69
NAME READY STATUS RESTARTS AGE
nginx-7854ff8877-k4d69 1/1 Running 1 (47m ago) 40h
[root@CentOS8Shaowenhua ~]# kubectl get pod nginx-7854ff8877-k4d69 -o yaml
apiVersion: v1
kind: Pod
metadata:
creationTimestamp: "2024-05-05T12:40:19Z"
generateName: nginx-7854ff8877-
labels:
app: nginx
pod-template-hash: 7854ff8877
name: nginx-7854ff8877-k4d69
namespace: default
ownerReferences:
- apiVersion: apps/v1
blockOwnerDeletion: true
controller: true
kind: ReplicaSet
name: nginx-7854ff8877
uid: 5b335a72-0f4f-430b-b907-5fccb7218453
resourceVersion: "5206"
uid: f5178873-25cc-4543-b34c-b1dd90bc46dd
spec:
containers:
- image: nginx
imagePullPolicy: Always
name: nginx
resources: {}
terminationMessagePath: /dev/termination-log
terminationMessagePolicy: File
volumeMounts:
- mountPath: /var/run/secrets/kubernetes.io/serviceaccount
name: kube-api-access-vxkkc
readOnly: true
dnsPolicy: ClusterFirst
enableServiceLinks: true
nodeName: docker1
preemptionPolicy: PreemptLowerPriority
priority: 0
restartPolicy: Always
schedulerName: default-scheduler
securityContext: {}
serviceAccount: default
serviceAccountName: default
terminationGracePeriodSeconds: 30
tolerations:
- effect: NoExecute
key: node.kubernetes.io/not-ready
operator: Exists
tolerationSeconds: 300
- effect: NoExecute
key: node.kubernetes.io/unreachable
operator: Exists
tolerationSeconds: 300
volumes:
- name: kube-api-access-vxkkc
projected:
defaultMode: 420
sources:
- serviceAccountToken:
expirationSeconds: 3607
path: token
- configMap:
items:
- key: ca.crt
path: ca.crt
name: kube-root-ca.crt
- downwardAPI:
items:
- fieldRef:
apiVersion: v1
fieldPath: metadata.namespace
path: namespace
status:
conditions:
- lastProbeTime: null
lastTransitionTime: "2024-05-05T12:40:19Z"
status: "True"
type: Initialized
- lastProbeTime: null
lastTransitionTime: "2024-05-07T04:04:55Z"
status: "True"
type: Ready
- lastProbeTime: null
lastTransitionTime: "2024-05-07T04:04:55Z"
status: "True"
type: ContainersReady
- lastProbeTime: null
lastTransitionTime: "2024-05-05T12:40:19Z"
status: "True"
type: PodScheduled
containerStatuses:
- containerID: containerd://6294019e568f3764cd53247765741d95a3e26deb86ec2673b7f2f98ef800b381
image: docker.io/library/nginx:latest
imageID: docker.io/library/nginx@sha256:32e76d4f34f80e479964a0fbd4c5b4f6967b5322c8d004e9cf0cb81c93510766
lastState:
terminated:
containerID: containerd://7e62d399c595452aebeae3257b2416ab34e2159c081d1372f8debf332df34fb1
exitCode: 255
finishedAt: "2024-05-07T04:02:59Z"
reason: Unknown
startedAt: "2024-05-05T12:42:32Z"
name: nginx
ready: true
restartCount: 1
started: true
state:
running:
startedAt: "2024-05-07T04:04:54Z"
hostIP: 192.168.27.134
phase: Running
podIP: 10.244.1.3
podIPs:
- ip: 10.244.1.3
qosClass: BestEffort
startTime: "2024-05-05T12:40:19Z"
（2）资源类型
kubernetes中所有的内容都抽象为资源，可以通过下面的命令进行查看:
kubectl api-resources
[root@CentOS8Shaowenhua ~]# kubectl api-resources
NAME SHORTNAMES APIVERSION NAMESPACED KIND
bindings v1 true Binding
componentstatuses cs v1 false ComponentStatus
configmaps cm v1 true ConfigMap
endpoints ep v1 true Endpoints
events ev v1 true Event
limitranges limits v1 true LimitRange
namespaces ns v1 false Namespace
nodes no v1 false Node
persistentvolumeclaims pvc v1 true PersistentVolumeClaim
persistentvolumes pv v1 false PersistentVolume
pods po v1 true Pod
podtemplates v1 true PodTemplate
replicationcontrollers rc v1 true ReplicationController
resourcequotas quota v1 true ResourceQuota
secrets v1 true Secret
serviceaccounts sa v1 true ServiceAccount
services svc v1 true Service
mutatingwebhookconfigurations admissionregistration.k8s.io/v1 false MutatingWebhookConfiguration
validatingwebhookconfigurations admissionregistration.k8s.io/v1 false ValidatingWebhookConfiguration
customresourcedefinitions crd,crds apiextensions.k8s.io/v1 false CustomResourceDefinition
apiservices apiregistration.k8s.io/v1 false APIService
controllerrevisions apps/v1 true ControllerRevision
daemonsets ds apps/v1 true DaemonSet
deployments deploy apps/v1 true Deployment
replicasets rs apps/v1 true ReplicaSet
statefulsets sts apps/v1 true StatefulSet
selfsubjectreviews authentication.k8s.io/v1 false SelfSubjectReview
tokenreviews authentication.k8s.io/v1 false TokenReview
localsubjectaccessreviews authorization.k8s.io/v1 true LocalSubjectAccessReview
selfsubjectaccessreviews authorization.k8s.io/v1 false SelfSubjectAccessReview
selfsubjectrulesreviews authorization.k8s.io/v1 false SelfSubjectRulesReview
subjectaccessreviews authorization.k8s.io/v1 false SubjectAccessReview
horizontalpodautoscalers hpa autoscaling/v2 true HorizontalPodAutoscaler
cronjobs cj batch/v1 true CronJob
jobs batch/v1 true Job
certificatesigningrequests csr certificates.k8s.io/v1 false CertificateSigningRequest
leases coordination.k8s.io/v1 true Lease
endpointslices discovery.k8s.io/v1 true EndpointSlice
events ev events.k8s.io/v1 true Event
flowschemas flowcontrol.apiserver.k8s.io/v1beta3 false FlowSchema
prioritylevelconfigurations flowcontrol.apiserver.k8s.io/v1beta3 false PriorityLevelConfiguration
ingressclasses networking.k8s.io/v1 false IngressClass
ingresses ing networking.k8s.io/v1 true Ingress
networkpolicies netpol networking.k8s.io/v1 true NetworkPolicy
runtimeclasses node.k8s.io/v1 false RuntimeClass
poddisruptionbudgets pdb policy/v1 true PodDisruptionBudget
clusterrolebindings rbac.authorization.k8s.io/v1 false ClusterRoleBinding
clusterroles rbac.authorization.k8s.io/v1 false ClusterRole
rolebindings rbac.authorization.k8s.io/v1 true RoleBinding
roles rbac.authorization.k8s.io/v1 true Role
priorityclasses pc scheduling.k8s.io/v1 false PriorityClass
csidrivers storage.k8s.io/v1 false CSIDriver
csinodes storage.k8s.io/v1 false CSINode
csistoragecapacities storage.k8s.io/v1 true CSIStorageCapacity
storageclasses sc storage.k8s.io/v1 false StorageClass
volumeattachments storage.k8s.io/v1 false VolumeAttachment
[root@CentOS8Shaowenhua ~]#
经常使用的资源有下面这些：
| 资源分类 | 资源名称 | 缩写 | 资源作用 |
|---|---|---|---|
| 集群级别资源 | nodes | no | 集群组成部分 |
| namespaces | ns | 隔离Pod | |
| pod资源 | pods | po | 装载容器 |
| pod资源控制器 | replicationcontrollers | rc | 控制pod资源 |
| replicasets | rs | 控制pod资源 | |
| deployments | deploy | 控制pod资源 | |
| daemonsets | ds | 控制pod资源 | |
| jobs | 控制pod资源 | ||
| cronjobs | cj | 控制pod资源 | |
| horizontalpodautoscalers | hpa | 控制pod资源 | |
| statefulsets | sts | 控制pod资源 | |
| 服务发现资源 | services | svc | 统一pod对外接口 |
| ingress | ing | 统一pod对外接口 | |
| 存储资源 | volumeattachments | 存储 | |
| persistentvolumes | pv | 存储 | |
| persistentvolumeclaims | pvc | 存储 | |
| 配置资源 | configmaps | cm | 配置 |
| secrets | 配置 |
（3）操作
kubernetes允许对资源进行多种操作，可以通过--help查看详细的操作命令
kubectl --help
[root@CentOS8Shaowenhua ~]# kubectl --help
kubectl controls the Kubernetes cluster manager.
Find more information at: https://kubernetes.io/docs/reference/kubectl/
Basic Commands (Beginner):
create Create a resource from a file or from stdin
expose Take a replication controller, service, deployment or pod and expose it as a new Kubernetes service
run Run a particular image on the cluster
set Set specific features on objects
Basic Commands (Intermediate):
explain Get documentation for a resource
get Display one or many resources
edit Edit a resource on the server
delete Delete resources by file names, stdin, resources and names, or by resources and label selector
Deploy Commands:
rollout Manage the rollout of a resource
scale Set a new size for a deployment, replica set, or replication controller
autoscale Auto-scale a deployment, replica set, stateful set, or replication controller
Cluster Management Commands:
certificate Modify certificate resources
cluster-info Display cluster information
top Display resource (CPU/memory) usage
cordon Mark node as unschedulable
uncordon Mark node as schedulable
drain Drain node in preparation for maintenance
taint Update the taints on one or more nodes
Troubleshooting and Debugging Commands:
describe Show details of a specific resource or group of resources
logs Print the logs for a container in a pod
attach Attach to a running container
exec Execute a command in a container
port-forward Forward one or more local ports to a pod
proxy Run a proxy to the Kubernetes API server
cp Copy files and directories to and from containers
auth Inspect authorization
debug Create debugging sessions for troubleshooting workloads and nodes
events List events
Advanced Commands:
diff Diff the live version against a would-be applied version
apply Apply a configuration to a resource by file name or stdin
patch Update fields of a resource
replace Replace a resource by file name or stdin
wait Experimental: Wait for a specific condition on one or many resources
kustomize Build a kustomization target from a directory or URL
Settings Commands:
label Update the labels on a resource
annotate Update the annotations on a resource
completion Output shell completion code for the specified shell (bash, zsh, fish, or powershell)
Other Commands:
api-resources Print the supported API resources on the server
api-versions Print the supported API versions on the server, in the form of "group/version"
config Modify kubeconfig files
plugin Provides utilities for interacting with plugins
version Print the client and server version information
Usage:
kubectl [flags] [options]
Use "kubectl <command> --help" for more information about a given command.
Use "kubectl options" for a list of global command-line options (applies to all commands).
[root@CentOS8Shaowenhua ~]#
经常使用的操作有下面这些：
| 命令分类 | 命令 | 翻译 | 命令作用 |
|---|---|---|---|
| 基本命令 | create | 创建 | 创建一个资源 |
| edit | 编辑 | 编辑一个资源 | |
| get | 获取 | 获取一个资源 | |
| patch | 更新 | 更新一个资源 | |
| delete | 删除 | 删除一个资源 | |
| explain | 解释 | 展示资源文档 | |
| 运行和调试 | run | 运行 | 在集群中运行一个指定的镜像 |
| expose | 暴露 | 暴露资源为Service | |
| describe | 描述 | 显示资源内部信息 | |
| logs | 日志输出容器在 pod 中的日志 | 输出容器在 pod 中的日志 | |
| attach | 缠绕进入运行中的容器 | 进入运行中的容器 | |
| exec | 执行容器中的一个命令 | 执行容器中的一个命令 | |
| cp | 复制 | 在Pod内外复制文件 | |
| rollout | 首次展示 | 管理资源的发布 | |
| scale | 规模 | 扩(缩)容Pod的数量 | |
| autoscale | 自动调整 | 自动调整Pod的数量 | |
| 高级命令 | apply | rc | 通过文件对资源进行配置 |
| label | 标签 | 更新资源上的标签 | |
| 其他命令 | cluster-info | 集群信息 | 显示集群信息 |
| version | 版本 | 显示当前Server和Client的版本 |
（4）演示
下面以一个namespace / pod的创建和删除简单演示下命令的使用：
# 创建一个namespace
[root@CentOS8Shaowenhua ~]# kubectl create namespace dev
namespace/dev created
# 获取namespace
[root@CentOS8Shaowenhua ~]# kubectl get ns
NAME STATUS AGE
default Active 40h
dev Active 9s
kube-flannel Active 40h
kube-node-lease Active 40h
kube-public Active 40h
kube-system Active 40h
# 在此namespace下创建并运行一个nginx的Pod
[root@CentOS8Shaowenhua ~]# kubectl run pod --image=nginx:latest -n dev
pod/pod created
# 查看新创建的pod
[root@CentOS8Shaowenhua ~]# kubectl get pod -n dev
NAME READY STATUS RESTARTS AGE
pod 0/1 ContainerCreating 0 34s
# 删除指定的pod
[root@master ~]# kubectl delete pod pod_name
# 删除指定的namespace
[root@CentOS8Shaowenhua ~]# kubectl delete ns dev
namespace "dev" deleted
5、命令式对象配置
命令式对象配置就是使用命令配合配置文件一起来操作kubernetes资源。
（1） 创建一个nginxpod.yaml，内容如下：
[root@CentOS8Shaowenhua ~]# vi nginxpod.yaml
[root@CentOS8Shaowenhua ~]# cat nginxpod.yaml
apiVersion: v1
kind: Namespace
metadata:
name: dev
---
apiVersion: v1
kind: Pod
metadata:
name: nginxpod
namespace: dev
spec:
containers:
- name: nginx-containers
image: nginx:latest
（2）执行create命令，创建资源：
[root@CentOS8Shaowenhua ~]# kubectl create -f nginxpod.yaml
namespace/dev created
pod/nginxpod created
此时发现创建了两个资源对象，分别是namespace和pod
（3）执行get命令，查看资源：
[root@CentOS8Shaowenhua ~]# kubectl get -f nginxpod.yaml
NAME STATUS AGE
namespace/dev Active 12s
NAME READY STATUS RESTARTS AGE
pod/nginxpod 0/1 ContainerCreating 0 12s
[root@CentOS8Shaowenhua ~]#
这样就显示了两个资源对象的信息
（4）执行delete命令，删除资源：
[root@CentOS8Shaowenhua ~]# kubectl delete -f nginxpod.yaml
namespace "dev" deleted
pod "nginxpod" deleted
此时发现两个资源对象被删除了
总结：命令式对象配置的方式操作资源，可以简单的认为：命令 + yaml配置文件（里面是命令需要的各种参数
6、声明式对象配置
声明式对象配置跟命令式对象配置很相似，但是它只有一个命令apply。
# 首先执行一次kubectl apply -f yaml文件，发现创建了资源
[root@CentOS8Shaowenhua ~]# kubectl apply -f nginxpod.yaml
namespace/dev created
pod/nginxpod created
# 再次执行一次kubectl apply -f yaml文件，发现说资源没有变动
[root@CentOS8Shaowenhua ~]# kubectl apply -f nginxpod.yaml
namespace/dev unchanged
pod/nginxpod unchanged
[root@CentOS8Shaowenhua ~]#
总结:
其实声明式对象配置就是使用apply描述一个资源最终的状态（在yaml中定义状态）
使用apply操作资源：
如果资源不存在，就创建，相当于 kubectl create
如果资源已存在，就更新，相当于 kubectl patch
扩展1：kubectl可以在node节点上运行吗 ?
kubectl的运行是需要进行配置的，它的配置文件是$HOME/.kube，如果想要在node节点运行此命令，需要将master上的.kube文件复制到node节点上，即在master节点上执行下面操作：
scp -r HOME/.kube node1: HOME/
使用推荐: 三种方式应该怎么用 ?
- 创建/更新资源 使用声明式对象配置 kubectl apply -f XXX.yaml
- 删除资源 使用命令式对象配置 kubectl delete -f XXX.yaml
- 查询资源 使用命令式对象管理 kubectl get(describe) 资源名称
二、Namespace+Pod+Deployment
1、Namespace
Namespace是kubernetes系统中的一种非常重要资源，它的主要作用是用来实现多套环境的资源隔离或者多租户的资源隔离。
默认情况下，kubernetes集群中的所有的Pod都是可以相互访问的。但是在实际中，可能不想让两个Pod之间进行互相的访问，那此时就可以将两个Pod划分到不同的namespace下。kubernetes通过将集群内部的资源分配到不同的Namespace中，可以形成逻辑上的"组"，以方便不同的组的资源进行隔离使用和管理。
可以通过kubernetes的授权机制，将不同的namespace交给不同租户进行管理，这样就实现了多租户的资源隔离。此时还能结合kubernetes的资源配额机制，限定不同租户能占用的资源，例如CPU使用量、内存使用量等等，来实现租户可用资源的管理。
（1）默认创建
kubernetes在集群启动之后，会默认创建几个namespace
[root@CentOS8Shaowenhua ~]# kubectl get namespace
NAME STATUS AGE
default Active 41h
kube-flannel Active 40h
kube-node-lease Active 41h
kube-public Active 41h
kube-system Active 41h
[root@CentOS8Shaowenhua ~]#
（2）namespace资源的具体操作
#<1># 查看所有的ns 命令：kubectl get ns
[root@CentOS8Shaowenhua ~]# kubectl get ns
NAME STATUS AGE
default Active 41h
kube-flannel Active 40h
kube-node-lease Active 41h
kube-public Active 41h
kube-system Active 41h
[root@CentOS8Shaowenhua ~]#
#<2># 查看指定的ns 命令：kubectl get ns ns名称
[root@CentOS8Shaowenhua ~]# kubectl get ns default
NAME STATUS AGE
default Active 41h
#<3># 指定输出格式 命令：kubectl get ns ns名称 -o 格式参数
# kubernetes支持的格式有很多，比较常见的是wide、json、yaml
[root@CentOS8Shaowenhua ~]# kubectl get ns default -o yaml
apiVersion: v1
kind: Namespace
metadata:
creationTimestamp: "2024-05-05T11:57:34Z"
labels:
kubernetes.io/metadata.name: default
name: default
resourceVersion: "12"
uid: 85e104c4-9fb4-40b5-8d92-8c3639faea1b
spec:
finalizers:
- kubernetes
status:
phase: Active
[root@CentOS8Shaowenhua ~]#
#<4> 查看ns详情 命令：kubectl describe ns ns名称
[root@CentOS8Shaowenhua ~]# kubectl describe ns default
Name: default
Labels: kubernetes.io/metadata.name=default
Annotations: <none>
Status: Active # Active 命名空间正在使用中 Terminating 正在删除命名空间
No resource quota.
No LimitRange resource.
[root@CentOS8Shaowenhua ~]#
# ResourceQuota 针对namespace做的资源限制
# LimitRange针对namespace中的每个组件做的资源限制
No resource quota.
No LimitRange resource.
2、Pod
Pod是kubernetes集群进行管理的最小单元，程序要运行必须部署在容器中，而容器必须存在于Pod中。
Pod可以认为是容器的封装，一个Pod中可以存在一个或者多个容器。
（1）Pod方式运行的组件
kubernetes在集群启动之后，集群中的各个组件也都是以Pod方式运行的。可以通过下面命令查看：
[root@CentOS8Shaowenhua ~]# kubectl get pod -n kube-system
NAME READY STATUS RESTARTS AGE
coredns-66f779496c-6nk25 1/1 Running 1 (88m ago) 41h
coredns-66f779496c-chmlg 1/1 Running 1 (88m ago) 41h
etcd-centos8shaowenhua 1/1 Running 1 (88m ago) 41h
kube-apiserver-centos8shaowenhua 1/1 Running 1 (88m ago) 41h
kube-controller-manager-centos8shaowenhua 1/1 Running 1 (88m ago) 41h
kube-proxy-4dbwn 1/1 Running 1 (87m ago) 40h
kube-proxy-bw6q9 1/1 Running 1 (87m ago) 40h
kube-proxy-kzhtv 1/1 Running 1 (88m ago) 41h
kube-scheduler-centos8shaowenhua 1/1 Running 1 (88m ago) 41h
[root@CentOS8Shaowenhua ~]#
（2）创建并运行
kubernetes没有提供单独运行Pod的命令，都是通过Pod控制器来实现的
命令格式： kubectl run (pod控制器名称) [参数]
--image 指定Pod的镜像
--port 指定端口
--namespace 指定namespace
[root@CentOS8Shaowenhua ~]# kubectl create namespace dev
namespace/dev created
[root@CentOS8Shaowenhua ~]# kubectl run nginx --image=nginx:latest --port=80 --namespace dev
pod/nginx created
[root@CentOS8Shaowenhua ~]#
（3）查看pod信息
#<1># 查看Pod基本信息
[root@CentOS8Shaowenhua ~]# kubectl get pods -n dev
NAME READY STATUS RESTARTS AGE
nginx 1/1 Running 0 74s
#<2># 查看Pod的详细信息
[root@CentOS8Shaowenhua ~]# kubectl describe pod nginx -n dev
Name: nginx
Namespace: dev
Priority: 0
Service Account: default
Node: docker2/192.168.27.135
Start Time: Tue, 07 May 2024 13:35:57 +0800
Labels: run=nginx
Annotations: <none>
Status: Running
IP: 10.244.2.5
IPs:
IP: 10.244.2.5
Containers:
nginx:
Container ID: containerd://4bdd9cca20eb8686c4e394b76460175970e5917ef1d925fabda44b98f234a745
Image: nginx:latest
Image ID: docker.io/library/nginx@sha256:32e76d4f34f80e479964a0fbd4c5b4f6967b5322c8d004e9cf0cb81c93510766
Port: 80/TCP
Host Port: 0/TCP
State: Running
Started: Tue, 07 May 2024 13:36:17 +0800
Ready: True
Restart Count: 0
Environment: <none>
Mounts:
/var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-vfl94 (ro)
Conditions:
Type Status
Initialized True
Ready True
ContainersReady True
PodScheduled True
Volumes:
kube-api-access-vfl94:
Type: Projected (a volume that contains injected data from multiple sources)
TokenExpirationSeconds: 3607
ConfigMapName: kube-root-ca.crt
ConfigMapOptional: <nil>
DownwardAPI: true
QoS Class: BestEffort
Node-Selectors: <none>
Tolerations: node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled 83s default-scheduler Successfully assigned dev/nginx to docker2
Normal Pulling 82s kubelet Pulling image "nginx:latest"
Normal Pulled 64s kubelet Successfully pulled image "nginx:latest" in 18.197s (18.198s including waiting)
Normal Created 63s kubelet Created container nginx
Normal Started 63s kubelet Started container nginx
[root@CentOS8Shaowenhua ~]#
（4）访问Pod
#<1># 获取podIP
[root@CentOS8Shaowenhua ~]# kubectl get pods -n dev -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
nginx 1/1 Running 0 2m57s 10.244.2.5 docker2 <none> <none>
#<2># 访问POD
[root@CentOS8Shaowenhua ~]# curl http://10.244.2.5:80
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
html { color-scheme: light dark; }
body { width: 35em; margin: 0 auto;
font-family: Tahoma, Verdana, Arial, sans-serif; }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>
<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>
<p><em>Thank you for using nginx.</em></p>
</body>
</html>
[root@CentOS8Shaowenhua ~]#
（5）删除指定Pod
# 删除指定Pod
[root@CentOS8Shaowenhua ~]# kubectl delete pod nginx -n dev
pod "nginx" deleted
# 此时，显示删除Pod成功，但是再查询，发现又新产生了一个
[root@CentOS8Shaowenhua ~]# kubectl get pods -n dev
NAME READY STATUS RESTARTS AGE
nginx 1/1 Running 0 21s
# 这是因为当前Pod是由Pod控制器创建的，控制器会监控Pod状况，一旦发现Pod死亡，会立即重建
# 此时要想删除Pod，必须删除Pod控制器
# 先来查询一下当前namespace下的Pod控制器
[root@CentOS8Shaowenhua ~]# kubectl get deploy -n dev
NAME READY UP-TO-DATE AVAILABLE AGE
nginx 1/1 1 1 9m7s
# 接下来，删除此PodPod控制器
[root@CentOS8Shaowenhua ~]# kubectl delete deploy nginx -n dev
deployment.apps "nginx" deleted
# 稍等片刻，再查询Pod，发现Pod被删除了
[root@CentOS8Shaowenhua ~]# kubectl get pods -n dev
No resources found in dev namespace.
（6）配置操作
[root@CentOS8Shaowenhua ~]# vi pod-nginx.yaml
[root@CentOS8Shaowenhua ~]# cat pod-nginx.yaml
apiVersion: v1
kind: Pod
metadata:
name: nginx
namespace: dev
spec:
containers:
- image: nginx:latest
name: pod
ports:
- name: nginx-port
containerPort: 80
protocol: TCP
[root@CentOS8Shaowenhua ~]# kubectl create -f pod-nginx.yaml
pod/nginx created
[root@CentOS8Shaowenhua ~]# kubectl delete -f pod-nginx.yaml
pod "nginx" deleted
[root@CentOS8Shaowenhua ~]# ls
anaconda-ks.cfg k8s kube-flannel.yml pod-nginx.yaml
[root@CentOS8Shaowenhua ~]#
3、Label
Label是kubernetes系统中的一个重要概念。它的作用就是在资源上添加标识，用来对它们进行区分和选择。
（1）Label的特点：
- 一个Label会以key/value键值对的形式附加到各种对象上，如Node、Pod、Service等等
- 一个资源对象可以定义任意数量的Label ，同一个Label也可以被添加到任意数量的资源对象上去
- Label通常在资源对象定义时确定，当然也可以在对象创建后动态添加或者删除
可以通过Label实现资源的多维度分组，以便灵活、方便地进行资源分配、调度、配置、部署等管理工作。
一些常用的Label 示例如下：
- 版本标签：“version”:“release”, “version”:“stable”…
- 环境标签：“environment”:“dev”，“environment”:“test”，“environment”:“pro”
- 架构标签：“tier”:“frontend”，“tier”:“backend”
标签定义完毕之后，还要考虑到标签的选择，这就要使用到Label Selector，即：
Label用于给某个资源对象定义标识
Label Selector用于查询和筛选拥有某些标签的资源对象
当前有两种Label Selector：
基于等式的Label Selector
name = slave: 选择所有包含Label中key="name"且value="slave"的对象
env != production: 选择所有包括Label中的key="env"且value不等于"production"的对象
基于集合的Label Selector
name in (master, slave): 选择所有包含Label中的key="name"且value="master"或"slave"的对象
name not in (frontend): 选择所有包含Label中的key="name"且value不等于"frontend"的对象
标签的选择条件可以使用多个，此时将多个Label Selector进行组合，使用逗号","进行分隔即可。例如：
name=slave，env!=production
name not in (frontend)，env!=production
（2）命令方式
# 为pod资源打标签
[root@CentOS8Shaowenhua ~]# kubectl label pod nginx-pod version=1.0 -n dev
pod/nginx-pod labeled
# 为pod资源更新标签
[root@CentOS8Shaowenhua ~]# kubectl label pod nginx-pod version=2.0 -n dev --overwrite
pod/nginx-pod labeled
# 查看标签
[root@CentOS8Shaowenhua ~]# kubectl get pod nginx-pod -n dev --show-labels
NAME READY STATUS RESTARTS AGE LABELS
nginx-pod 1/1 Running 0 10m version=2.0
# 筛选标签
[root@CentOS8Shaowenhua ~]# kubectl get pod -n dev -l version=2.0 --show-labels
NAME READY STATUS RESTARTS AGE LABELS
nginx-pod 1/1 Running 0 17m version=2.0
[root@CentOS8Shaowenhua ~]# kubectl get pod -n dev -l version!=2.0 --show-labels
No resources found in dev namespace.
# 删除标签
[root@CentOS8Shaowenhua ~]# kubectl label pod nginx-pod version- -n dev
pod/nginx-pod labeled
（3）配置方式
[root@CentOS8Shaowenhua yamls]# vi pod-nginx.yaml
[root@CentOS8Shaowenhua yamls]# cat pod-nginx.yaml
apiVersion: v1
kind: Pod
metadata:
name: nginx
namespace: dev
labels:
version: "3.0"
env: "test"
spec:
containers:
- image: nginx:latest
name: pod
ports:
- name: nginx-port
containerPort: 80
protocol: TCP
[root@CentOS8Shaowenhua yamls]# kubectl apply -f pod-nginx.yaml
4、Deployment
在kubernetes中，Pod是最小的控制单元，但是kubernetes很少直接控制Pod，一般都是通过Pod控制器来完成的。Pod控制器用于pod的管理，确保pod资源符合预期的状态，当pod的资源出现故障时，会尝试进行重启或重建pod。
在kubernetes中Pod控制器的种类有很多，本章节只介绍一种：Deployment。
（1）配置
[root@CentOS8Shaowenhua yamls]# vi deploy-nginx.yaml
[root@CentOS8Shaowenhua yamls]# cat deploy-nginx.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx
namespace: dev
spec:
replicas: 3
selector:
matchLabels:
run: nginx
template:
metadata:
labels:
run: nginx
spec:
containers:
- image: nginx:latest
name: nginx
ports:
- containerPort: 80
protocol: TCP
[root@CentOS8Shaowenhua yamls]# kubectl create -f deploy-nginx.yaml
deployment.apps/nginx created
（2）命令格式
# 命令格式: kubectl create deployment 名称 [参数]
# --image 指定pod的镜像
# --port 指定端口
# --namespace 指定namespace
[root@CentOS8Shaowenhua yamls]# kubectl run nginx --image=nginx:latest --port=80 -n dev
pod/nginx created
# 查看创建的Pod
[root@CentOS8Shaowenhua yamls]# kubectl get pods -n dev
NAME READY STATUS RESTARTS AGE
nginx 1/1 Running 0 28s
# 查看deployment的信息
[root@CentOS8Shaowenhua yamls]# kubectl get deploy -n dev
NAME READY UP-TO-DATE AVAILABLE AGE
nginx 0/3 3 0 3s
# UP-TO-DATE：成功升级的副本数量
# AVAILABLE：可用副本的数量
[root@CentOS8Shaowenhua yamls]# kubectl get deploy -n dev -o wide
NAME READY UP-TO-DATE AVAILABLE AGE CONTAINERS IMAGES SELECTOR
nginx 2/3 3 2 22s nginx nginx:latest run=nginx
# 查看deployment的详细信息
[root@CentOS8Shaowenhua yamls]# kubectl describe deploy nginx -n dev
Name: nginx
Namespace: dev
CreationTimestamp: Tue, 07 May 2024 14:09:07 +0800
Labels: <none>
Annotations: deployment.kubernetes.io/revision: 1
Selector: run=nginx
Replicas: 3 desired | 3 updated | 3 total | 2 available | 1 unavailable
StrategyType: RollingUpdate
MinReadySeconds: 0
RollingUpdateStrategy: 25% max unavailable, 25% max surge
Pod Template:
Labels: run=nginx
Containers:
nginx:
Image: nginx:latest
Port: 80/TCP
Host Port: 0/TCP
Environment: <none>
Mounts: <none>
Volumes: <none>
Conditions:
Type Status Reason
---- ------ ------
Available False MinimumReplicasUnavailable
Progressing True ReplicaSetUpdated
OldReplicaSets: <none>
NewReplicaSet: nginx-6c45cbd8c5 (3/3 replicas created)
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal ScalingReplicaSet 30s deployment-controller Scaled up replica set nginx-6c45cbd8c5 to 3
三、Service
- 在kubernetes中，pod是应用程序的载体，我们可以通过pod的ip来访问应用程序，但是pod的ip地址不是固定的，这也就意味着不方便直接采用pod的ip对服务进行访问。
- 为了解决这个问题，kubernetes提供了Service资源，Service会对提供同一个服务的多个pod进行聚合，并且提供一个统一的入口地址。通过访问Service的入口地址就能访问到后面的pod服务。
- Service在很多情况下只是一个概念，真正起作用的其实是kube-proxy服务进程，每个Node节点上都运行着一个kube-proxy服务进程。当创建Service的时候会通过api-server向etcd写入创建的service的信息，而kube-proxy会基于监听的机制发现这种Service的变动，然后它会将最新的Service信息转换成对应的访问规则。
1、kube-proxy目前支持三种工作模式:
（1）userspace 模式
userspace模式下，kube-proxy会为每一个Service创建一个监听端口，发向Cluster IP的请求被Iptables规则重定向到kube-proxy监听的端口上，kube-proxy根据LB算法选择一个提供服务的Pod并和其建立链接，以将请求转发到Pod上。 该模式下，kube-proxy充当了一个四层负责均衡器的角色。由于kube-proxy运行在userspace中，在进行转发处理时会增加内核和用户空间之间的数据拷贝，虽然比较稳定，但是效率比较低。
（2）iptables 模式
iptables模式下，kube-proxy为service后端的每个Pod创建对应的iptables规则，直接将发向Cluster IP的请求重定向到一个Pod IP。 该模式下kube-proxy不承担四层负责均衡器的角色，只负责创建iptables规则。该模式的优点是较userspace模式效率更高，但不能提供灵活的LB策略，当后端Pod不可用时也无法进行重试。
（3）ipvs 模式
ipvs模式和iptables类似，kube-proxy监控Pod的变化并创建相应的ipvs规则。ipvs相对iptables转发效率更高。除此以外，ipvs支持更多的LB算法。
# 10.97.97.97:80 是service提供的访问入口
# 当访问这个入口的时候，可以发现后面有三个pod的服务在等待调用，
# kube-proxy会基于rr（轮询）的策略，将请求分发到其中一个pod上去
# 这个规则会同时在集群内的所有节点上都生成，所以在任何一个节点，访问都可以。
[root@CentOS8Shaowenhua yamls]# ipvsadm -Ln
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 172.17.0.1:32300 rr
-> 10.244.1.3:80 Masq 1 0 0
TCP 192.168.27.128:32300 rr
-> 10.244.1.3:80 Masq 1 0 0
TCP 10.96.0.1:443 rr
-> 192.168.27.128:6443 Masq 1 0 0
TCP 10.96.0.10:53 rr
-> 10.244.0.4:53 Masq 1 0 0
-> 10.244.0.5:53 Masq 1 0 0
TCP 10.96.0.10:9153 rr
-> 10.244.0.4:9153 Masq 1 0 0
-> 10.244.0.5:9153 Masq 1 0 0
TCP 10.98.50.119:80 rr
-> 10.244.1.3:80 Masq 1 0 0
TCP 10.244.0.0:32300 rr
-> 10.244.1.3:80 Masq 1 0 0
TCP 10.244.0.1:32300 rr
-> 10.244.1.3:80 Masq 1 0 0
UDP 10.96.0.10:53 rr
-> 10.244.0.4:53 Masq 1 0 0
-> 10.244.0.5:53 Masq 1 0 0
# 此模式必须安装ipvs内核模块，否则会降级为iptables
# 开启ipvs
[root@CentOS8Shaowenhua yamls]# kubectl edit cm kube-proxy -n kube-system
configmap/kube-proxy edited
# 修改mode: "ipvs"
[root@CentOS8Shaowenhua yamls]# kubectl delete pod -l k8s-app=kube-proxy -n kube-system
pod "kube-proxy-4dbwn" deleted
pod "kube-proxy-bw6q9" deleted
pod "kube-proxy-kzhtv" deleted
[root@CentOS8Shaowenhua yamls]# ipvsadm -Ln
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 172.17.0.1:32300 rr
-> 10.244.1.3:80 Masq 1 0 0
TCP 192.168.27.128:32300 rr
-> 10.244.1.3:80 Masq 1 0 0
TCP 10.96.0.1:443 rr
-> 192.168.27.128:6443 Masq 1 0 0
TCP 10.96.0.10:53 rr
-> 10.244.0.4:53 Masq 1 0 0
-> 10.244.0.5:53 Masq 1 0 0
TCP 10.96.0.10:9153 rr
-> 10.244.0.4:9153 Masq 1 0 0
-> 10.244.0.5:9153 Masq 1 0 0
TCP 10.98.50.119:80 rr
-> 10.244.1.3:80 Masq 1 0 0
TCP 10.244.0.0:32300 rr
-> 10.244.1.3:80 Masq 1 0 0
TCP 10.244.0.1:32300 rr
-> 10.244.1.3:80 Masq 1 0 0
UDP 10.96.0.10:53 rr
-> 10.244.0.4:53 Masq 1 0 0
-> 10.244.0.5:53 Masq 1 0 0
[root@CentOS8Shaowenhua yamls]#
2、Service类型
kind: Service # 资源类型
apiVersion: v1 # 资源版本
metadata: # 元数据
name: service # 资源名称
namespace: dev # 命名空间
spec: # 描述
selector: # 标签选择器，用于确定当前service代理哪些pod
app: nginx
type: # Service类型，指定service的访问方式
clusterIP: # 虚拟服务的ip地址
sessionAffinity: # session亲和性，支持ClientIP、None两个选项
ports: # 端口信息
- protocol: TCP
port: 3017 # service端口
targetPort: 5003 # pod端口
nodePort: 31122 # 主机端口
- ClusterIP：默认值，它是Kubernetes系统自动分配的虚拟IP，只能在集群内部访问
- NodePort：将Service通过指定的Node上的端口暴露给外部，通过此方法，就可以在集群外部访问服务
- LoadBalancer：使用外接负载均衡器完成到服务的负载分发，注意此模式需要外部云环境支持
- ExternalName： 把集群外部的服务引入集群内部，直接使用
3、Service使用
在使用service之前，首先利用Deployment创建出3个pod，注意要为pod设置app=nginx-pod的标签
（1）创建deployment.yaml
内容如下：
[root@CentOS8Shaowenhua yamls]# vi deployment.yaml
[root@CentOS8Shaowenhua yamls]# cat deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: pc-deployment
namespace: dev
spec:
replicas: 3
selector:
matchLabels:
app: nginx-pod
template:
metadata:
labels:
app: nginx-pod
spec:
containers:
- name: nginx
image: nginx:1.17.1
ports:
- containerPort: 80
（2）create
[root@CentOS8Shaowenhua yamls]# kubectl create -f deployment.yaml
deployment.apps/pc-deployment created
# 查看pod详情
[root@CentOS8Shaowenhua yamls]# kubectl get pods -n dev -o wide --show-labels
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES LABELS
nginx 1/1 Running 0 39m 10.244.2.8 docker2 <none> <none> run=nginx
nginx-6c45cbd8c5-5fcw8 1/1 Running 0 34m 10.244.2.9 docker2 <none> <none> pod-template-hash=6c45cbd8c5,run=nginx
nginx-6c45cbd8c5-tq9vf 1/1 Running 0 34m 10.244.1.5 docker1 <none> <none> pod-template-hash=6c45cbd8c5,run=nginx
nginx-6c45cbd8c5-wz5jl 1/1 Running 0 34m 10.244.1.4 docker1 <none> <none> pod-template-hash=6c45cbd8c5,run=nginx
pc-deployment-5cb65f68db-c76dz 1/1 Running 0 7m48s 10.244.2.11 docker2 <none> <none> app=nginx-pod,pod-template-hash=5cb65f68db
pc-deployment-5cb65f68db-nqntj 1/1 Running 0 7m48s 10.244.2.10 docker2 <none> <none> app=nginx-pod,pod-template-hash=5cb65f68db
pc-deployment-5cb65f68db-tqj6r 1/1 Running 0 7m48s 10.244.1.6 docker1 <none> <none> app=nginx-pod,pod-template-hash=5cb65f68db
# 修改下三台nginx的index.html页面（三台修改的IP地址不一致）
[root@CentOS8Shaowenhua yamls]# kubectl exec -it pc-deployment-5cb65f68db-c76dz -n dev /bin/sh
kubectl exec [POD] [COMMAND] is DEPRECATED and will be removed in a future version. Use kubectl exec [POD] -- [COMMAND] instead.
# echo "10.244.2.11" > /usr/share/nginx/html/index.html
# exit
[root@CentOS8Shaowenhua yamls]# curl 10.244.2.11
10.244.2.11
[root@CentOS8Shaowenhua yamls]# kubectl exec -it pc-deployment-5cb65f68db-nqntj -n dev /bin/sh
kubectl exec [POD] [COMMAND] is DEPRECATED and will be removed in a future version. Use kubectl exec [POD] -- [COMMAND] instead.
# echo "10.244.2.10" > /usr/share/nginx/html/index.html
# exit
[root@CentOS8Shaowenhua yamls]# curl 10.244.2.10
10.244.2.10
[root@CentOS8Shaowenhua yamls]# kubectl exec -it pc-deployment-5cb65f68db-tqj6r -n dev /bin/sh
kubectl exec [POD] [COMMAND] is DEPRECATED and will be removed in a future version. Use kubectl exec [POD] -- [COMMAND] instead.
# echo "10.244.1.6" > /usr/share/nginx/html/index.html
# exit
[root@CentOS8Shaowenhua yamls]# curl 10.244.1.6
10.244.1.6
[root@CentOS8Shaowenhua yamls]#
三、Volume数据存储
- 容器的生命周期可能很短，会被频繁地创建和销毁。那么容器在销毁时，保存在容器中的数据也会被清除。这种结果对用户来说，在某些情况下是不乐意看到的。为了持久化保存容器的数据，kubernetes引入了Volume的概念。
- Volume是Pod中能够被多个容器访问的共享目录，它被定义在Pod上，然后被一个Pod里的多个容器挂载到具体的文件目录下，kubernetes通过Volume实现同一个Pod中不同容器之间的数据共享以及数据的持久化存储。Volume的生命容器不与Pod中单个容器的生命周期相关，当容器终止或者重启时，Volume中的数据也不会丢失。
kubernetes的Volume支持多种类型，比较常见的有下面几个：
- 简单存储：EmptyDir、HostPath、NFS
- 高级存储：PV、PVC
- 配置存储：ConfigMap、Secret
1、EmptyDir
-
EmptyDir是最基础的Volume类型，一个EmptyDir就是Host上的一个空目录。
-
EmptyDir是在Pod被分配到Node时创建的，它的初始内容为空，并且无须指定宿主机上对应的目录文件，因为kubernetes会自动分配一个目录，当Pod销毁时， EmptyDir中的数据也会被永久删除。 EmptyDir用途如下：
临时空间，例如用于某些应用程序运行时所需的临时目录，且无须永久保留
一个容器需要从另一个容器中获取数据的目录（多容器共享目录）
-
接下来，通过一个容器之间文件共享的案例来使用一下EmptyDir。
（1）创建一个volume-emptydir.yaml
[root@CentOS8Shaowenhua yamls]# vi volume-emptydir.yaml
[root@CentOS8Shaowenhua yamls]# cat volume-emptydir.yaml
apiVersion: v1
kind: Pod
metadata:
name: volume-emptydir
namespace: dev
spec:
containers:
- name: nginx
image: nginx:1.17.1
ports:
- containerPort: 80
volumeMounts: # 将logs-volume挂在到nginx容器中，对应的目录为/var/log/nginx
- name: logs-volume
mountPath: /var/log/nginx
- name: busybox
image: busybox:1.30
command: ["/bin/sh","-c","tail -f /logs/access.log"] # 初始命令，动态读取指定文件中内容
volumeMounts: # 将logs-volume 挂在到busybox容器中，对应的目录为/logs
- name: logs-volume
mountPath: /logs
volumes: # 声明volume， name为logs-volume，类型为emptyDir
- name: logs-volume
emptyDir: {}
[root@CentOS8Shaowenhua yamls]#
# 创建Pod
[root@CentOS8Shaowenhua yamls]# kubectl create -f volume-emptydir.yaml
pod/volume-emptydir created
# 查看pod
[root@CentOS8Shaowenhua yamls]# kubectl get pods volume-emptydir -n dev -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
volume-emptydir 0/2 ContainerCreating 0 20s <none> docker1 <none> <none>
# 通过podIp访问nginx
[root@CentOS8Shaowenhua yamls]# curl 10.224.2.14
......
2、HostPath
EmptyDir中数据不会被持久化，它会随着Pod的结束而销毁，如果想简单的将数据持久化到主机中，可以选择HostPath。
HostPath就是将Node主机中一个实际目录挂在到Pod中，以供容器使用，这样的设计就可以保证Pod销毁了，但是数据依据可以存在于Node主机上。
（1）创建一个volume-hostpath.yaml
apiVersion: v1
kind: Pod
metadata:
name: volume-hostpath
namespace: dev
spec:
containers:
- name: nginx
image: nginx:1.17.1
ports:
- containerPort: 80
volumeMounts:
- name: logs-volume
mountPath: /var/log/nginx
- name: busybox
image: busybox:1.30
command: ["/bin/sh","-c","tail -f /logs/access.log"]
volumeMounts:
- name: logs-volume
mountPath: /logs
volumes:
- name: logs-volume
hostPath:
path: /root/logs
type: DirectoryOrCreate # 目录存在就使用，不存在就先创建后使用
同样的道理进行测试
3、NFS
HostPath可以解决数据持久化的问题，但是一旦Node节点故障了，Pod如果转移到了别的节点，又会出现问题了，此时需要准备单独的网络存储系统，比较常用的用NFS、CIFS。
NFS是一个网络文件存储系统，可以搭建一台NFS服务器，然后将Pod中的存储直接连接到NFS系统上，这样的话，无论Pod在节点上怎么转移，只要Node跟NFS的对接没问题，数据就可以成功访问。
（1）创建volume-nfs.yaml
apiVersion: v1
kind: Pod
metadata:
name: volume-nfs
namespace: dev
spec:
containers:
- name: nginx
image: nginx:1.17.1
ports:
- containerPort: 80
volumeMounts:
- name: logs-volume
mountPath: /var/log/nginx
- name: busybox
image: busybox:1.30
command: ["/bin/sh","-c","tail -f /logs/access.log"]
volumeMounts:
- name: logs-volume
mountPath: /logs
volumes:
- name: logs-volume
nfs:
server: 192.168.5.6 #nfs服务器地址
path: /root/data/nfs #共享文件路径
4、补充
前面已经学习了使用NFS提供存储，此时就要求用户会搭建NFS系统，并且会在yaml配置nfs。由于kubernetes支持的存储系统有很多，要求客户全都掌握，显然不现实。为了能够屏蔽底层存储实现的细节，方便用户使用， kubernetes引入PV和PVC两种资源对象。
- PV（Persistent Volume）是持久化卷的意思，是对底层的共享存储的一种抽象。一般情况下PV由kubernetes管理员进行创建和配置，它与底层具体的共享存储技术有关，并通过插件完成与共享存储的对接。
- PVC（Persistent Volume Claim）是持久卷声明的意思，是用户对于存储需求的一种声明。换句话说，PVC其实就是用户向kubernetes系统发出的一种资源需求申请。
使用了PV和PVC之后，工作可以得到进一步的细分：
- 存储：存储工程师维护
- PV： kubernetes管理员维护
- PVC：kubernetes用户维护
