Kubernetes学习笔记02

正文01

于 2024-04-28 19:31:01 发布

阅读量730

点赞数 25

文章标签： kubernetes 学习笔记

本文链接：https://blog.csdn.net/sjdhdbjd/article/details/138287894

版权

第五章、Kubernetes核心技术Pod

Pod概述

Pod是K8S系统中可以创建和管理的最小单元，是资源对象模型中由用户创建或部署的最小资源对象模型，也是在K8S上运行容器化应用的资源对象，其它的资源对象都是用来支撑或者扩展Pod对象功能的，比如控制器对象是用来管控Pod对象的，Service或者Ingress资源对象是用来暴露Pod引用对象的，PersistentVolume资源对象是用来为Pod提供存储等等，K8S不会直接处理容器，而是Pod，Pod是由一个或多个container组成。

Pod是Kubernetes的最重要概念，每一个Pod都有一个特殊的被称为 “根容器”的Pause容器。Pause容器对应的镜像属于Kubernetes平台的一部分，除了Pause容器，每个Pod还包含一个或多个紧密相关的用户业务容器。

Pod基本概念

最小部署的单元
Pod里面是由一个或多个容器组成【一组容器的集合】
一个pod中的容器是共享网络命名空间
Pod是短暂的
每个Pod包含一个或多个紧密相关的用户业务容器

Pod存在的意义

创建容器使用docker，一个docker对应一个容器，一个容器运行一个应用进程
Pod是多进程设计，运用多个应用程序，也就是一个Pod里面有多个容器，而一个容器里面运行一个应用程序

Pod的存在是为了亲密性应用
- 两个应用之间进行交互
- 网络之间的调用【通过127.0.0.1 或 socket】
- 两个应用之间需要频繁调用

Pod是在K8S集群中运行部署应用或服务的最小单元，它是可以支持多容器的。Pod的设计理念是支持多个容器在一个Pod中共享网络地址和文件系统，可以通过进程间通信和文件共享这种简单高效的方式组合完成服务。同时Pod对多容器的支持是K8S中最基础的设计理念。在生产环境中，通常是由不同的团队各自开发构建自己的容器镜像，在部署的时候组合成一个微服务对外提供服务。

Pod是K8S集群中所有业务类型的基础，可以把Pod看作运行在K8S集群上的小机器人，不同类型的业务就需要不同类型的小机器人去执行。目前K8S的业务主要可以分为以下几种

长期伺服型：long-running
批处理型：batch
节点后台支撑型：node-daemon
有状态应用型：stateful application

上述的几种类型，分别对应的小机器人控制器为：Deployment、Job、DaemonSet 和 StatefulSet (后面将介绍控制器)

Pod实现机制

主要有以下两大机制

共享网络
共享存储

共享网络

容器本身之间相互隔离的，一般是通过 namespace 和 group 进行隔离，那么Pod里面的容器如何实现通信？

首先需要满足前提条件，也就是容器都在同一个namespace之间

关于Pod实现原理，首先会在Pod会创建一个根容器： pause容器，然后我们在创建业务容器【nginx，redis 等】，在我们创建业务容器的时候，会把它添加到 info容器中

而在 info容器中会独立出 ip地址，mac地址，port 等信息，然后实现网络的共享

完整步骤如下

通过 Pause 容器，把其它业务容器加入到Pause容器里，让所有业务容器在同一个名称空间中，可以实现网络共享

共享存储

Pod持久化数据，专门存储到某个地方中

使用 Volumn数据卷进行共享存储，案例如下所示

Pod镜像拉取策略

我们以具体实例来说，拉取策略就是 imagePullPolicy

拉取策略主要分为了以下几种

IfNotPresent：默认值，镜像在宿主机上不存在才拉取
Always：每次创建Pod都会重新拉取一次镜像
Never：Pod永远不会主动拉取这个镜像

Pod资源限制

也就是我们Pod在进行调度的时候，可以对调度的资源进行限制，例如我们限制 Pod调度是使用的资源是 2C4G，那么在调度对应的node节点时，只会占用对应的资源，对于不满足资源的节点，将不会进行调度

示例

我们在下面的地方进行资源的限制

