Day22_K8S

文章目录

3.资源管理方式
- - - 通过命令管理
    - 通过配置文件管理
4. 基本概念入门
- - 4.1 Namespace
  - 4.2 Pod
  - 4.3 Label
  - 4.4 Deployment
  - 4.5 Service
5. Pod详解
- - 5.1 Pod介绍
  - 5.2 Pod配置
  - 5.3 Pod生命周期
  - - 5.3.1 初始化容器
    - 5.3.2 钩子函数
    - 5.3.3 容器探测
    - 5.3.4 重启策略
  - 5.4 Pod调度
  - - 5.4.1 定向调度
    - 5.4.2 亲和性调度
    - 5.4.3 污点和容忍
6. Pod控制器详解
- - 6.1 Pod控制器介绍
  - 6.2 ReplicaSet(RS)
  - 6.3 Deployment(Deploy)
  - 6.4 HPA
  - 6.5 DaemonSet(DS)
  - 6.6 Job
  - 6.7 CronJob(CJ)
7. Service详解
- - 7.1 Service介绍
  - - 7.1.1 userspace 模式
    - 7.1.2 iptables 模式
    - 7.1.3 ipvs 模式
  - 7.2 Service类型
  - 7.3 Service使用
  - - 7.3.1 实验环境准备
    - 7.3.2 ClusterIP类型的Service
    - 7.3.3 NodePort类型的Service
    - 7.3.4 LoadBalancer类型的Service
  - 7.4 Ingress介绍
  - 7.5 Ingress使用
  - - 7.5.1 环境准备搭建ingress环境
    - 7.5.2 准备service和pod
    - 7.5.3 Http代理
    - 7.5.4 Https代理
8. 数据存储
- - 8.1 基本存储
  - - 8.1.1 EmptyDir
    - 8.1.2 HostPath
    - 8.1.3 NFS
  - 8.2 高级存储—PV和PVC
  - 8.3 配置存储
  - - 8.3.1 ConfigMap
    - 8.3.2 Secret

3.资源管理方式

通过命令管理

直接使用命令去操作kubernetes资源

# 啥时候用命令式对象管理？当我们查询资源、分析资源时经常用命令方式去管理对象

kubectl top nodes

kubectl get pods -n dev

kubectl describe pod nginx -n dev

通过配置文件管理

①创建一个nginxpod.yaml，内容如下：

apiVersion: v1
kind: Pod
metadata:
  name: nginxpod
  namespace: dev
spec:
  containers:
  - name: nginx-containers
    image: nginx:latest

②通过命令配置去创建资源

# create是创建 
kubectl create -f nginx-pod.yaml

# patch是更新
kubectl patch -f nginx-pod.yaml

# 删除
kubectl delete -f nginxpod.yaml

③也可以通过apply命令

# apply就包含create创建和patch更新，如果没有就create，如果有就patch更新
kubectl apply -f nginx-pod.yaml


总结:
    其实声明式对象配置就是使用apply描述一个资源最终的状态（在yaml中定义状态）
    使用apply操作资源：
        如果资源不存在，就创建，相当于 kubectl create
        如果资源已存在，就更新，相当于 kubectl patch

4. 基本概念入门

4.1 Namespace

Namespace是kubernetes系统中的一种非常重要资源，它的主要作用是用来实现多套环境的资源隔离或者多租户的资源隔离。

一句话来讲：比如你弄两个namespace分别代表开发环境和测试环境，在不同namespace里面限制CPU使用量、内存使用量等等，然后将不同的namespace交给不同租户进行管理（限制不同租户的访问权限），那么就实现**多套环境的资源隔离**或者**多租户的资源隔离**。

1》命令方式

# 创建namespace
[root@master ~]# kubectl create ns dev

# 删除namespace
[root@master ~]# kubectl delete ns dev

# 以yaml格式输出，还支持wide、json、yaml
[root@master ~]# kubectl get ns default -o yaml

# 查看ns详情
[root@master ~]# kubectl describe ns default

2》配置方式

首先准备一个yaml文件：ns-dev.yaml

apiVersion: v1
kind: Namespace
metadata:
  name: dev

然后就可以执行对应的创建和删除命令了：

创建：kubectl create -f ns-dev.yaml

