Kubernetes 工作实践内容总结-收藏版

原创

Freddy_Shen 2022-04-29 11:07:24 ©著作权

文章标签 kubernetes 原力计划 docker git github 文章分类 kubernetes 云计算

©著作权归作者所有：来自51CTO博客作者Freddy_Shen的原创作品，请联系作者获取转载授权，否则将追究法律责任

Kubernetes 工作实践内容总结-收藏

k8s 命令基础

Kubectl 自动补全
常用使用命令

查看kube-system ns中所有pod
查看所有node
查看node的资源使用情况

Kubernetes 部署metrics-server

k8s的配置默认地址
cordon，drain，delete

cordon
drain
drain的参数
delete
CPU单位m

k8s 命令基础

在学习中，经常自己验证的相关知识记录

Kubectl 自动补全

根据官方文档Kubectl自动补全配置自己电脑详细过程

#在 zsh 中设置当前 shell 的自动补全
vi /etc/profile
#在最后一行加入
source <(kubectl completion zsh)  # 在 zsh 中设置当前 shell 的自动补全
#保存生效
source /etc/profile
#验证,按tab键使用

常用使用命令

查看kube-system ns中所有pod

#查看kube-system ns中所有pod
kubectl get pods -n kube-system

查看所有node

#查看所有node
kubectl get nodes
#查看node的详细信息
kubectl describe node docker-desktop

查看node的资源使用情况

如果没有部署 Metrics 时，使用查看命令会报 Metrics API not available

#查看node的资源使用情况
➜  ~ kubectl top node
error: Metrics API not available #没有部署Metrics时会报错
#查看
➜  ~ kubectl cluster-info
Kubernetes master is running at https://kubernetes.docker.internal:6443
KubeDNS is running at https://kubernetes.docker.internal:6443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy

Kubernetes 部署metrics-server

首先根据官方文档，查看Metrics服务器，然后会根据提示点击到github-kubernetes-sigs/metrics-server，下面是部署过程

根据官网的git地址，选择要安装的具体版本

#2020-12-14在github上，查看的latest release是v0.4.1
kubectl apply -f https:///kubernetes-sigs/metrics-server/releases/download/v0.4.1/components.yaml
#如果能科学上网就不用修改安装文件，反之，需要先下载，修改下镜像地址，再执行部署
wget https:///kubernetes-sigs/metrics-server/releases/download/v0.4.1/components.yaml
wget https:///kubernetes-sigs/metrics-server/releases/download/v0.5.0/components.yaml

自己手动制作镜像或者下载别人上传的

# clone 源码
git clone https:///kubernetes-sigs/metrics-server.git
#选择要制作的镜像tag
git tag
git checkout v0.4.1
#检测基础镜像是不是也有？
➜  metrics-server git:(91dbeeb) cat Dockerfile | grep -i from
FROM golang:1.14.2 as build
FROM /distroless/static:latest
COPY --from=build /go/src/sigs.k8s.io/metrics-server/metrics-server /
#解决所有需要科学上网的镜像问题
下载gcr-io-distroless-stati.rar 
docker load -i gcr-io-distroless-stati.rar 
docker image | grep static
## 制作镜像
mkdir build
docker build . -f Dockerfile -t k8s./metrics-server/metrics-server:v0.4.1
##过程如下
Sending build context to Docker daemon  14.07MB
Step 1/17 : FROM golang:1.14.2 as build
1.14.2: Pulling from library/golang
90fe46dd8199: Pull complete
35a4f1977689: Pull complete
bbc37f14aded: Pull complete
74e27dc593d4: Pull complete
38b1453721cb: Pull complete
780391780e20: Pull complete
0f7fd9f8d114: Pull complete
Digest: sha256:1bd634c5a72bfa7fb48d54e37dd5d8174161bd6ca601b7d132c7b68eaf513c6b
Status: Downloaded newer image for golang:1.14.2
 ---> 2421885b04da
Step 2/17 : WORKDIR /go/src/sigs.k8s.io/metrics-server
 ---> Running in 96e81531cb0a
Removing intermediate container 96e81531cb0a
 ---> 9d0927391b72
Step 3/17 : COPY go.mod .
 ---> 9f60e5015533
Step 4/17 : COPY go.sum .
 ---> 523142f52066
#如果这里下载比较慢的话，或者不能下载，请使用直接执行代理
#请参考 
Step 5/17 : RUN go mod download
 ---> Running in 8fffbf196d65
Removing intermediate container 8fffbf196d65
 ---> db3645f8946e
Step 6/17 : COPY pkg pkg
 ---> 83cbfd06a366
Step 7/17 : COPY cmd cmd
 ---> 7f85f264e366
Step 8/17 : COPY Makefile Makefile
 ---> f111904bc8ca
Step 9/17 : ARG ARCH
 ---> Running in 0b0a7f75d5e5
Removing intermediate container 0b0a7f75d5e5
 ---> c271515d88af