这里分了两个部分

request：表示调度所需的资源
limits：表示最大所占用的资源

Pod重启机制

因为Pod中包含了很多个容器，假设某个容器出现问题了，那么就会触发Pod重启机制

重启策略主要分为以下三种

Always：当容器终止退出后，总是重启容器，默认策略【nginx等，需要不断提供服务】
OnFailure：当容器异常退出（退出状态码非0）时，才重启容器。
Never：当容器终止退出，从不重启容器【批量任务】

Pod健康检查

通过容器检查，原来我们使用下面的命令来检查

kubectl get pod

但是有的时候，程序可能出现了 Java 堆内存溢出，程序还在运行，但是不能对外提供服务了，这个时候就不能通过容器检查来判断服务是否可用了

这个时候就可以使用应用层面的检查

# 存活检查，如果检查失败，将杀死容器，根据Pod的restartPolicy【重启策略】来操作

livenessProbe

# 就绪检查，如果检查失败，Kubernetes会把Pod从Service endpoints中剔除

readinessProbe

Probe支持以下三种检查方式

http Get：发送HTTP请求，返回200 - 400 范围状态码为成功
exec：执行Shell命令返回状态码是0为成功
tcpSocket：发起TCP Socket建立成功

Pod调度策略

创建Pod流程

首先创建一个pod，然后创建一个API Server 和 Etcd【把创建出来的信息存储在etcd中】
然后创建 Scheduler，监控API Server是否有新的Pod，如果有的话，会通过调度算法，把pod调度某个node上
在node节点，会通过 kubelet -- apiserver 读取etcd 拿到分配在当前node节点上的pod，然后通过docker创建容器

影响Pod调度的属性

Pod资源限制对Pod的调度会有影响

根据request找到足够node节点进行调度

节点选择器标签影响Pod调度

关于节点选择器，其实就是有两个环境，然后环境之间所用的资源配置不同

我们可以通过以下命令，给我们的节点新增标签，然后节点选择器就会进行调度了

kubectl label node node1 env_role=prod

节点亲和性

节点亲和性 nodeAffinity 和之前nodeSelector 基本一样的，根据节点上标签约束来决定Pod调度到哪些节点上

硬亲和性：约束条件必须满足
软亲和性：尝试满足，不保证

支持常用操作符：in、NotIn、Exists、Gt、Lt、DoesNotExists

反亲和性：就是和亲和性刚刚相反，如 NotIn、DoesNotExists等

污点和污点容忍

概述

nodeSelector 和 NodeAffinity，都是Prod调度到某些节点上，属于Pod的属性，是在调度的时候实现的。

Taint 污点：节点不做普通分配调度，是节点属性

场景

专用节点【限制ip】
配置特定硬件的节点【固态硬盘】
基于Taint驱逐【在node1不放，在node2放】

查看污点情况

kubectl describe node k8smaster | grep Taint

污点值有三个

NoSchedule：一定不被调度
PreferNoSchedule：尽量不被调度【也有被调度的几率】
NoExecute：不会调度，并且还会驱逐Node已有Pod

未节点添加污点

kubectl taint node [node] key=value:污点的三个值

举例：

kubectl taint node k8snode1 env_role=yes:NoSchedule

删除污点

kubectl taint node k8snode1 env_role:NoSchedule-

演示

我们现在创建多个Pod，查看最后分配到Node上的情况

首先我们创建一个 nginx 的pod

kubectl create deployment web --image=nginx

然后使用命令查看

kubectl get pods -o wide

我们可以非常明显的看到，这个Pod已经被分配到 k8snode1 节点上了

下面我们把pod复制5份，在查看情况pod情况

kubectl scale deployment web --replicas=5

我们可以发现，因为master节点存在污点的情况，所以节点都被分配到了 node1 和 node2节点上

我们可以使用下面命令，把刚刚我们创建的pod都删除

kubectl delete deployment web

现在给了更好的演示污点的用法，我们现在给 node1节点打上污点

kubectl taint node k8snode1 env_role=yes:NoSchedule

然后我们查看污点是否成功添加

kubectl describe node k8snode1 | grep Taint