删除：kubectl delete -f ns-dev.yaml

4.2 Pod

在kubernetes的世界中，k8s并不直接处理容器，而是直接管理pod。

Pod是kubernetes集群进行管理的最小单元，程序要运行必须部署在容器中，而容器必须存在于Pod中。

Pod可以认为是容器的封装，一个Pod中可以存在一个或者多个容器。

1》命令方式

# 查看Pod基本信息
[root@master ~]# kubectl get pods -n dev

# 获取podIP
[root@master ~]# kubectl get pods -n dev -o wide
NAME    READY   STATUS    RESTARTS   AGE    IP             NODE    ... 
nginx   1/1     Running   0          190s   10.244.1.23   node1   ...

# 查看Pod的详细信息
[root@master ~]# kubectl describe pod nginx -n dev

2》配置操作

创建一个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

然后就可以执行对应的创建和删除命令了：

创建：kubectl create -f pod-nginx.yaml

删除：kubectl delete -f pod-nginx.yaml

4.3 Label

我们可以使用namespace来分组，但是不同的namespace下面的pod又无法直接通信，所以可以使用lable来实现分组，而且不同分组的pod还可以通信。

Label的特点：

一个Label会以key/value键值对的形式附加到各种对象上，如Node、Pod、Service等等
一个资源对象可以定义任意数量的Label ，同一个Label也可以被添加到任意数量的资源对象上去

一些常用的Label 示例如下：

版本标签：“version”:“release”, “version”:“stable”…

环境标签：“environment”:“dev”，“environment”:“test”，“environment”:“pro”

架构标签：“tier”:“frontend”，“tier”:“backend”

标签定义完毕之后，还要考虑到标签的选择，这就要使用到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"的对象

1》命令方式添加标签

# 为pod资源打标签
[root@master ~]# kubectl label pod nginx-pod version=1.0 -n dev
pod/nginx-pod labeled

# 为pod资源更新标签
[root@master ~]# kubectl label pod nginx-pod version=2.0 -n dev --overwrite
pod/nginx-pod labeled

# 查看标签
[root@master ~]# 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@master ~]# 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@master ~]# kubectl get pod -n dev -l version!=2.0 --show-labels
No resources found in dev namespace.

#删除标签
[root@master ~]# kubectl label pod nginx-pod version- -n dev
pod/nginx-pod labeled

2》配置方式（创建时就打上标签）

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

然后就可以执行对应的更新命令了：kubectl apply -f pod-nginx.yaml

4.4 Deployment

在kubernetes中，Pod是最小的控制单元，但是kubernetes很少直接控制Pod，一般都是通过Pod控制器来完成的。Pod控制器用于pod的管理，确保pod资源符合预期的状态，当pod的资源出现故障时，会尝试进行重启或重建pod。（这就是为什么你之前删除pod是删不掉的，你必须删掉控制器才行）

在kubernetes中Pod控制器的种类有很多，本章节只介绍一种：Deployment。

1》命令的方式创建deploy

# 查看deployment的信息
[root@master ~]# kubectl get deploy -n dev
NAME    READY   UP-TO-DATE   AVAILABLE   AGE
nginx   3/3     3            3           2m42s

# UP-TO-DATE：成功升级的副本数量
# AVAILABLE：可用副本的数量
[root@master ~]# kubectl get deploy -n dev -o wide
NAME    READY UP-TO-DATE  AVAILABLE   AGE     CONTAINERS   IMAGES              SELECTOR
nginx   3/3     3         3           2m51s   nginx        nginx:latest        run=nginx

# 查看deployment的详细信息
[root@master ~]# kubectl describe deploy nginx -n dev


# 删除 （删除deployment后它管理的那些pod也就被删除了）
[root@master ~]# kubectl delete deploy nginx -n dev
deployment.apps "nginx" deleted

2》配置操作

创建一个deploy-nginx.yaml，内容如下：

然后就可以执行对应的创建和删除命令了：

创建：kubectl create -f deploy-nginx.yaml

删除：kubectl delete -f deploy-nginx.yaml

4.5 Service

通过上节课的学习，已经能够利用Deployment来创建一组Pod来提供具有高可用性的服务。

虽然每个Pod都会分配一个单独的Pod IP，然而却存在如下两问题：

