k8s环境设置

在我们开始使用k8s之前,我们可以先做一些环境配置,使k8s更加的方便使用

  1. 第一个要做的就是kubectl命令的补全

    在使用kubectl的时候你会发现参数你是Tab不出来的,这时候我们可以操作一下,让他可以补全
# 在/etc/bashrc里面写入
[root@master ~]# echo "source <(kubectl completion bash)" >> /etc/bashrc
# 然后重新登录一下或者bash一下,souce 这个文件也行,习惯用什么你就用什么
[root@master ~]# source /etc/bashrc

现在你去敲kubectl 你就可以发现他的命令是可以补全的了

  1. 第二个要做的就是安装metrics-server

    这个是用来监控k8s的资源使用率的,也能监控pod,你默认去使用kubectl top node他是会报错的
[root@master ~]# kubectl top node
error: Metrics API not available

我们可以安装一个工具,让他可以监控到node和pod

# 我们先下载yaml文件,github上可以找到
[root@master ~]# wget https://github.com/kubernetes-sigs/metrics-server/releases/download/v0.6.4/components.yaml

下载好之后我们vim修改这个文件的内容,在第135行的地方我们给他加上一行

134 - args:

135 - --kubelet-insecure-tls # 加上这一行就行

136 - --cert-dir=/tmp

137 - --secure-port=4443

138 - --kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname

139 - --kubelet-use-node-status-port

140 - --metric-resolution=15s

然后在141行修改

141 image: registry.aliyuncs.com/google_containers/metrics-server:v0.6.4 # 改成这样就好了

# 修改好之后apply这个文件
[root@master ~]# kubectl apply -f components.yaml

稍等片刻之后我们执行kubectl top node

[root@master ~]# kubectl top node
NAME CPU(cores) CPU% MEMORY(bytes) MEMORY%
master 94m 4% 1314Mi 34%
node1 44m 2% 701Mi 18%
node2 38m 1% 784Mi 20%

k8s操作

我们默认使用kubectl去操作的时候,他都是在default命名空间里面,如果我们想要修改的话,可以这样操作

[root@master ~]# kubectl config set-context --current --namespace kube-system

这样修改完之后,我们后续的操作他就会默认在kube-system下进行操作,比如查询pod

[root@master ~]# kubectl get pod
NAME READY STATUS RESTARTS AGE
coredns-5bbd96d687-4vmbt 1/1 Running 3 (19m ago) 4h58m
coredns-5bbd96d687-9r9bt 1/1 Running 3 (19m ago) 4h58m
etcd-master 1/1 Running 3 (19m ago) 4h59m
kube-apiserver-master 1/1 Running 3 (17m ago) 4h59m
kube-controller-manager-master 1/1 Running 4 (19m ago) 4h59m
kube-proxy-mp98s 1/1 Running 1 (39m ago) 4h55m
kube-proxy-snk8k 1/1 Running 3 (19m ago) 4h59m
kube-proxy-xmxpj 1/1 Running 1 (39m ago) 4h55m
kube-scheduler-master 1/1 Running 4 (19m ago) 4h59m
metrics-server-7bf8c67888-qjqvw 1/1 Running 0 13m

每个命令空间内的资源都是隔离的,linux也是使用namespace来进行隔离的

我们现在切换回default命令空间

[root@master ~]# kubectl config set-context --current --namespace default
Context "kubernetes-admin@kubernetes" modified.

Pod的操作

在k8s里面,k8s调度的最小单位是pod,pod里面跑容器,一般一个pod跑一个容器,如果有特殊需求,也可以跑多个容器

创建pod的2种方式

  1. 通过命令行创建
  2. 通过yaml文件创建
通过命令行创建
# kubectl run 这个应该很容易看懂
[root@master ~]# kubectl run pod01 --image=nginx
pod/pod01 created
# 现在他的状态时正在创建,因为他需要拉取镜像,如果已经存在这个镜像,那么他就会很快变成running
[root@master ~]# kubectl get pod
NAME READY STATUS RESTARTS AGE
pod01 0/1 ContainerCreating 0 5s
# 等他一会之后他就会变成running了
[root@master ~]# kubectl get pod
NAME READY STATUS RESTARTS AGE
pod01 1/1 Running 0 33s

通过命令行去操作pod其实跟docker的命令时差不多的

我们同样也可以使用exec去进入pod