然后我们在创建一个 pod

# 创建nginx pod

kubectl create deployment web --image=nginx

# 复制五次

kubectl scale deployment web --replicas=5

然后我们在进行查看

kubectl get pods -o wide

我们能够看到现在所有的pod都被分配到了 k8snode2上，因为刚刚我们给node1节点设置了污点

最后我们可以删除刚刚添加的污点

kubectl taint node k8snode1 env_role:NoSchedule-

污点容忍

污点容忍就是某个节点可能被调度，也可能不被调度

第六章、Kubernetes核心技术-Controller

内容

什么是Controller
Pod和Controller的关系
Deployment控制器应用场景
yaml文件字段说明
Deployment控制器部署应用
升级回滚
弹性伸缩

什么是Controller

Controller是在集群上管理和运行容器的对象，Controller是实际存在的，Pod是虚拟机的

Pod和Controller的关系

Pod是通过Controller实现应用的运维，比如弹性伸缩，滚动升级等

Pod 和 Controller之间是通过label标签来建立关系，同时Controller又被称为控制器工作负载

Deployment控制器应用

Deployment控制器可以部署无状态应用
管理Pod和ReplicaSet
部署，滚动升级等功能
应用场景：web服务，微服务

Deployment表示用户对K8S集群的一次更新操作。Deployment是一个比RS( Replica Set, RS) 应用模型更广的 API 对象，可以是创建一个新的服务，更新一个新的服务，也可以是滚动升级一个服务。滚动升级一个服务，实际是创建一个新的RS，然后逐渐将新 RS 中副本数增加到理想状态，将旧RS中的副本数减少到0的复合操作。

这样一个复合操作用一个RS是不好描述的，所以用一个更通用的Deployment来描述。以K8S的发展方向，未来对所有长期伺服型的业务的管理，都会通过Deployment来管理。

Deployment部署应用

之前我们也使用Deployment部署过应用，如下代码所示

kubectrl create deployment web --image=nginx

但是上述代码不是很好的进行复用，因为每次我们都需要重新输入代码，所以我们都是通过YAML进行配置

但是我们可以尝试使用上面的代码创建一个镜像【只是尝试，不会创建】

kubectl create deployment web --image=nginx --dry-run -o yaml > nginx.yaml

然后输出一个yaml配置文件 nginx.yml ，配置文件如下所示

apiVersion: apps/v1

kind: Deployment

metadata:

creationTimestamp: null

labels:

app: web

spec:

replicas: 1

selector:

matchLabels:

app: web

strategy: {}

template:

metadata:

creationTimestamp: null

labels:

app: web

spec:

containers:

- image:

nginx name: nginx

resources: {}

status: {}

我们看到的 selector 和 label 就是我们Pod 和 Controller之间建立关系的桥梁

使用YAML创建Pod

通过刚刚的代码，我们已经生成了YAML文件，下面我们就可以使用该配置文件快速创建Pod镜像了

kubectl apply -f nginx.yaml

但是因为这个方式创建的，我们只能在集群内部进行访问，所以我们还需要对外暴露端口

kubectl expose deployment web --port=80 --type=NodePort --target-port=80 --name=web1

关于上述命令，有几个参数

--port：就是我们内部的端口号
--target-port：就是暴露外面访问的端口号
--name：名称
--type：类型

同理，我们一样可以导出对应的配置文件

kubectl expose deployment web --port=80 --type=NodePort --target-port=80 --name=web1 -o yaml > web1.yaml

得到的web1.yaml如下所示

apiVersion: v1
kind: Service
metadata:
creationTimestamp: "2020-11-16T02:26:53Z"
labels:
app: web
managedFields:
- apiVersion: v1
fieldsType: FieldsV1
fieldsV1:
f:metadata:
f:labels:
.: {}
f:app: {}
f:spec:
f:externalTrafficPolicy: {}
f:ports:
.: {}
k:{"port":80,"protocol":"TCP"}:
.: {}
f:port: {}
f:protocol: {}
f:targetPort: {}
f:selector:
.: {}
f:app: {}
f:sessionAffinity: {}
f:type: {}
manager: kubectl
operation: Update
time: "2020-11-16T02:26:53Z"
name: web2
namespace: default
resourceVersion: "113693"
selfLink: /api/v1/namespaces/default/services/web2
uid: d570437d-a6b4-4456-8dfb-950f09534516
spec:
clusterIP: 10.104.174.145
externalTrafficPolicy: Cluster
ports:
- nodePort: 32639
port: 80
protocol: TCP
targetPort: 80
selector:
app: web
sessionAffinity: None
type: NodePort
status:
loadBalancer: {}