Pod IP 会随着Pod的重建产生变化
Pod IP 仅仅是集群内可见的虚拟IP，外部无法访问

这样对于访问这个服务带来了难度。因此，kubernetes设计了Service来解决这个问题。

Service可以看作是一组同类Pod对外的访问接口。借助Service，应用可以方便地实现服务发现和负载均衡。

1》配置方式

创建集群内部可访问的Service

# 暴露Service(service指定要暴露哪个deployment下的那些pod)
[root@master ~]# kubectl expose deploy nginx --name=svc-nginx1 --type=ClusterIP --port=80 --target-port=80 -n dev
service/svc-nginx1 exposed

# 查看service
[root@master ~]# kubectl get svc svc-nginx1 -n dev -o wide
NAME         TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)   AGE     SELECTOR
svc-nginx1   ClusterIP   10.109.179.231   <none>        80/TCP    3m51s   run=nginx

# 这里产生了一个CLUSTER-IP，这就是service的IP，在Service的生命周期中，这个地址是不会变动的
# 可以通过这个IP访问当前service对应的POD
[root@master ~]# curl 10.109.179.231:80

创建集群外部也可访问的Service

# 上面创建的Service的type类型为ClusterIP，这个ip地址只用集群内部可访问
# 如果需要创建外部也可以访问的Service，需要修改type为NodePort
[root@master ~]# kubectl expose deploy nginx --name=svc-nginx2 --type=NodePort --port=80 --target-port=80 -n dev
service/svc-nginx2 exposed

# 此时查看，会发现出现了NodePort类型的Service，而且有一对Port（80:31928/TC）
[root@master ~]# kubectl get svc  svc-nginx2  -n dev -o wide
NAME          TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)        AGE    SELECTOR
svc-nginx2    NodePort    10.100.94.0      <none>        80:31928/TCP   9s     run=nginx

# 接下来就可以通过集群外的主机访问 节点IP:31928访问服务了
# 例如在的电脑主机上通过浏览器访问下面的地址，192.168.90.100是你虚拟机的ip
http://192.168.90.100:31928/

删除Service

[root@master ~]# kubectl delete svc svc-nginx-1 -n dev 
service "svc-nginx-1" deleted

2》配置方式

创建一个svc-nginx.yaml，内容如下：

apiVersion: v1
kind: Service
metadata:
  name: svc-nginx
  namespace: dev
spec:
  clusterIP: 10.109.179.231 #固定svc的内网ip
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    run: nginx
  type: ClusterIP

然后就可以执行对应的创建和删除命令了：

创建：kubectl create -f svc-nginx.yaml

删除：kubectl delete -f svc-nginx.yaml

5. Pod详解

5.1 Pod介绍

每个Pod中都可以包含一个或者多个容器，这些容器可以分为两类：

用户程序所在的容器，数量可多可少
Pause容器，这是每个Pod都会有的一个根容器，它的作用有两个：
- 可以以它为依据，评估整个Pod的健康状态
- 可以在根容器上设置Ip地址，其它容器都此Ip（Pod IP），以实现Pod内部的网路通信

下面是Pod的资源清单：

apiVersion: v1     #必选，版本号，例如v1
kind: Pod       　 #必选，资源类型，例如 Pod
metadata:       　 #必选，元数据
  name: string     #必选，Pod名称
  namespace: string  #Pod所属的命名空间,默认为"default"
  labels:       　　  #自定义标签列表
    - name: string      　          
