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

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

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中所有podkubectl get pods -n kube-system

查看所有node

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

查看node的资源使用情况

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

#查看node的资源使用情况➜ ~ kubectl top nodeerror: Metrics API not available #没有部署Metrics时会报错#查看➜ ~ kubectl cluster-infoKubernetes master is running at is running at 部署metrics-server

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

#2020-12-14在github上，查看的latest release是v0.4.1kubectl apply -f clone 源码git clone taggit checkout v0.4.1#检测基础镜像是不是也有gcr.io？➜ metrics-server git:(91dbeeb) cat Dockerfile | grep -i fromFROM golang:1.14.2 as buildFROM gcr.io/distroless/static:latestCOPY --from=build /go/src/sigs.k8s.io/metrics-server/metrics-server /#解决所有需要科学上网的镜像问题gcr.io下载gcr-io-distroless-stati.rar docker load -i gcr-io-distroless-stati.rar docker image | grep static## 制作镜像mkdir builddocker build . -f Dockerfile -t k8s.gcr.io/metrics-server/metrics-server:v0.4.1##过程如下Sending build context to Docker daemon 14.07MBStep 1/17 : FROM golang:1.14.2 as build1.14.2: Pulling from library/golang90fe46dd8199: Pull complete35a4f1977689: Pull completebbc37f14aded: Pull complete74e27dc593d4: Pull complete38b1453721cb: Pull complete780391780e20: Pull complete0f7fd9f8d114: Pull completeDigest: sha256:1bd634c5a72bfa7fb48d54e37dd5d8174161bd6ca601b7d132c7b68eaf513c6bStatus: Downloaded newer image for golang:1.14.2 ---> 2421885b04daStep 2/17 : WORKDIR /go/src/sigs.k8s.io/metrics-server ---> Running in 96e81531cb0aRemoving intermediate container 96e81531cb0a ---> 9d0927391b72Step 3/17 : COPY go.mod . ---> 9f60e5015533Step 4/17 : COPY go.sum . ---> 523142f52066#如果这里下载比较慢的话，或者不能下载，请使用直接执行代理#请参考 Step 5/17 : RUN go mod download ---> Running in 8fffbf196d65Removing intermediate container 8fffbf196d65 ---> db3645f8946eStep 6/17 : COPY pkg pkg ---> 83cbfd06a366Step 7/17 : COPY cmd cmd ---> 7f85f264e366Step 8/17 : COPY Makefile Makefile ---> f111904bc8caStep 9/17 : ARG ARCH ---> Running in 0b0a7f75d5e5Removing intermediate container 0b0a7f75d5e5 ---> c271515d88afStep 10/17 : ARG GIT_COMMIT ---> Running in 1e241ac12eecRemoving intermediate container 1e241ac12eec ---> 0807400e8b0bStep 11/17 : ARG GIT_TAG ---> Running in 408cc6814cc6Removing intermediate container 408cc6814cc6 ---> 93d1121234eeStep 12/17 : ARG BUILD_DATE ---> Running in 78a05f90f090Removing intermediate container 78a05f90f090 ---> 18c062a2e029Step 13/17 : RUN make metrics-server ---> Running in dd252653029dGOARCH=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-serverRemoving intermediate container dd252653029d ---> 6a577df71f43Step 14/17 : FROM gcr.io/distroless/static:latest ---> 25b8fd42ff36Step 15/17 : COPY --from=build /go/src/sigs.k8s.io/metrics-server/metrics-server / ---> 8ae2fdc5fd0dStep 16/17 : USER 65534 ---> Running in df725cb47b01Removing intermediate container df725cb47b01 ---> b677cdc44ad9Step 17/17 : ENTRYPOINT ["/metrics-server"] ---> Running in 6f004c6d2af8Removing intermediate container 6f004c6d2af8 ---> 768fa6c1a0fbSuccessfully built 768fa6c1a0fbSuccessfully tagged k8s.gcr.io/metrics-server/metrics-server:v0.4.1

k8s启动metrics-server

#由于镜像k8s.gcr.io/metrics-server/metrics-server:v0.4.1本地已经有了，可以直接执行。kubectl apply -f apply -f components.yaml#如果删除需要执行kubectl delete -f components.yaml

运行记录如下

➜ metrics-server git:(91dbeeb) kubectl apply -f components.yamlserviceaccount/metrics-server createdclusterrole.rbac.authorization.k8s.io/system:aggregated-metrics-reader createdclusterrole.rbac.authorization.k8s.io/system:metrics-server createdrolebinding.rbac.authorization.k8s.io/metrics-server-auth-reader createdclusterrolebinding.rbac.authorization.k8s.io/metrics-server:system:auth-delegator createdclusterrolebinding.rbac.authorization.k8s.io/system:metrics-server createdservice/metrics-server createddeployment.apps/metrics-server createdapiservice.apiregistration.k8s.io/v1beta1.metrics.k8s.io created

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

#集群节点没问题，刚才创建的pod出现异常 状态是CrashLoopBackOffkubectl 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 "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.gcr.io/metrics-server/metrics-server:v0.4.1

验证metrics-server

➜ Desktop kubectl top nodesNAME 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 ）。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。