我们可以通过describe命令去查看这个pod产生的日志啊,事件

[root@master ~]# kubectl describe pods pod01
# 这里面会显示很多信息
Normal Scheduled 4m30s default-scheduler Successfully assigned default/pod01 to node2
Normal Pulling 4m29s kubelet Pulling image "nginx"
Normal Pulled 4m11s kubelet Successfully pulled image "nginx" in 18.539149997s (18.539154065s including waiting)
Normal Created 4m11s kubelet Created container pod01
Normal Started 4m10s kubelet Started container pod01

他这里面会记录从拉取镜像到启动容器的过程

我们刚刚已经启动过一个nginx了,镜像他也拉取到了,那我们现在去创建pod是不是非常的快呢???不一定

# 我们再来创建一个pod
[root@master ~]# kubectl run pod02 --image=nginx
pod/pod02 created
[root@master ~]# kubectl get pod
NAME READY STATUS RESTARTS AGE
pod01 1/1 Running 0 8m56s
pod02 0/1 ContainerCreating 0 13s
[root@master ~]# kubectl get pod
NAME READY STATUS RESTARTS AGE
pod01 1/1 Running 0 9m3s
pod02 1/1 Running 0 20s

你会发现他过了20秒才running,我们不是已经拉取过镜像了吗,为什么还是这么慢呢

这其实是因为调度的原因

[root@master ~]# kubectl get pod -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
pod01 1/1 Running 0 10m 10.244.104.5 node2 <none> <none>
pod02 1/1 Running 0 79s 10.244.166.135 node1 <none> <none>

通过这个命令我们可以看见,pod01是被调度到了node2上面,那么他拉取的镜像也应该是存在node2上面,然而pod02是被调度到了node1上面,他也需要重新拉取镜像,所以会很慢

我们同样可以到node1上面去看看是不是真的存在这样镜像了

# 注意,k8s在1.24之后就剔除了dockershim,所以他的镜像并不是存在docker里
[root@node1 ~]# crictl img |grep nginx
docker.io/library/nginx latest d453dd892d935 70.5MB

我们可以看到 node1上确实是有这个镜像的

通过describe也是可以看到他的调度过程的

[root@master ~]#  kubectl describe pods pod02
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled 4m58s default-scheduler Successfully assigned default/pod02 to node1
Normal Pulling 4m58s kubelet Pulling image "nginx"
Normal Pulled 4m39s kubelet Successfully pulled image "nginx" in 18.445251423s (18.445254681s including waiting)
Normal Created 4m39s kubelet Created container pod02
Normal Started 4m39s kubelet Started container pod02

现在2个节点上都有镜像了,我们不妨再来创建一个pod,看看他是不是要快很多

[root@master ~]# kubectl run pod03 --image=nginx
pod/pod03 created
[root@master ~]# kubectl get pod
NAME READY STATUS RESTARTS AGE
pod01 1/1 Running 0 15m
pod02 1/1 Running 0 6m57s
pod03 1/1 Running 0 4s

可以看到pod03只用了4秒就已经running了

4秒就是极限了吗?不,还可以更快,想要更快就需要了解镜像拉取策略了

pod的镜像拉取策略

总共有3种策略,分别是

  1. Always

这个就是默认的策略,不管你当前的节点上是否存在你指定的那个镜像,他都会有一个联网的动作,如果你的节点上存在这个镜像,那么他会联网检查这个动作,如果不存在则会联网拉取镜像

  1. Never

这个是从不拉取,只会使用本地镜像

  1. IfNotPresent

这个策略会检测本地是否存在,存在的话就直接使用了,不存在的话就会联网拉取

那么我们现在创建pod并指定一下策略,看看他是不是会比默认的策略要快

[root@master ~]# kubectl run pod04 --image=nginx --image-pull-policy=IfNotPresent
pod/pod04 created
[root@master ~]# kubectl get pod
NAME READY STATUS RESTARTS AGE
pod01 1/1 Running 0 48m
pod02 1/1 Running 0 39m
pod03 1/1 Running 0 32m
pod04 1/1 Running 0 2s

我们可以看到,他只花了2秒就已经启动了这个pod,更快的原因是因为他没有了联网联查的这个动作

这个就是镜像的拉取策略

通过yaml文件创建

通过命令行去创建我们会觉得不太方便,因为我们创建一个pod他就需要敲一次命令,我能不能写个文件,让他按照这个文件去创建pod呢?可以

