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://github.com/kubernetes-sigs/metrics-server/releases/download/v0.4.1/components.yaml
  #如果能科学上网就不用修改安装文件，反之，需要先下载，修改下镜像地址，再执行部署
  wget https://github.com/kubernetes-sigs/metrics-server/releases/download/v0.4.1/components.yaml
  wget https://github.com/kubernetes-sigs/metrics-server/releases/download/v0.5.0/components.yaml
  

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

  # clone 源码
  git clone https://github.com/kubernetes-sigs/metrics-server.git
  #选择要制作的镜像tag
  git tag
  git checkout v0.4.1
  #检测基础镜像是不是也有gcr.io？
  ➜  metrics-server git:(91dbeeb) cat Dockerfile | grep -i from
  FROM golang:1.14.2 as build
  FROM gcr.io/distroless/static:latest
  COPY --from=build /go/src/sigs.k8s.io/metrics-server/metrics-server /
  #解决所有需要科学上网的镜像问题gcr.io
  下载gcr-io-distroless-stati.rar https://download.csdn.net/download/shenhonglei1234/13684957
  docker load -i gcr-io-distroless-stati.rar 
  docker image | grep static
  ## 制作镜像
  mkdir build
  docker build . -f Dockerfile -t k8s.gcr.io/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
  #如果这里下载比较慢的话，或者不能下载，请使用直接执行代理
  #请参考 https://blog.csdn.net/shenhonglei1234/article/details/107933030
  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 gcr.io/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.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 https://github.com/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
  clusterrole.rbac.authorization.k8s.io/system:aggregated-metrics-reader created
  clusterrole.rbac.authorization.k8s.io/system:metrics-server created
  rolebinding.rbac.authorization.k8s.io/metrics-server-auth-reader created
  clusterrolebinding.rbac.authorization.k8s.io/metrics-server:system:auth-delegator created
  clusterrolebinding.rbac.authorization.k8s.io/system:metrics-server created
  service/metrics-server created
  deployment.apps/metrics-server created
  apiservice.apiregistration.k8s.io/v1beta1.metrics.k8s.io 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.gcr.io/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 ）。