Step 10/17 : ARG GIT_COMMIT
 ---> Running in 1e241ac12eec
Removing intermediate container 1e241ac12eec
 ---> 0807400e8b0b
Step 11/17 : ARG GIT_TAG
 ---> Running in 408cc6814cc6
Removing intermediate container 408cc6814cc6
 ---> 93d1121234ee
Step 12/17 : ARG BUILD_DATE
 ---> Running in 78a05f90f090
Removing intermediate container 78a05f90f090
 ---> 18c062a2e029
Step 13/17 : RUN make metrics-server
 ---> Running in dd252653029d
GOARCH=amd64 CGO_ENABLED=0 go build -ldflags "-X sigs.k8s.io/metrics-server/pkg/version.gitVersion= -X sigs.k8s.io/metrics-server/pkg/version.gitCommit= -X sigs.k8s.io/metrics-server/pkg/version.buildDate=2020-12-14T05:12:12Z" -o metrics-server sigs.k8s.io/metrics-server/cmd/metrics-server
Removing intermediate container dd252653029d
 ---> 6a577df71f43
Step 14/17 : FROM /distroless/static:latest
 ---> 25b8fd42ff36
Step 15/17 : COPY --from=build /go/src/sigs.k8s.io/metrics-server/metrics-server /
 ---> 8ae2fdc5fd0d
Step 16/17 : USER 65534
 ---> Running in df725cb47b01
Removing intermediate container df725cb47b01
 ---> b677cdc44ad9
Step 17/17 : ENTRYPOINT ["/metrics-server"]
 ---> Running in 6f004c6d2af8
Removing intermediate container 6f004c6d2af8
 ---> 768fa6c1a0fb
Successfully built 768fa6c1a0fb
Successfully tagged k8s./metrics-server/metrics-server:v0.4.1

k8s启动metrics-server

#由于镜像k8s./metrics-server/metrics-server:v0.4.1本地已经有了，可以直接执行。
kubectl apply -f https:///kubernetes-sigs/metrics-server/releases/download/v0.4.1/components.yaml
#或者文件下载到本地，然后执行
kubectl apply -f components.yaml
#如果删除需要执行
kubectl delete -f components.yaml

运行记录如下

➜  metrics-server git:(91dbeeb) kubectl apply -f components.yaml
serviceaccount/metrics-server created
/system:aggregated-metrics-reader created
/system:metrics-server created
/metrics-server-auth-reader created
cluster/metrics-server:system:auth-delegator created
cluster/system:metrics-server created
service/metrics-server created
deployment.apps/metrics-server created
/ created

k8s启动Pod遇到unable to fully scrape metrics x509: cannot validate certificate

#集群节点没问题，刚才创建的pod出现异常 状态是CrashLoopBackOff
kubectl get pods --all-namespaces
#查看此状态pod详细情况
kubectl describe pods metrics-server-866b7d5b74-2w9r2 -n kube-system
#查看此pod日志
kubectl logs metrics-server-866b7d5b74-2w9r2 -n kube-system
#根据日志发现，原因是unable to fully scrape metrics: unable to fully scrape metrics from node docker-desktop: unable to fetch metrics from node docker-desktop: Get "https://192.168.65.3:10250/stats/summary?only_cpu_and_memory=true": x509: cannot validate certificate for 192.168.65.3 because it doesn't contain any IP SANs
#如何修复呢? -添加- --kubelet-insecure-tls
  template:
    metadata:
      labels:
        k8s-app: metrics-server
    spec:
      containers:
      - args:
        - --cert-dir=/tmp
        - --secure-port=4443
        - --kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname
        - --kubelet-use-node-status-port
        - --kubelet-insecure-tls
        image: k8s./metrics-server/metrics-server:v0.4.1

验证metrics-server

➜  Desktop kubectl top nodes
NAME             CPU(cores)   CPU%   MEMORY(bytes)   MEMORY%
docker-desktop   308m         7%     1794Mi          37%

k8s的配置默认地址

$HOME/.kube/config

cordon，drain，delete

cordon

cordon 停止调度
影响最小，只会将node调为SchedulingDisabled，之后再发创建pod，不会被调度到该节点，旧有的pod不会受到影响，仍正常对外提供服务。
恢复调度kubectl uncordon node_name

drain

drain 驱逐节点
首先，驱逐node上的pod，其他节点重新创建，接着，将节点调为 SchedulingDisabled
恢复调度kubectl uncordon node_name

对节点执行维护操作之前（例如：内核升级，硬件维护等），您可以使用 kubectl drain 安全驱逐节点上面所有的 pod。安全驱逐的方式将会允许 pod 里面的容器遵循指定的 PodDisruptionBudgets 执行优雅的中止。

注：默认情况下，kubectl drain 会忽略那些不能杀死的系统类型的 pod，如果您想了解更多详细的内容，请参考kubectl drain