通过这种方式我们的这个文件是可以复用的

像这种文件里面的参数是很多的,减少记忆负担,我们是可以通过命令让他生成一个模板的,我们只需要改这个模板就好了

# 这个模板就是使用nginx镜像,拉取策略是IfNotPresent --dry-run 是测试运行的意思,然后将内容以yaml的格式进行输出,
[root@master ~]# kubectl run pod01 --image=nginx --image-pull-policy=IfNotPresent --dry-run=client -o yaml
# 那么他输出的就是这样的一些信息,我们可以通过重定向将他保存到文件内
apiVersion: v1
kind: Pod
metadata:
creationTimestamp: null
labels:
run: pod01
name: pod01
spec:
containers:
- image: nginx
imagePullPolicy: IfNotPresent
name: pod01
resources: {}
dnsPolicy: ClusterFirst
restartPolicy: Always
status: {}

我们来完整生成并使用一次这个文件

[root@master ~]# kubectl run pod01 --image=nginx --image-pull-policy=IfNotPresent --dry-run=client -o yaml > pod01.yml
[root@master k8s]# kubectl apply -f nginx.yml
pod/pod01 created

这样pod01就被创建出来了,我们可以改动这个模板,比如我想要用centos镜像,那么改动image后面的nginx,改成centos就好了,然后执行kubectl apply,那么一个新的pod就会被创建了

如果我现在需要在一个pod里跑2个容器或者多个容器,应该怎么去写yaml文件呢

直接看示例

apiVersion: v1
kind: Pod
metadata:
creationTimestamp: null
labels:
run: pod01
name: pod01
spec:
containers:
- image: nginx
imagePullPolicy: IfNotPresent
name: pod04
resources: {}
- image: centos
args:
- sleep
- "3600"
imagePullPolicy: IfNotPresent
name: pod05
resources: {}
dnsPolicy: ClusterFirst
restartPolicy: Always
status: {}

我们首先来看一下,他跟之前的区别就是,在spec下的containers里边,多写了一个- image,我们得知道。在yaml语法种,- 代表的是列表,那么现在他的意思就是第一个零七用nginx的镜像,第二个容器使用centos的镜像

但是dnsPolicy和restartPolicy这两个为什么只用写一次呢,因为他们所属的层级不一样,这两个策略看他们的缩进,是和containers属于同一层级,所以只用写一个,并不是一个容器就得给他一个策略,不是这样的

[root@master k8s]# kubectl apply -f nginx.yml
pod/pod01 created
[root@master k8s]# kubectl get pods
NAME READY STATUS RESTARTS AGE
pod01 2/2 Running 0 3s
# 我们现在一个pod里面有2个容器,那我执行exec进入容器的时候他会进入哪个呢?随机进入吗?我们试试
[root@master k8s]# kubectl exec -it pod01 -- /bin/bash
Defaulted container "pod04" out of: pod04, pod05
root@pod01:/#
# 我们一个是nginx,另一个是centos,想要检验进入的是哪个的话非常容易,centos容器里面是有yum命令的,执行一下就知道了,如果报错,那么进入的就是nginx
root@pod01:/# yum
bash: yum: command not found
# 看出来了,我们进入的是nginx
# 我们退出再进一次,看看他是不是随机进入的
[root@master k8s]# kubectl exec -it pod01 -- /bin/bash
Defaulted container "pod04" out of: pod04, pod05
root@pod01:/# yum
bash: yum: command not found
# 其实我们看提示信息就知道了。它默认进入的是pod04,也就是nginx
# 那我我想进入pod05怎么办呢?我们可以加上-c参数
[root@master k8s]# kubectl exec -it pod01 -c pod05 -- /bin/bash
[root@pod01 /]# yum version
Failed to set locale, defaulting to C.UTF-8
No such command: version. Please use /usr/bin/yum --help
It could be a YUM plugin command, try: "yum install 'dnf-command(version)'"
# 可以看到我们确实进入了centos,yum命令可以是用了

pod的生命周期及重启策略

容器运行的是进程,而进程是由镜像定义好的

在上面的yaml文件中,我们可以看得到有一个restartPolicy,这个就是重启策略

重启策略总共有3种,分别是

  1. Always:当容器终止退出后,总是重启容器,默认策略。
  2. OnFailure:当容器终止异常退出(退出码非0)时,才重启容器。
  3. Never:当容器终止退出时,不管是正常还是非正常退出,都不重启