然后我们可以通过下面的命令来查看对外暴露的服务

kubectl get pods,svc

然后我们访问对应的url，即可看到 nginx了 http://192.168.177.130:32639/

升级回滚和弹性伸缩

升级：假设从版本为1.14 升级到 1.15 ，这就叫应用的升级【升级可以保证服务不中断】
回滚：从版本1.15 变成 1.14，这就叫应用的回滚
弹性伸缩：我们根据不同的业务场景，来改变Pod的数量对外提供服务，这就是弹性伸缩

应用升级和回滚

首先我们先创建一个 1.14版本的Pod

apiVersion: apps/v1
kind: Deployment
metadata:
creationTimestamp: null
labels:
app: web
name: web
spec:
replicas: 1
selector:
matchLabels:
app: web
strategy: {}
template:
metadata:
creationTimestamp: null
labels:
app: web
spec:
containers:
- image: nginx:1.14
name: nginx
resources: {}
status: {}

我们先指定版本为1.14，然后开始创建我们的Pod

kubectl apply -f nginx.yaml

同时，我们使用docker images命令，就能看到我们成功拉取到了一个 1.14版本的镜像

我们使用下面的命令，可以将nginx从 1.14 升级到 1.15

kubectl set image deployment web nginx=nginx:1.15

在我们执行完命令后，能看到升级的过程

首先是开始的nginx 1.14版本的Pod在运行，然后 1.15版本的在创建
然后在1.15版本创建完成后，就会暂停1.14版本
最后把1.14版本的Pod移除，完成我们的升级

我们在下载 1.15版本，容器就处于ContainerCreating状态，然后下载完成后，就用 1.15版本去替换1.14版本了，这么做的好处就是：升级可以保证服务不中断

我们到我们的node2节点上，查看我们的 docker images;

能够看到，我们已经成功拉取到了 1.15版本的nginx了

查看升级状态

下面可以，查看升级状态

kubectl rollout status deployment web

查看历史版本

我们还可以查看历史版本

kubectl rollout history deployment web

应用回滚

我们可以使用下面命令，完成回滚操作，也就是回滚到上一个版本

kubectl rollout undo deployment web

然后我们就可以查看状态

kubectl rollout status deployment web

同时我们还可以回滚到指定版本

kubectl rollout undo deployment web --to-revision=2

弹性伸缩

弹性伸缩，也就是我们通过命令一下创建多个副本

kubectl scale deployment web --replicas=10

能够清晰看到，我们一下创建了10个副本

第七章、Kubernetes核心技术Service

前言

前面我们了解到 Deployment 只是保证了支撑服务的微服务Pod的数量，但是没有解决如何访问这些服务的问题。一个Pod只是一个运行服务的实例，随时可能在一个节点上停止，在另一个节点以一个新的IP启动一个新的Pod，因此不能以确定的IP和端口号提供服务。

要稳定地提供服务需要服务发现和负载均衡能力。服务发现完成的工作，是针对客户端访问的服务，找到对应的后端服务实例。在K8S集群中，客户端需要访问的服务就是Service对象。每个Service会对应一个集群内部有效的虚拟IP，集群内部通过虚拟IP访问一个服务。

在K8S集群中，微服务的负载均衡是由kube-proxy实现的。kube-proxy是k8s集群内部的负载均衡器。它是一个分布式代理服务器，在K8S的每个节点上都有一个；这一设计体现了它的伸缩性优势，需要访问服务的节点越多，提供负载均衡能力的kube-proxy就越多，高可用节点也随之增多。与之相比，我们平时在服务器端使用反向代理作负载均衡，还要进一步解决反向代理的高可用问题。