精华内容
下载资源
问答
  • 2021-03-05 18:39:26

    开发测试环境 k8s node节点磁盘不足运维

    在开发测试环境容器运行了一段时间之后会出现一些问题
    常见的问题就是磁盘资源不足
    现在针对开发测试环境资源不足的情况最快的处理方案

    排查服务器pod 问题

    kubectl -n ns describe po podname
    kubectl  get nodes -o wide
    kubectl -n ns get pod  -o wide | grep -v Running
    kubectl -n ns  describe po podname
    kubectl describe node nodename
    kubectl get pod --all-namespaces -o wide | grep Pending
    kubectl -n ns  get pod  -o wide | grep -v Running
    

    解决服务器节点磁盘问题

    #驱逐节点并迁移容器到可用节点
    kubectl drain nodename  --ignore-daemonsets
    #停止调度
    kubectl  cordon nodename  
    #允许调度
    # kubectl uncordon nodename
    #删除节点
    kubectl delete node nodename
    #创建加入节点token
    kubeadm token  create --print-join-co
    更多相关内容
  • k8s node节点监控

    2018-06-08 17:17:29
    k8s node节点监控,可以显示node节点信息,监控node集群节点的状态
  • K8S node节点not ready

    千次阅读 2021-07-22 15:15:22
    部署K8s node 节点not ready root@n226-060-152:/opt/cni/bin# kubectl get node NAME STATUS ROLES AGE VERSION n224-214-218 NotReady <none> 119s v1.18.4 n226-060-152 Ready master 21h v1.18.4 n226-070...

    部署K8s
    node 节点not ready

    root@n226-060-152:/opt/cni/bin# kubectl get node
    NAME           STATUS     ROLES    AGE    VERSION
    n224-214-218   NotReady   <none>   119s   v1.18.4
    n226-060-152   Ready      master   21h    v1.18.4
    n226-070-127   NotReady   <none>   76m    v1.18.4
    n226-075-141   NotReady   <none>   82m    v1.18.4
    

    node 节点查看日志
    sudo journalctl -u kubelet -n 100 --no-pager

    Jul 22 15:10:30 n224-214-218 kubelet[2353397]: I0722 15:10:30.621814 2353397 docker_service.go:353] docker cri received runtime config &RuntimeConfig{NetworkConfig:&NetworkConfig{PodCidr:10.244.3.0/24,},}
    Jul 22 15:10:30 n224-214-218 kubelet[2353397]: I0722 15:10:30.622415 2353397 kubelet_network.go:77] Setting Pod CIDR:  -> 10.244.3.0/24
    Jul 22 15:10:30 n224-214-218 kubelet[2353397]: I0722 15:10:30.667034 2353397 status_manager.go:158] Starting to sync pod status with apiserver
    Jul 22 15:10:30 n224-214-218 kubelet[2353397]: I0722 15:10:30.667082 2353397 kubelet.go:1821] Starting kubelet main sync loop.
    Jul 22 15:10:30 n224-214-218 kubelet[2353397]: E0722 15:10:30.667123 2353397 kubelet.go:1845] skipping pod synchronization - [container runtime status check may not have completed yet, PLEG is not healthy: pleg has yet to be successful]
    Jul 22 15:10:30 n224-214-218 kubelet[2353397]: E0722 15:10:30.768762 2353397 kubelet.go:1845] skipping pod synchronization - container runtime status check may not have completed yet
    Jul 22 15:10:30 n224-214-218 kubelet[2353397]: E0722 15:10:30.969358 2353397 kubelet.go:1845] skipping pod synchronization - container runtime status check may not have completed yet
    Jul 22 15:10:31 n224-214-218 kubelet[2353397]: I0722 15:10:31.051390 2353397 cpu_manager.go:184] [cpumanager] starting with none policy
    Jul 22 15:10:31 n224-214-218 kubelet[2353397]: I0722 15:10:31.051406 2353397 cpu_manager.go:185] [cpumanager] reconciling every 10s
    Jul 22 15:10:31 n224-214-218 kubelet[2353397]: I0722 15:10:31.051429 2353397 state_mem.go:36] [cpumanager] initializing new in-memory state store
    Jul 22 15:10:31 n224-214-218 kubelet[2353397]: I0722 15:10:31.058700 2353397 policy_none.go:43] [cpumanager] none policy: Start
    Jul 22 15:10:31 n224-214-218 kubelet[2353397]: W0722 15:10:31.090594 2353397 manager.go:597] Failed to retrieve checkpoint for "kubelet_internal_checkpoint": checkpoint is not found
    Jul 22 15:10:31 n224-214-218 kubelet[2353397]: I0722 15:10:31.091915 2353397 plugin_manager.go:114] Starting Kubelet Plugin Manager
    Jul 22 15:10:31 n224-214-218 kubelet[2353397]: E0722 15:10:31.105446 2353397 kubelet.go:2187] Container runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized
    Jul 22 15:10:31 n224-214-218 kubelet[2353397]: I0722 15:10:31.373531 2353397 topology_manager.go:233] [topologymanager] Topology Admit Handler
    Jul 22 15:10:31 n224-214-218 kubelet[2353397]: I0722 15:10:31.381300 2353397 topology_manager.go:233] [topologymanager] Topology Admit Handler
    Jul 22 15:10:31 n224-214-218 kubelet[2353397]: I0722 15:10:31.447630 2353397 reconciler.go:224] operationExecutor.VerifyControllerAttachedVolume started for volume "kube-proxy" (UniqueName: "kubernetes.io/configmap/7dc21d2f-16c0-49da-b61f-8b7d3e9e385a-kube-proxy") pod "kube-proxy-dfcxb" (UID:"7dc21d2f-16c0-49da-b61f-8b7d3e9e385a")
    Jul 22 15:10:31 n224-214-218 kubelet[2353397]: I0722 15:10:31.447677 2353397 reconciler.go:224] operationExecutor.VerifyControllerAttachedVolume started for volume "xtables-lock" (UniqueName: "kubernetes.io/host-path/7dc21d2f-16c0-49da-b61f-8b7d3e9e385a-xtables-lock") pod "kube-proxy-dfcxb" (UID: "7dc21d2f-16c0-49da-b61f-8b7d3e9e385a")
    Jul 22 15:10:31 n224-214-218 kubelet[2353397]: I0722 15:10:31.447726 2353397 reconciler.go:224] operationExecutor.VerifyControllerAttachedVolume started for volume "lib-modules" (UniqueName: "kubernetes.io/host-path/7dc21d2f-16c0-49da-b61f-8b7d3e9e385a-lib-modules") pod "kube-proxy-dfcxb" (UID: "7dc21d2f-16c0-49da-b61f-8b7d3e9e385a")
    

    在这里插入图片描述
    似乎是镜像拉取失败
    主节点
    kubectl get pods -n kube-system

    root@n226-060-152:/opt/cni/bin# kubectl get pods -n kube-system
    NAME                                   READY   STATUS              RESTARTS   AGE
    coredns-66bff467f8-nczr6               0/1     ImagePullBackOff    0          21h
    coredns-66bff467f8-vr296               0/1     ImagePullBackOff    0          21h
    etcd-n226-060-152                      1/1     Running             0          21h
    kube-apiserver-n226-060-152            1/1     Running             0          21h
    kube-controller-manager-n226-060-152   1/1     Running             0          21h
    kube-flannel-ds-2vlf9                  1/1     Running             0          21h
    kube-flannel-ds-5blq4                  1/1     Running             0          6m53s
    kube-flannel-ds-mqczm                  0/1     Init:0/1            0          81m
    kube-flannel-ds-mzkw4                  0/1     Init:0/1            0          87m
    kube-proxy-c94sn                       0/1     ContainerCreating   0          81m
    kube-proxy-dfcxb                       1/1     Running             0          6m53s
    kube-proxy-gzk8b                       0/1     ContainerCreating   0          87m
    kube-proxy-vz54p                       1/1     Running             0          21h
    kube-scheduler-n226-060-152            1/1     Running             0          21h
    

    确认拉取镜像失败

    查看pod详情

    kubectl describe pod coredns-66bff467f8-nczr6 --namespace=kube-system
    在这里插入图片描述

    在这里插入图片描述

    docker pull registry.aliyuncs.com/google_containers/coredns:1.6.7
    docker tag registry.aliyuncs.com/google_containers/coredns:1.6.7 k8s.gcr.io/coredns:1.6.7
    docker rmi registry.aliyuncs.com/google_containers/coredns:v1.6.7
    
    
    展开全文
  • 使用sjyt-k8s搭建NFS服务作为后端存储。 K8S集群版本为: [root@sjyt-k8s01 ~]# kubectl get nodes NAME STATUS ROLES AGE VERSION sjyt-k8s01 Ready <none> 13d v1.14.2 sjyt-k8s02 Ready <none> 13d v...

    K8S:部署prometheus+node-exporter实现监控k8s node

    一、前言

    背景描述:
    kubernetes使用三个节点搭建的集群,一个work节点。使用sjyt-k8s搭建NFS服务作为后端存储。
    K8S集群版本为:

    [root@sjyt-k8s01 ~]# kubectl get nodes
    NAME         STATUS   ROLES    AGE   VERSION
    sjyt-k8s01   Ready    <none>   13d   v1.14.2
    sjyt-k8s02   Ready    <none>   13d   v1.14.2
    sjyt-k8s03   Ready    <none>   13d   v1.14.2
    sjyt-k8s04   Ready    <none>   13d   v1.14.2
    

    k8s二进制下载地址:https://dl.k8s.io/v1.14.2/kubernetes-server-linux-amd64.tar.gz

    storageclass 动态存储:

    [root@sjyt-k8s01 ~]# kubectl get storageclass
    NAME                 PROVISIONER      AGE
    course-nfs-storage   fuseim.pri/ifs   13d
    

    安装部署prometheus
    以上K8S二进制中包含了prometheus的yaml部署文件
    注意:prometheus需要事先准备后端存储,本文使用storageclass(NFS)为后端存储
    软件包我解压到/opt/k8s/work目录下、目录路径如下:

    [root@sjyt-k8s01 prometheus]# pwd
    /opt/k8s/work/kubernetes/cluster/addons/prometheus
    

    prometheus下文件如下。

    [root@sjyt-k8s01 prometheus]# ls -l
    total 76
    -rw-rw-r-- 1 root root  402 May 14  2019 alertmanager-configmap.yaml
    -rw-rw-r-- 1 root root 2183 May 14  2019 alertmanager-deployment.yaml
    -rw-rw-r-- 1 root root  319 May 14  2019 alertmanager-pvc.yaml
    -rw-rw-r-- 1 root root  371 May 14  2019 alertmanager-service.yaml
    -rw-rw-r-- 1 root root 2379 May 14  2019 kube-state-metrics-deployment.yaml
    -rw-rw-r-- 1 root root 2239 May 14  2019 kube-state-metrics-rbac.yaml
    -rw-rw-r-- 1 root root  506 May 14  2019 kube-state-metrics-service.yaml
    -rw-rw-r-- 1 root root 1490 May 14  2019 node-exporter-ds.yml
    -rw-rw-r-- 1 root root  424 May 14  2019 node-exporter-service.yaml
    -rw-rw-r-- 1 root root  150 May 14  2019 OWNERS
    -rw-rw-r-- 1 root root 5622 Jun 11 21:41 prometheus-configmap.yaml
    -rw-r--r-- 1 root root 5440 Jun 11 21:39 prometheus-configmap.yaml_0611
    drwxr-xr-x 2 root root  115 Dec 20 14:58 prometheus_pv_nfs
    -rw-rw-r-- 1 root root 1079 May 14  2019 prometheus-rbac.yaml
    -rw-rw-r-- 1 root root  364 Dec 10  2019 prometheus-service.yaml
    drwxr-xr-x 2 root root  112 Jun  6 12:53 prometheus_stateclass
    -rw-rw-r-- 1 root root 3118 Dec 20 15:14 prometheus-statefulset.yaml
    -rw-rw-r-- 1 root root  349 May 14  2019 README.md
    

    二、修改prometheus-statefulset.yaml文件

         terminationGracePeriodSeconds: 300
          volumes:
            - name: config-volume
              configMap:
                name: prometheus-config
      volumeClaimTemplates:
      - metadata:
          name: prometheus-data
        spec:
          storageClassName: standard #修改为自己K8S集群中的后端存储名称,这里使用course-nfs-storage
          accessModes:
            - ReadWriteOnce
          resources:
            requests:
              storage: "16Gi"
    

    修改后:

         terminationGracePeriodSeconds: 300
          volumes:
            - name: config-volume
              configMap:
                name: prometheus-config
      volumeClaimTemplates:
      - metadata:
          name: prometheus-data
        spec:
          #storageClassName: managed-nfs-storage
          storageClassName: course-nfs-storage
          accessModes:
            - ReadWriteMany
          resources:
            requests:
              storage: "80Gi"
    

    三、修改prometheus-configmap.yaml

    data:
      prometheus.yml: |
        scrape_configs:
        - job_name: prometheus
          static_configs:
          - targets:
            - localhost:9090
    
        - job_name: kubernetes-apiservers
          kubernetes_sd_configs:
          - role: endpoints
          relabel_configs:
          - action: keep
            regex: default;kubernetes;https
            source_labels:
            - __meta_kubernetes_namespace
            - __meta_kubernetes_service_name
            - __meta_kubernetes_endpoint_port_name
          scheme: https
          tls_config:
            ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
            insecure_skip_verify: true
          bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token
    
        - job_name: kubernetes-nodes-kubelet
          kubernetes_sd_configs:
          - role: node
          relabel_configs:
          - action: labelmap
            regex: __meta_kubernetes_node_label_(.+)
          scheme: https
          tls_config:
            ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
            insecure_skip_verify: true
          bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token
    

    在- job_name: kubernetes-apiservers上方添加node监控,添加后效果如下

    data:
      prometheus.yml: |
        scrape_configs:
        - job_name: prometheus
          static_configs:
          - targets:
            - localhost:9090
    
        - job_name: k8s-nodes
          static_configs:
          - targets:
            - 192.168.5.241:9100
            - 192.168.5.242:9100
            - 192.168.5.243:9100
            - 192.168.5.244:9100
    
        - job_name: kubernetes-apiservers
          kubernetes_sd_configs:
          - role: endpoints
          relabel_configs:
          - action: keep
            regex: default;kubernetes;https
    

    查看node-exporter暴露的端口

    apiVersion: v1
    kind: Service
    metadata:
      name: node-exporter
      namespace: kube-system
      annotations:
        prometheus.io/scrape: "true"
      labels:
        kubernetes.io/cluster-service: "true"
        addonmanager.kubernetes.io/mode: Reconcile
        kubernetes.io/name: "NodeExporter"
    spec:
      clusterIP: None
      ports:
        - name: metrics
          port: 9100
          protocol: TCP
          targetPort: 9100
      selector:
        k8s-app: node-exporter
    

    四、部署prometheus开头的yaml,及node-exporter的yaml。

    [root@sjyt-k8s01 prometheus]# kubectl apply -f ./prometheus-*
    [root@sjyt-k8s01 prometheus]# kubectl apply -f ./node-exporter*
    
    

    部署后查看prometheus暴露的端口

    [root@sjyt-k8s01 prometheus]# kubectl get svc -o wide -n kube-system
    NAME                   TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)                  AGE     SELECTOR
    kube-dns               ClusterIP   10.254.0.2       <none>        53/UDP,53/TCP,9153/TCP   13d     k8s-app=kube-dns
    kubernetes-dashboard   NodePort    10.254.8.22      <none>        443:32399/TCP            13d     k8s-app=kubernetes-dashboard
    metrics-server         ClusterIP   10.254.49.213    <none>        443/TCP                  13d     k8s-app=metrics-server
    node-exporter          ClusterIP   None             <none>        9100/TCP                 7d18h   k8s-app=node-exporter
    prometheus             NodePort    10.254.211.234   <none>        9090:30200/TCP           8d      k8s-app=prometheus
    

    网页打开prometheus,接着点击Status ---- Targets 查看监控的目标。
    如下图所示已经监控到每个Node的数据。
    在这里插入图片描述

    五、Grafana展示

    import 8919 模板
    在这里插入图片描述

    选择数据源 :prometheus(事先已添加)
    在这里插入图片描述

    展开全文
  • k8s node节点停机维护,pod如何迁移?

    千次阅读 2020-09-01 08:48:22
    k8s集群中的node节点要升级内存,以应对服务迁入、pod扩缩容导致的资源短缺,需要对node节点进行停机维护,那么此时node节点上的pod应该如何处理呢? 下面我们来看一下。 默认迁移 当node节点关机后,k8s集群并没有...

    需求

    k8s集群中的node节点要升级内存,以应对服务迁入、pod扩缩容导致的资源短缺,需要对node节点进行停机维护,那么此时node节点上的pod应该如何处理呢?

    下面我们来看一下。

    默认迁移

    当node节点关机后,k8s集群并没有立刻发生任何自动迁移动作,如果该node节点上的副本数为1,则会出现服务中断的情况。其实事实并非如此,k8s在等待5分钟后,会自动将停机node节点上的pod自动迁移到其他node节点上

    具体过程如下:

    # 1.模拟node节点停机,停止kubelet
    systemctl stop kubelet
    
    # 2.集群状态
    # 此时停机的node点处于NotReady状态
    # kubectl get node
    NAME                STATUS     ROLES     AGE   VERSION
    k8s-3-217   Ready        master     88d   v1.18.2
    k8s-3-218   NotReady   <none>   88d   v1.18.2
    k8s-3-219   Ready        <none>   88d   v1.18.2
    
    # 3.监控pod状态,大约等待5分钟左右,集群开始有动作
    # kubectl get pod -n test -o wide -n test -w
    NAME                                   READY   STATUS    RESTARTS   AGE   IP             NODE           NOMINATED NODE   READINESS GATES
    helloworld-79956d95b4-q7jjg            1/1     Running   0          19h   10.244.1.154   k8s-3-218   <none>           <none>
    helloworld-79956d95b4-q7jjg            1/1     Running   0          19h   10.244.1.154   k8s-3-218   <none>           <none>
    # 5分钟后,pod终止并进行重建
    helloworld-79956d95b4-q7jjg            1/1     Terminating   0          19h   10.244.1.154   k8s-3-218   <none>           <none>
    helloworld-79956d95b4-nnlrq            0/1     Pending       0          0s    <none>         <none>         <none>           <none>
    helloworld-79956d95b4-nnlrq            0/1     Pending       0          0s    <none>         k8s-3-219   <none>           <none>
    helloworld-79956d95b4-nnlrq            0/1     ContainerCreating   0          1s    <none>         k8s-3-219   <none>           <none>
    
    helloworld-79956d95b4-nnlrq            0/1     Running             0          3s    10.244.2.215   k8s-3-219   <none>           <none>
    helloworld-79956d95b4-nnlrq            1/1     Running             0          66s   10.244.2.215   k8s-3-219   <none>           <none>
    
    # 4.访问测试:在pod重新迁移到其他node节点时,服务是不可用的。
    # curl -x 192.168.3.219:80 hello.test.cn
    <html>
    <head><title>503 Service Temporarily Unavailable</title></head>
    <body>
    <center><h1>503 Service Temporarily Unavailable</h1></center>
    <hr><center>nginx/1.17.8</center>
    
    # 5.迁移完毕:服务正常访问
    # curl -x 192.168.3.219:80 hello.test.cn
    Hello,world!
    

    从以上过程看出,停机node节点上的pod在5分钟后先终止再重建,直到pod在新节点启动并由readiness探针检测正常后并处于1\1 Running状态才可以正式对外提供服务。因此服务中断时间=停机等待5分钟时间+重建时间+服务启动时间+readiness探针检测正常时间

    在此大家可能有一个疑问:为什么pod在5分钟后开始迁移呢?
    此时需要涉及到k8s中的Taint(污点)和 Toleration(容忍),这是从Kubernetes 1.6开始提供的高级调度功能。Taint和Toleration相互配合,可以避免pod被分配到不合适的节点上。每个节点上都可以应用一个或多个Taint,这表示对于那些不能容忍Taint的pod,是不会被该节点接受的。如果将Toleration应用于pod上,则表示这些pod可以(但不要求)被调度到具有匹配Taint的节点上。

    具体来分析下:

    # 1.查看停止服务节点的状态
    # kubelet停止后,node节点自动添加了Taints;
    # kubectl describe node k8s-3-218
    
    Name:               k8s-3-218
    Roles:              <none>
    CreationTimestamp:  Fri, 22 May 2020 11:36:16 +0800
    Taints:             node.kubernetes.io/unreachable:NoExecute
                        node.kubernetes.io/unreachable:NoSchedule
    Unschedulable:      false
    Lease:
      HolderIdentity:  k8s-3-218
      AcquireTime:     <unset>
      RenewTime:       Wed, 19 Aug 2020 09:31:22 +0800
    Conditions:
      Type                 Status    LastHeartbeatTime                 LastTransitionTime                Reason              Message
      ----                 ------    -----------------                 ------------------                ------              -------
      NetworkUnavailable   False     Tue, 18 Aug 2020 09:07:59 +0800   Tue, 18 Aug 2020 09:07:59 +0800   FlannelIsUp         Flannel is running on this node
      MemoryPressure       Unknown   Wed, 19 Aug 2020 09:29:56 +0800   Wed, 19 Aug 2020 09:32:07 +0800   NodeStatusUnknown   Kubelet stopped posting node status.
      DiskPressure         Unknown   Wed, 19 Aug 2020 09:29:56 +0800   Wed, 19 Aug 2020 09:32:07 +0800   NodeStatusUnknown   Kubelet stopped posting node status.
      PIDPressure          Unknown   Wed, 19 Aug 2020 09:29:56 +0800   Wed, 19 Aug 2020 09:32:07 +0800   NodeStatusUnknown   Kubelet stopped posting node status.
      Ready                Unknown   Wed, 19 Aug 2020 09:29:56 +0800   Wed, 19 Aug 2020 09:32:07 +0800   NodeStatusUnknown   Kubelet stopped posting node status.
    ...省略...
    Events:              <none>
    
    # 2.查看pod状态
    # kubectl describe pod helloworld-8565c4687b-rrfmj -n test
    Name:                      helloworld-8565c4687b-rrfmj
    Namespace:                 test
    Priority:                  0
    ......
    Node-Selectors:  <none>
    Tolerations:     node.kubernetes.io/not-ready:NoExecute for 300s
                     node.kubernetes.io/unreachable:NoExecute for 300s
    Events:          <none>
    

    此时pod的Tolerations 默认对于具有相应Taint的node节点容忍时间为300s,超过此时间pod将会被驱逐到其他可用node节点上。因此5分钟后node节点上所有的pod重新被调度,在此期间服务是中断的。

    既然默认的pod迁移无法避免服务中断,那么我们在node节点停机前,我们手动迁移是否可以?

    手动迁移

    为避免等待默认的5分钟,我们还可以使用cordon、drain、uncordor三个命令实现节点的主动维护。此时需要用到以下三个命令:

    • cordon:标记节点不可调度,后续新的pod不会被调度到此节点,但是该节点上的pod可以正常对外服务;
    • drain:驱逐节点上的pod至其他可调度节点;
    • uncordon:标记节点可调度;

    具体操作过程如下:

    # 1.标记节点不可调度
    # kubectl cordon k8s-3-219
    node/k8s-3-219 cordoned
    
    # 查看节点状态,此时219被标记为不可调度
    # kubectl get node
    NAME           STATUS                     ROLES    AGE   VERSION
    k8s-3-217   Ready                      master   89d   v1.18.2
    k8s-3-218   Ready                      <none>   88d   v1.18.2
    k8s-3-219   Ready,SchedulingDisabled   <none>   88d   v1.18.2
    
    # 2.驱逐pod
    # kubectl drain k8s-3-219 --delete-local-data --ignore-daemonsets --force
    node/k8s-3-219 already cordoned
    WARNING: ignoring DaemonSet-managed Pods: ingress-nginx/nginx-ingress-controller-gmzq6, kube-system/kube-flannel-ds-amd64-5gfwh, kube-system/kube-proxy-vdckk
    evicting pod kube-system/tiller-deploy-6c65968d87-75pfm
    evicting pod kube-system/metrics-server-7f96bbcc66-bgt7j
    evicting pod test/helloworld-79956d95b4-nnlrq
    
    # 参数如下:
    --delete-local-data  删除本地数据,即使emptyDir也将删除;
    --ignore-daemonsets  忽略DeamonSet,否则DeamonSet被删除后,仍会自动重建;
    --force  不加force参数只会删除该node节点上的ReplicationController, ReplicaSet, DaemonSet,StatefulSet or Job,加上后所有pod都将删除;
    
    # 3. 查看驱逐,219上的pod迁移到218上了。
    # kubectl get pod -n test -o wide
    NAME                                   READY   STATUS        RESTARTS   AGE   IP             NODE           NOMINATED NODE   READINESS GATES
    helloworld-79956d95b4-gg58c            0/1     Running       0          20s   10.244.1.165   k8s-3-218   <none>           <none>
    helloworld-79956d95b4-nnlrq            1/1     Terminating   0          77m   10.244.2.215   k8s-3-219   <none>           <none>
    

    此时与默认迁移不同的是,pod会先重建再终止,此时的服务中断时间=重建时间+服务启动时间+readiness探针检测正常时间,必须等到1/1 Running服务才会正常。因此在单副本时迁移时,服务终端是不可避免的

    如何能够做到平滑迁移呢?我们继续往下看。

    平滑迁移

    要做到平滑迁移就需要用的pdb(PodDisruptionBudget),即主动驱逐保护。无论是默认迁移和手动迁移,都会导致服务中断,而pdb能可以实现节点维护期间不低于一定数量的pod正常运行,从而保证服务的可用性。

    在仍以helloworld为例,由于只有一个副本,因此需要保证维护期间这个副本在迁移完成后,才会终止。

    # 从218 驱逐到 219
    # 1.标记节点不可调度
    # kubectl cordon k8s-3-218
    node/k8s-3-218 cordoned
    
    # 2.新建pdb
    vim pdb-test.yaml
    apiVersion: policy/v1beta1
    kind: PodDisruptionBudget
    metadata:
      name: pdb-test
      namespace: test
    spec:
      minAvailable: 1
      selector:
        matchLabels:
          app: helloworld
    
    # 2.应用并查看状态
    # kubectl apply -f pdb-test.yaml
    # kubectl get pdb -n test
    NAME       MIN AVAILABLE   MAX UNAVAILABLE   ALLOWED DISRUPTIONS   AGE
    pdb-test   1                         N/A                          0                                       7s
    
    # 3.驱逐
    # kubectl drain k8s-3-218 --delete-local-data --ignore-daemonsets --force
    node/k8s-3-218 already cordoned
    WARNING: ignoring DaemonSet-managed Pods: ingress-nginx/nginx-ingress-controller-hhb6h, kube-system/kube-flannel-ds-amd64-pb4d7, kube-system/kube-proxy-rzdcj
    evicting pod kube-system/tiller-deploy-6c65968d87-ktqmm
    evicting pod kube-system/metrics-server-7f96bbcc66-6p6wm
    evicting pod test/helloworld-79956d95b4-gg58c
    error when evicting pod "helloworld-79956d95b4-gg58c" (will retry after 5s): Cannot evict pod as it would violate the pod's disruption budget.
    evicting pod test/helloworld-79956d95b4-gg58c
    error when evicting pod "helloworld-79956d95b4-gg58c" (will retry after 5s): Cannot evict pod as it would violate the pod's disruption budget.
    pod/tiller-deploy-6c65968d87-ktqmm evicted
    
    #此时由于只有一个副本,最小可用为1,则ALLOWED就为0,因此在一个副本通过pdb是不会发生驱逐的。我们需要先扩容,将副本数调整为大于1。
    
    # 3.手动调整副本数,将replicas为2
    kubectl edit deploy helloworld -n test
    # 再次查看pdb
    # kubectl get pdb -n test
    NAME       MIN AVAILABLE   MAX UNAVAILABLE   ALLOWED DISRUPTIONS   AGE
    pdb-test   1               N/A               1                     13m
    
    #此时最小可用为1 ,ALLOWED为1,此时是数量会自动计算。
    
    # 4.驱逐
    # kubectl drain k8s-3-218 --delete-local-data --ignore-daemonsets --force
    
    # 5.维护完毕,将node调整为可调度
    # kubectl uncordon k8s-3-218
    

    本次驱逐,由于helloworld始终保持有一个pod在提供服务,因此服务是不中断的
    最后将副本数可以调节为1并将node节点调整为可调度,维护完毕。

    总结

    通过简单了解了Taint(污点)和 Toleration(容忍)作用,我们既可以通过设置tolerationSeconds来缩短等待时间,也可以自行定义匹配规则实现符合实际情况的调度规则。
    另外还要注意先重建再终止先终止再重建,在此过程中服务启动时间和探针检测时间决定你的服务中断时间。

    展开全文
  • k8s nodePort外网访问不通

    千次阅读 2021-06-11 11:08:36
    刚学k8s,这可能在老手眼里是个弱智问题,不过事情总是要一步步做的嘛。 先描述一下我的环境以及碰到的问题: 一个mater节点,两个node节点。我部署了一个应用,副本数是3个,所以有3个pod。问题就是我用postman去...
  • k8s版本:v1.16.10 安装方式:二进制 删除node01节点: kubectl delete node node01 在node01节点上删除master节点批准其加入集群时,自动颁发的证书: #自动颁发的证书,在Node节点上的目录:/opt/kubernetes/ssl/...
  • K8s nodePort、port、targetPort、hostPort详解 1. nodePort 外部流量访问k8s集群中service入口的一种方式(另一种方式是LoadBalancer),即nodeIP:nodePort是提供给外部流量访问k8s集群中service的入口。比如外部...
  • k8s nodeSelector和affinity

    千次阅读 2018-12-08 23:18:35
    nodeSelector 1.分配pod到node的方法 通过node label selector...2.nodeSelector 是k8s早起提供的节点选择器实现 1)首先为nodes打对应的label kubectl label nodes master disktype=ssd 2)创建yaml文件,ng...
  • 修改/etc/sysconfig/flanneld文件,将FLANNEL_...HOSTNAME修改为node节点的ip,将KUBELET_API_SERVER修改为master主机的ip 修改完上面的三个文件之后,重启node节点的k8s服务就行 systemctl restart kubelet.service
  • K8S Node启动后 处于NotReady状态的问题

    千次阅读 2020-10-22 18:23:00
    在kubernetes集群中,每个Node节点都会启动kubelet进程,用来处理Master节点下发到本节点的任务,管理Pod和其中的容器。kubelet会在API Server上注册节点信息,定期向Master汇报节点资源使用情况,并通过cAdvisor...
  • K8s Node节点ROLES为none

    千次阅读 2020-09-17 16:33:26
    K8s Node节点ROLES为none kubectl get nodes kubectl label node k8s-node01(节点名称) node-role.kubernetes.io/worker=worker
  • k8s node节点为noready

    2020-09-17 16:31:24
    k8s node节点为noready 把admin.conf加入到环境变量里面 echo "export KUBECONFIG=/etc/kubernetes/admin.conf" >> ~/.bash_profile source ~/.bash_profile
  • 设置k8s node最大pod数量

    千次阅读 2021-07-29 15:53:41
    默认情况下k8s 一个node最多起110个pod. No more than 110 pods per node No more than 5000 nodes No more than 150000 total pods No more than 300000 total containers 如何修改一个node中起的pod数量呢? ...
  • k8s node节点删除及重新加入 列出所有nodes: kubectl get node 删除节点 kubectl delete node node3 kubectl delete type name 查看对应node上的pods信息: kubectl get pods -o wide | grep node3 重新加入 在...
  • kubeadm 安装的 k8s 集群 delete node 后重新添加回集群问题解决 1.问题描述 k8smaster节点坏掉,重新部署完k8s-master节点后node节点无法加入集群 报错如下 [root@k8s-node2 ~]# kubeadm join apiserver.demo:6443 ...
  • 记一次K8S node not ready 问题定位

    千次阅读 2019-07-16 11:19:58
    昨天晚上,针对K8S环境做了一次压测,50路并发实施,早上起来看监控,发现昨晚8点之后,系统好像都宕掉了,一看master节点和一个node节点状态变成了not ready,主要定位手段如下: 1. 查看master kubelet状态 ...
  • k8s node节点重启后遇到的问题及解决

    万次阅读 2019-08-16 15:43:06
    有一个node节点因为主机原因进行了重启, 主机启动之后,通过执行以下命令恢复了节点状态。 systemctl start docker systemctl start kubelet 在主节点查看所有节点都正常, ...k8s-master01 Ready ...
  • k8s学习 k8s使用nodeport方式配置service对外暴露服务1、创建yaml service.yaml 把集群中的mysql 服务对外暴露2、用node ip 访问 1、创建yaml service.yaml 把集群中的mysql 服务对外暴露 --- apiVersion: v1 kind: ...
  • k8s指定node调度

    2021-08-30 09:29:54
    可以看出可以使用节点的ip地址或者是在node节点添加标签,让pod调度器使用selector进行选择,这里我将使用两种方法,将主服务的beego端放在node1上,将判题器的两个judger放在node2上,judger1使用ip选择,judger2...
  • k8s nodeSelector&affinity

    万次阅读 2017-01-17 18:44:58
    1.分配pod到node的方法 通过node label selector实现约束pod运行到...2.nodeSelector 是k8s早起提供的节点选择器实现 1)首先为nodes打对应的label kubectl label nodes master disktype=ssd 2)创建yaml文件 cat >> n
  • client-go 获取 k8s node 节点信息

    千次阅读 2019-06-15 19:08:44
    //获取NODE fmt.Println("####### 获取node ######") nodes, err := clientset.CoreV1().Nodes().List(metav1.ListOptions{}) if err != nil { panic(err) } for _,nds := range nodes.Items { fmt.Printf(...
  • K8S Node节点报错The connection to the server localhost:8080 was refused - did you specify the right host or port? 今天在Kubernetes的从节点上运行命令【kubectl】出现了如下错误 [root@k8snode1 ...
  • k8s 下线node正确处理姿势

    千次阅读 2022-03-01 16:52:26
    [root@k8s-master1 ~]# kubectl get node -o wide NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME k8s-node1 Ready <none> 35d v1.17.5 1
  • K8s nodePort、port、targetPort、hostPort

    千次阅读 2020-03-16 16:22:17
    外部流量访问k8s集群中service入口的一种方式(另一种方式是LoadBalancer),即nodeIP:nodePort是提供给外部流量访问k8s集群中service的入口。比如外部用户要访问k8s集群中的一个Web应用,那么我们可以配置对应...
  • Kubernetes K8S之固定节点nodeName和nodeSelector调度详解与示例
  • k8s删除node节点

    千次阅读 2021-05-17 11:11:08
    k8s版本:V1.18.4 主机操作系统:CentOS Linux release 7.6.1810 (Core) #生产环境删除节点需要确认主机pod的数据目录,查看存储类型,若数据有用,必须备份数据,确定数据恢复方案后再操作。 1.查看集群节点信息: ...
  • k8s设置Node污点

    2021-03-26 14:32:03
    k8s设置Node污点 master节点设置taint 如果不想让master节点参与到正常的pod调度,则需要对master进行打污点标签,这样master就不会有pod创建(pod创建时可以进行容忍度设置,这样master还是可以进行pod调度) 污点...
  • k8s 添加 node

    2021-01-14 13:58:07
    当微服务不断增加时,资源不够用,需要增加新的node 修改hostname hostnamectl set-hostname xxxx 重启生效 安装必要的软件 yum -y install wget net-tools nfs-utils lrzsz gcc gcc-c++ make cmake\ libxml2-devel...
  • 平滑删除k8s node节点

    千次阅读 2019-10-09 20:46:28
    k8s集群投入使用后,由于缩容或者其他原因导致需要删除节点,可以通过以下步骤避免对应用造成影响。 首先,查看目前的集群情况 > kubectl get no NAME STATUS ROLES AGE VERSION b-master Ready master 168m v...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 76,607
精华内容 30,642
关键字:

k8s node

友情链接: Program20210323.rar