Always

我们直接来看一个示例

apiVersion: v1
kind: Pod
metadata:
creationTimestamp: null
labels:
run: pod01
name: pod01
spec:
containers:
- image: nginx
imagePullPolicy: IfNotPresent
name: pod04
resources: {}
args:
- sleeeeeeep
- "3600"
dnsPolicy: ClusterFirst
restartPolicy: Always
status: {}

这里容器执行的命令我们故意将他写错,来看效果

[root@master k8s]# kubectl apply -f nginx.yml
pod/pod01 created
[root@master k8s]# kubectl get pods
NAME READY STATUS RESTARTS AGE
pod01 0/1 Error 1 (2s ago) 2s
[root@master k8s]# kubectl get pods
NAME READY STATUS RESTARTS AGE
pod01 0/1 Error 4 (59s ago) 101s

会发现他一直都在重启,这个就是Always

Never

这个策略我们依旧使用上面那个yaml文件,但是策略我们改成Never,我们来看看效果

[root@master k8s]# kubectl apply -f nginx.yml
pod/pod01 created
[root@master k8s]# kubectl get pods
NAME READY STATUS RESTARTS AGE
pod01 0/1 Error 0 3s
[root@master k8s]# kubectl get pods
NAME READY STATUS RESTARTS AGE
pod01 0/1 Error 0 30s

我们可以看见,过了30秒他的restarts依旧是0,说明没有重启过

OnFailure

这个策略我们用到2个yaml文件,一个是上面的那个命令错误的yaml文件,另一个是让他执行命令echo,他执行完之后是正常退出的,我们来看效果

# 这个依旧是使用之前的yaml文件,策略改成OnFailure,其他不变
[root@master k8s]# kubectl apply -f nginx.yml
pod/pod01 created
[root@master k8s]# kubectl get pods
NAME READY STATUS RESTARTS AGE
pod01 0/1 Error 1 (3s ago) 4s
[root@master k8s]# kubectl get pods
NAME READY STATUS RESTARTS AGE
pod01 0/1 Error 2 (15s ago) 17s

我们可以看到,他是一直在重启的,符合他的重启策略

现在我们来让他执行一个瞬时任务,echo 他执行完这个命令之后容器的生命周期就结束了,所以是属于正常退出,我们来看看他会不会重启

# 修改yaml文件
apiVersion: v1
kind: Pod
metadata:
creationTimestamp: null
labels:
run: pod01
name: pod01
spec:
containers:
- image: nginx
imagePullPolicy: IfNotPresent
name: pod04
resources: {}
args:
- echo
- hello
dnsPolicy: ClusterFirst
restartPolicy: OnFailure
status: {}

使用这个yaml文件去创建pod

[root@master k8s]# kubectl apply -f nginx.yml
pod/pod01 created
[root@master k8s]# kubectl get pods
NAME READY STATUS RESTARTS AGE
pod01 0/1 Completed 0 3s
[root@master k8s]# kubectl get pods
NAME READY STATUS RESTARTS AGE
pod01 0/1 Completed 0 52s

我们可以看见,容器是正常退出的,状态时完成,不是Error,所以他并没有重启