kubectl drain 返回成功表明所有的 pod （除了前面排除的那些）已经被安全驱逐（遵循期望优雅的中止期，并且没有违反任何应用程序级别的中断预算）。

然后，通过对物理机断电或者在云平台上删除节点所在的虚拟机，都能安全的将节点移除。

# 确定要排空的节点的名称
kubectl get nodes 
# 查看获取pod名字
kubectl get po 
# 命令node节点开始释放所有pod，并且不接收新的pod进程
kubectl drain [node-name] --force --ignore-daemonsets --delete-local-data 
# 这时候把需要做的事情做一下。比如上面说的更改docker文件daemon.json或者说node节点故障需要进行的处理操作 
# 然后恢复node，恢复接收新的pod进程
kubectl uncordon [node-name]

drain的参数

–force

当一些pod不是经 ReplicationController, ReplicaSet, Job, DaemonSet 或者 StatefulSet 管理的时候
就需要用–force来强制执行 (例如:kube-proxy)

–ignore-daemonsets

无视DaemonSet管理下的Pod

–delete-local-data

如果有mount local volumn的pod，会强制杀掉该pod并把料清除掉
另外如果跟本身的配置讯息有冲突时，drain就不会执行

delete

delete 删除节点
首先，驱逐node上的pod，其他节点重新创建，然后，从master节点删除该node，master对其不可见，失去对其控制，master不可对其恢复
恢复调度，需进入node节点，重启kubelet，基于node的自注册功能，节点重新恢复使用systemctl restart kubelet

delete是一个比较粗暴的命令，它会将被删node上的pod直接驱逐，由其他node创建（针对replicaset），然后将被删节点从master管理范围内移除，master对其失去管理控制，若想使node重归麾下，必须在node节点重启kubelet。

CPU单位m

而CPU的使用单位却是m，而OpenShift的教材上则写道：m means millicores，即m是“毫核”。毫核，是个什么鬼？OpenShift官方网站上，这样写道：

CPU的计量单位叫毫核。集群中的每一个节点可以通过操作系统确认本节点的CPU内核数量，将这个数量乘以1000，得到的就是节点总的CPU总数量。如，一个节点有两个核，那么该节点的CPU总量为2000m。如果你要使用单核的十分之一，则你要求的是100m。

还是有点晕，继续在网上翻找，终于我在Kubernetes的网站上找到相应的说明。顺便提一下，OpenShift使用的是Kubernetes ＋ Docker + Etcd及其他开源技术栈构建起来的。原来，在一个豆苞内，Kubernetes通过两个参数来限制CPU的使用，即：

spec.containers[].resources.limits.cpu

主动限制。这个月销售额必须达到1000万，否则给我卷铺盖走人。

spec.containers[].resources.requests.cpu

主动请求限制。张飞大叫：只拨三千军与我去取武陵郡，活捉太守金旋来献！

而这个m的单位，则是将一个cpu抽象化，分成1000等份。每一份即为一个millicore，即千分之一个核，或毫核。跟米与毫米的关系是一样的。而且，Kubernetes的一个CPU核概念与下面各家的概念是等同的

resources:  
    requests:  #  容器需要的最小资源量
        cpu: 50m
        memory: 50Mi
   limits:    #容器最大可以消耗的资源上限
        cpu: 100m
        memory: 100Mi

requests定义了对应容器需要的最小资源量。这句话的含义是，举例来讲，比如对于一个 Spring Boot 业务容器，这里的requests必须是容器镜像中 JVM 虚拟机需要占用的最少资源。如果这里把 Pod 的内存requests指定为 10Mi ，显然是不合理的，JVM 实际占用的内存 Xms 超出了 Kubernetes 分配给 Pod 的内存，导致 Pod 内存溢出，从而 Kubernetes 不断重启 Pod 。

limits定义了这个容器最大可以消耗的资源上限，防止过量消耗资源导致资源短缺甚至宕机。特别的，设置为 0 表示对使用的资源不做限制。值得一提的是，当设置limits而没有设置requests时，Kubernetes 默认令requests等于limits。

进一步可以把requests和limits描述的资源分为 2 类：可压缩资源（例如 CPU ）和不可压缩资源（例如内存）。合理地设置limits参数对于不可压缩资源来讲尤为重要。

前面我们已经知道requests参数会对最终的 Kubernetes 调度结果起到直接的显而易见的影响。借助于 Linux 内核 Cgroup 机制，limits参数实际上是被 Kubernetes 用来约束分配给进程的资源。对于内存参数而言，实际上就是告诉 Linux 内核什么时候相关容器进程可以为了清理空间而被杀死（ oom-kill ）。

上一篇：KubeSphere 在集群管理中，无法显示 Host 集群列表信息

下一篇：T2 iCloud日历无法同步

提问和评论都可以，用心的回复会被更多人看到评论

发布评论

相关文章

官方博客	全部文章	热门标签	班级博客
了解我们	网站地图	意见反馈

鸿蒙开发者社区	51CTO学堂
51CTO	软考资讯