spec:  #描述，这是配置中最重要的一部分，里面是对各种资源配置的详细描述
  containers:  #必选，Pod中容器列表
  - name: string   #必选，容器名称
    image: string  #必选，容器的镜像名称
    imagePullPolicy: [ Always|Never|IfNotPresent ]  #获取镜像的策略 
    command: [string]   #容器的启动命令列表，如不指定，使用打包时使用的启动命令
    args: [string]      #容器的启动命令参数列表
    workingDir: string  #容器的工作目录
    volumeMounts:       #挂载到容器内部的存储卷配置
    - name: string      #引用pod定义的共享存储卷的名称，需用volumes[]部分定义的的卷名
      mountPath: string #存储卷在容器内mount的绝对路径，应少于512字符
      readOnly: boolean #是否为只读模式
    ports: #需要暴露的端口库号列表
    - name: string        #端口的名称
      containerPort: int  #容器需要监听的端口号
      hostPort: int       #容器所在主机需要监听的端口号，默认与Container相同
      protocol: string    #端口协议，支持TCP和UDP，默认TCP
    env:   #容器运行前需设置的环境变量列表
    - name: string  #环境变量名称
      value: string #环境变量的值
    resources: #资源限制和请求的设置
      limits:  #资源限制的设置
        cpu: string     #Cpu的限制，单位为core数，将用于docker run --cpu-shares参数
        memory: string  #内存限制，单位可以为Mib/Gib，将用于docker run --memory参数
      requests: #资源请求的设置
        cpu: string    #Cpu请求，容器启动的初始可用数量
        memory: string #内存请求,容器启动的初始可用数量
    lifecycle: #生命周期钩子
        postStart: #容器启动后立即执行此钩子,如果执行失败,会根据重启策略进行重启
        preStop: #容器终止前执行此钩子,无论结果如何,容器都会终止
    livenessProbe:  #对Pod内各容器健康检查的设置，当探测无响应几次后将自动重启该容器
      exec:       　 #对Pod容器内检查方式设置为exec方式
        command: [string]  #exec方式需要制定的命令或脚本
      httpGet:       #对Pod内个容器健康检查方法设置为HttpGet，需要制定Path、port
        path: string
        port: number
        host: string
        scheme: string
        HttpHeaders:
        - name: string
          value: string
      tcpSocket:     #对Pod内个容器健康检查方式设置为tcpSocket方式
         port: number
       initialDelaySeconds: 0       #容器启动完成后首次探测的时间，单位为秒
       timeoutSeconds: 0    　　    #对容器健康检查探测等待响应的超时时间，单位秒，默认1秒
       periodSeconds: 0     　　    #对容器监控检查的定期探测时间设置，单位秒，默认10秒一次
       successThreshold: 0
       failureThreshold: 0
       securityContext:
         privileged: false
  restartPolicy: [Always | Never | OnFailure]  #Pod的重启策略
  nodeName: <string> #设置NodeName表示将该Pod调度到指定到名称的node节点上
  nodeSelector: obeject #设置NodeSelector表示将该Pod调度到包含这个label的node上
  imagePullSecrets: #Pull镜像时使用的secret名称，以key：secretkey格式指定
  - name: string
  hostNetwork: false   #是否使用主机网络模式，默认为false，如果设置为true，表示使用宿主机网络
  volumes:   #在该pod上定义共享存储卷列表
  - name: string    #共享存储卷名称 （volumes类型有很多种）
    emptyDir: {
   }       #类型为emtyDir的存储卷，与Pod同生命周期的一个临时目录。为空值
    hostPath: string   #类型为hostPath的存储卷，表示挂载Pod所在宿主机的目录
      path: string      　　        #Pod所在宿主机的目录，将被用于同期中mount的目录
    secret:       　　　#类型为secret的存储卷，挂载集群与定义的secret对象到容器内部
      scretname: string  
      items:     
      - key: string
        path: string
    configMap:         #类型为configMap的存储卷，挂载预定义的configMap对象到容器内部
      name: string
      items:
      - key: string
        path: string

5.2 Pod配置

1》配置容器

一言蔽之：

在pod里面自定义两个程序（naginx和busybox），启动pod后发现nginx容器启动成功，但是busybox容器启动失败

创建pod-base.yaml文件，内容如下：

apiVersion: v1
kind: Pod
metadata:
  name: pod-base
  namespace: dev
  labels:
    user: heima
spec:
  containers:
  - name: nginx
    image: nginx:1.17.1
  - name: busybox
    image: busybox:1.30

# 创建Pod
[root@k8s-master01 pod]# kubectl apply -f pod-base.yaml
pod/pod-base created

# 查看Pod状况
# READY 1/2 : 表示当前Pod中有2个容器，其中1个准备就绪，1个未就绪
# RESTARTS  : 重启次数，因为有1个容器故障了，Pod一直在重启试图恢复它
[root@k8s-master01 pod]# kubectl get pod -n dev
NAME       READY   STATUS    RESTARTS   AGE
pod