k8s环境设置-pod下载及重启策略的更多相关文章

  1. .net core i上 K8S(四).netcore程序的pod管理,重启策略与健康检查

    上一章我们已经通过yaml文件将.netcore程序跑起来了,但还有一下细节问题可以分享给大家. 1.pod管理 1.1创建pod kubectl create -f netcore-pod.yaml ...

  2. Docker Kubernetes 容器重启策略

    Docker Kubernetes 容器重启策略 当容器被创建时,容器会根据重启策略来进行容器重启. 支持三种策略: Always:当容器终止退出后,总是重启容器,默认策略. OnFailure:当容 ...

  3. K8S环境的Jenkin性能问题处理续篇(任务Pod设置)

    欢迎访问我的GitHub 这里分类和汇总了欣宸的全部原创(含配套源码):https://github.com/zq2599/blog_demos K8S环境的Jenkin性能问题处理 本文是<K ...

  4. kubernetes之pod生命周期,pod重启策略, 镜像拉取策略

    pod声明周期(状态):pending , running, succeeded, failed, unknown 挂起(Pending):Pod 已被 Kubernetes 系统接受,但有一个或者多 ...

  5. Pod 生命周期和重启策略

    Pod 在整个生命周期中被系统定义为各种状态,熟悉 Pod 的各种状态对于理解如何设置 Pod 的调度策略.重启策略是很有必要的. Pod 的状态 状态值 描述 Pending API Server ...

  6. k8s重启策略

    Pod 的重启策略有 3 种,默认值为 Always. Always : 容器失效时,kubelet 自动重启该容器: OnFailure : 容器终止运行且退出码不为0时重启: Never : 不论 ...

  7. 案例分享 生产环境逐步迁移至k8s集群 - pod注册到consul

    #案例分享 生产环境逐步迁移至k8s集群 - pod注册到consul #项目背景 多套业务系统, 所有节点注册到consul集群,方便统一管理 使用consul的dns功能, 所有节点hostnam ...

  8. 记录一次k8s环境尝试过程(初始方案,现在已经做过很多完善,例如普罗米修斯)

    记录一次Team k8s环境搭建过程(初始方案,现在已经做过很多完善,例如普罗米修斯) span::selection, .CodeMirror-line > span > span::s ...

  9. k8s 中的 Pod 细节了解

    k8s中Pod的理解 基本概念 k8s 为什么使用 Pod 作为最小的管理单元 如何使用 Pod 1.自主式 Pod 2.控制器管理的 Pod 静态 Pod Pod的生命周期 Pod 如何直接暴露服务 ...

  10. K8S环境的Jenkin性能问题处理

    环境信息 在K8S环境通过helm部署了Jenkins(namespace为helm-jenkins),用于日常Java项目构建: kubernetes:1.15 jenkins:2.190.2 he ...

随机推荐

  1. 一文浅谈Mockito使用

    一.前期准备- 1.准备工作 <!--mockito依赖-->a <dependency> <groupId>org.mockito</groupId> ...

  2. Linux-Stream内存带宽及MLC内存延迟性能测试方法

    1.Stream内存带宽测试   Stream是业界主流的内存带宽测试程序,测试行为相对简单可控.该程序对CPU的计算能力要求很小,对CPU内存带宽压力很大.随着处理器核心数量的增大,而内存带宽并没有 ...

  3. 文心一言 VS 讯飞星火 VS chatgpt (105)-- 算法导论10.1 3题

    三.用go语言,仿照图 10-2,画图表示依次执行操作 ENQUEUE(Q,4).ENQUEUE(Q,1).ENQUEUE(Q,3).DEQUEUE(Q).ENQUEUE(Q,8)和 DEQUEUE( ...

  4. Python正则表达式——常用re正则表达式集合

    文章目录 一.校验数字的表达式 二.校验字符的表达式 三.特殊需求表达式 一.校验数字的表达式 数字:^[0-9]*$ n位的数字:^\d{n}$ 至少n位的数字:^\d{n,}$ m-n位的数字:^ ...

  5. 前端web页面支持MQTT消息推送

    MQTT服务一般用直接下载mosquitto,安装后启动服务即可.方便可靠. 但是默认情况下只开通了1883的tcp访问,用html的web页面上调用就不行了. 其实mosquitto是支持多端口的, ...

  6. JS个人总结(1)

    1. html页面引入js文件优先使用引入外部js文件. 2. 如果在html页面里使用<script></script>,则把js内容放在html内容下面,也就是</b ...

  7. 2023平台工程崭露头角,AI 带来新机遇与挑战

    在今年,平台工程正在迅速在 IT 企业中崭露头角,成为软件开发团队的必要实践.根据 CloudBees 发布的最新报告<2023年平台工程:快速采纳和影响>,83%的受访者已经完全实施了平 ...

  8. QLabel自己总结(常用接口)

    继承关系:QLabel->QFrame->QWidget void setText(const QString &) [slots] 设置标签显示的内容,也可以使用构造函数设置. ...

  9. Eclipse设置GC日志输出

    今天看了关于垃圾回收的书籍,然后自己就想自己试试,自己就在eclipse里面配置了日志输出.方法如下: 1 右键项目,选择properties 2 选择run/debug setting  新建一个a ...

  10. Go语言基准测试(benchmark)三部曲之三:提高篇

    欢迎访问我的GitHub 这里分类和汇总了欣宸的全部原创(含配套源码):https://github.com/zq2599/blog_demos 本篇概览 -<Go语言基准测试(benchmar ...