精华内容
下载资源
问答
  • k8s停止服务_Kubernetes 优雅停止Pod
    千次阅读
    2020-11-22 18:12:30

    博客地址:i4t.com


    首先我们先简单的分析一下"优雅的停止Pod"

    优雅停止(Graceful shutdown)这个说法来自于操作系统,比如我们windows关机系统首先会退出软件然后一步步到达关机,而相对的就是硬终止(Hard shutdown),简单的理解就是直接拔电源

    到了微服务中,网关会把流量分配给每个Pod节点上,比如我们上线更新Pod的时候

    • 如果我们直接将Pod杀死,那这部分流量就无法得到正确处理,会影响部分用户,通常来说网关或者注册中心会将我们的服务保持一个心跳,过了心跳超时之后会自动摘除我们的服务,但是有一个问题就是超时时间可能是30秒也可能是60秒,虽然不会影响我们的系统,但是会产生用户轻微抖动。
    • 如果我们在停止前执行一条命令,通知网关或者注册中心这台主机进行下线,那么注册中心就会标记这台主机已经下线,不进行流量转发,用户就不会有任何影响,这就是优雅停止,将滚动更新影响最小化

    Pod Hook

    Pod Hook是由kubelet发起的,当容器中的进程启动前或者容器中的进程终止之前运行,这是包含在容器的生命周期之中。我们可以同时为Pod中的所有容器都配置hook

    在k8s中,理想的状态是pod优雅释放,并产生新的Pod。但是并不是每一个Pod都会这么顺利

    • Pod卡死,处理不了优雅退出的命令或者操作
    • 优雅退出的逻辑有BUG,陷入死循环
    • 代码问题,导致执行的命令没有效果

    对于以上问题,k8s的Pod终止流程中还有一个"最多可以容忍的时间",即grace period (在pod的.spec.terminationGracePeriodSeconds字段定义),这个值默认是30秒,当我们执行kubectl delete的时候也可以通过--grace-period参数显示指定一个优雅退出时间来覆盖Pod中的配置,如果我们配置的grace period超过时间之后,k8s就只能选择强制kill Pod


    Kubernetes为我们提供了两种钩子函数:

    • PostStart :这个钩子在容器创建后立即执行。但是,并不能保证钩子将在容器ENTRYPOINT之前运行,因为没有参数传递给处理程序。 主要用于资源部署、环境准备等。不过需要注意的是如果钩子花费时间过长以及于不能运行或者挂起,容器将不能达到Running状态。
    • PreStop :钩子在容器终止前立即被调用。它是阻塞的,意味着它是同步的,所以它必须在删除容器的调用出发之前完成。主要用于优雅关闭应用程序、通知其他系统等。如果钩子在执行期间挂起,Pod阶段将停留在Running状态并且不会达到failed状态

    如果PostStart或者PreStop钩子失败,它会杀死容器。所以我们应该让钩子函数尽可能的轻量。当然有些情况下,长时间运行命令是合理的,比如在停止容器之前预先保留状态。

    这里稍微简单说一下Pod终止的过程

    • 用户发送命令删除Pod,Pod进入Terminating状态
    • service摘除Pod节点
    • 当kubelet看到Pod已被标记终止,开始执行preStop钩子,假如preStop hook的运行时间超过了grace period,kubelet会发送SIGTERM并等2秒
      官方文档介绍

    在Pod Hook钩子函数中有Exec和HTTP两种方式

    • Exec - 用于执行一段特定的命令,不过要注意的是该命令小号的资源会被计入容器
    • HTTP - 对容器上的特定端点执行HTTP请求

    基于PostStart命令演示

    首先我们先进行演示PostStart的两种方式

    第一种Exec
    我们echo一段话追加到 /tmp/message,在Pod启动前进行操作

    cat >>exec_test.yaml< /tmp/message'EOF

    使用kubectl apply -f exec_test.yaml进行创建

    可以通过下面查看结果,pod的目录已经有我们在yaml文件写的测试文件

    [root@abcdocker yaml]# kubectl get podNAME READY STATUS RESTARTS AGEabcdocker 1/1 Running 0 37s[root@abcdocker yaml]# kubectl exec -it -n default abcdocker /bin/bashroot@abcdocker:/# cat /tmp/messagehttps://i4t.comroot@abcdocker:/#root@abcdocker:/# exit

    创建容器后,Kubernetes立即发送postStart事件。但是,不能保证在调用Container的入口点之前先调用postStart处理程序。postStart处理程序相对于Container的代码异步运行,但是Kubernetes对容器的管理会阻塞,直到postStart处理程序完成。在postStart处理程序完成之前,容器的状态不会设置为RUNNING。

    第二种HTTP方式
    使用HttpGet配置Host、Path、Port

    apiVersion: v1kind: Podmetadata: name: abcdocker labels: name: abcdockerspec: containers: - name: abcdocker image: nginx ports: - containerPort: 80 lifecycle: postStart: httpGet: host: i4t.com path: index.html port: 80

    这里就不进行演示了,因为日志会看不到这个请求


    基于PreStop环境演示

    起因:
    在生产环境中使用spring框架,由于服务更新过程中,服务容器被直接充值,部分请求仍被分发到终止的容器(没有配置钩子,熟悉默认环境),导致服务出现500错误,这部分错误请求数据占用比较少,因为Pod滚动更新都是一对一。因为部分用户会产生服务器错误的情况,考虑使用优雅的终止方式,将错误请求降到最低,直至滚动更新不影响用户

    Eureka是一个基于REST的服务,作为Spring Cloud服务注册中心,用于定位服务来进行中间层服务器的负载均衡和故障转移。各服务启动时,会向Eureka Server注册自己的信息(IP、端口、服务信息等),Eureka Server会存储这些信息,微服务启动后,会周期性(默认30秒)的向Eureka Server发送心跳以续约自己的租期,并且可以从eureka中获取其他微服务的地址信息,执行相关逻辑

    67bfcfcae1ef22b42cd3549785b8dca1.png

    image_1dpi0idnqk981okaacv16l4172p9.png-61kB

    由于Eureka默认的心跳检测为30秒,当K8S下线Pod时Eureka会有30秒的异常问题,所以我们需要在Pod 停止前发送一条请求,通知Eureka进行下线操作,这样进行优雅的停止对用户的影响做到最小

    具体yaml如下

    apiVersion: v1kind: Podmetadata: name: abcdocker labels: name: abcdockerspec: containers: - name: abcdocker image: nginx ports: - containerPort: 80 lifecycle: preStop: exec: command: - bash - -c - 'curl -X POST --data DOWN http://127.0.0.1:8080/service-registry/instance-status -H "Content-Type: application/vnd.spring-boot.actuator.v2+json;charset=UTF-8";sleep 30'####### 参数解释127.0.0.1:8080 #代表eureka地址service-registry #代表注册中心DOWN #执行down请求sleep #等待30秒

    当我们删除Pod的时候就会执行上面的命令操作,并且等待30秒

    [root@yzsjhl82-135 yaml]# kubectl get podNAME READY STATUS RESTARTS AGEabcdocker 1/1 Running 0 2m16s[root@yzsjhl82-135 yaml]# kubectl delete pod abcdockerpod "abcdocker" deleted#此刻Pod不会马上删除,而是执行Exec中的命令,并等待30秒

    配置中添加了一个sleep时间,主要是作为服务停止的缓冲时间

    总结: Hook调用的日志没有暴露给Pod的Event,所以只能到通过describe命令来获取,如果是正常的操作是不会有event,如果有错误可以看到FailedPostStartHook和FailedPreStopHook这种event。并且如果Hook调用出现错误,则Pod状态不会是Running

    更多相关内容
  • K8S 设计本身就考虑到了各种故障的可能性,并提供了一些自愈机制以提高系统的容错性,但有些情况还是可能导致较长时间不可用,拉低服务可用性的指标。本文将结合生产实践经验,为大家提供一些最佳实践来最大化的提高...

    引言

    上一篇 文章我们围绕如何合理利用资源的主题做了一些最佳实践的分享,这一次我们就如何提高服务可用性的主题来展开探讨。

    怎样提高我们部署服务的可用性呢?K8S 设计本身就考虑到了各种故障的可能性,并提供了一些自愈机制以提高系统的容错性,但有些情况还是可能导致较长时间不可用,拉低服务可用性的指标。本文将结合生产实践经验,为大家提供一些最佳实践来最大化的提高服务可用性。

    如何避免单点故障?

    K8S 的设计就是假设节点是不可靠的。节点越多,发生软硬件故障导致节点不可用的几率就越高,所以我们通常需要给服务部署多个副本,根据实际情况调整 replicas 的值,如果值为 1 就必然存在单点故障,如果大于 1 但所有副本都调度到同一个节点了,那还是有单点故障,有时候还要考虑到灾难,比如整个机房不可用。

    所以我们不仅要有合理的副本数量,还需要让这些不同副本调度到不同的拓扑域(节点、可用区),打散调度以避免单点故障,这个可以利用 Pod 反亲和性来做到,反亲和主要分强反亲和与弱反亲和两种。

    先来看个强反亲和的示例,将 dns 服务强制打散调度到不同节点上:

    affinity:
     podAntiAffinity:
       requiredDuringSchedulingIgnoredDuringExecution:
       - labelSelector:
           matchExpressions:
           - key: k8s-app
             operator: In
             values:
             - kube-dns
         topologyKey: kubernetes.io/hostname
    • labelSelector.matchExpressions 写该服务对应 pod 中 labels 的 key 与 value,因为 Pod 反亲和性是通过判断 replicas 的 pod label 来实现的。
    • topologyKey 指定反亲和的拓扑域,即节点 label 的 key。这里用的 kubernetes.io/hostname 表示避免 pod 调度到同一节点,如果你有更高的要求,比如避免调度到同一个可用区,实现异地多活,可以用 failure-domain.beta.kubernetes.io/zone。通常不会去避免调度到同一个地域,因为一般同一个集群的节点都在一个地域,如果跨地域,即使用专线时延也会很大,所以 topologyKey 一般不至于用 failure-domain.beta.kubernetes.io/region
    • requiredDuringSchedulingIgnoredDuringExecution 调度时必须满足该反亲和性条件,如果没有节点满足条件就不调度到任何节点 (Pending)。

    如果不用这种硬性条件可以使用 preferredDuringSchedulingIgnoredDuringExecution 来指示调度器尽量满足反亲和性条件,即弱反亲和性,如果实在没有满足条件的,只要节点有足够资源,还是可以让其调度到某个节点,至少不会 Pending。

    我们再来看个弱反亲和的示例:

    affinity:
      podAntiAffinity:
        preferredDuringSchedulingIgnoredDuringExecution:
        - weight: 100
          podAffinityTerm:
            labelSelector:
              matchExpressions:
              - key: k8s-app
                operator: In
                values:
                - kube-dns
          topologyKey: kubernetes.io/hostname

    注意到了吗?相比强反亲和有些不同哦,多了一个 weight,表示此匹配条件的权重,而匹配条件被挪到了 podAffinityTerm 下面。

    如何避免节点维护或升级时导致服务不可用?

    有时候我们需要对节点进行维护或进行版本升级等操作,操作之前需要对节点执行驱逐 (kubectl drain),驱逐时会将节点上的 Pod 进行删除,以便它们漂移到其它节点上,当驱逐完毕之后,节点上的 Pod 都漂移到其它节点了,这时我们就可以放心的对节点进行操作了。

    有一个问题就是,驱逐节点是一种有损操作,驱逐的原理:

    1. 封锁节点 (设为不可调度,避免新的 Pod 调度上来)。
    2. 将该节点上的 Pod 删除。
    3. ReplicaSet 控制器检测到 Pod 减少,会重新创建一个 Pod,调度到新的节点上。

    这个过程是先删除,再创建,并非是滚动更新,因此更新过程中,如果一个服务的所有副本都在被驱逐的节点上,则可能导致该服务不可用。

    我们再来下什么情况下驱逐会导致服务不可用:

    1. 服务存在单点故障,所有副本都在同一个节点,驱逐该节点时,就可能造成服务不可用。
    2. 服务没有单点故障,但刚好这个服务涉及的 Pod 全部都部署在这一批被驱逐的节点上,所以这个服务的所有 Pod 同时被删,也会造成服务不可用。
    3. 服务没有单点故障,也没有全部部署到这一批被驱逐的节点上,但驱逐时造成这个服务的一部分 Pod 被删,短时间内服务的处理能力下降导致服务过载,部分请求无法处理,也就降低了服务可用性。

    针对第一点,我们可以使用前面讲的反亲和性来避免单点故障。

    针对第二和第三点,我们可以通过配置 PDB (PodDisruptionBudget) 来避免所有副本同时被删除,驱逐时 K8S 会 "观察" nginx 的当前可用与期望的副本数,根据定义的 PDB 来控制 Pod 删除速率,达到阀值时会等待 Pod 在其它节点上启动并就绪后再继续删除,以避免同时删除太多的 Pod 导致服务不可用或可用性降低,下面给出两个示例。

    示例一 (保证驱逐时 nginx 至少有 90% 的副本可用):

    apiVersion: policy/v1beta1
    kind: PodDisruptionBudget
    metadata:
      name: zk-pdb
    spec:
      minAvailable: 90%
      selector:
        matchLabels:
          app: zookeeper

    示例二 (保证驱逐时 zookeeper 最多有一个副本不可用,相当于逐个删除并等待在其它节点完成重建):

    apiVersion: policy/v1beta1
    kind: PodDisruptionBudget
    metadata:
      name: zk-pdb
    spec:
      maxUnavailable: 1
      selector:
        matchLabels:
          app: zookeeper

    如何让服务进行平滑更新?

    解决了服务单点故障和驱逐节点时导致的可用性降低问题后,我们还需要考虑一种可能导致可用性降低的场景,那就是滚动更新。为什么服务正常滚动更新也可能影响服务的可用性呢?别急,下面我来解释下原因。

    假如集群内存在服务间调用:

    f6a28698e3a06568759d3d0a94c37a98.png

    当 server 端发生滚动更新时:

    b847fa8ba0c515798ae93f6663879505.png

    发生两种尴尬的情况: 1. 旧的副本很快销毁,而 client 所在节点 kube-proxy 还没更新完转发规则,仍然将新连接调度给旧副本,造成连接异常,可能会报 "connection refused" (进程停止过程中,不再接受新请求) 或 "no route to host" (容器已经完全销毁,网卡和 IP 已不存在)。 2. 新副本启动,client 所在节点 kube-proxy 很快 watch 到了新副本,更新了转发规则,并将新连接调度给新副本,但容器内的进程启动很慢 (比如 Tomcat 这种 java 进程),还在启动过程中,端口还未监听,无法处理连接,也造成连接异常,通常会报 "connection refused" 的错误。

    针对第一种情况,可以给 container 加 preStop,让 Pod 真正销毁前先 sleep 等待一段时间,等待 client 所在节点 kube-proxy 更新转发规则,然后再真正去销毁容器。这样能保证在 Pod Terminating 后还能继续正常运行一段时间,这段时间如果因为 client 侧的转发规则更新不及时导致还有新请求转发过来,Pod 还是可以正常处理请求,避免了连接异常的发生。听起来感觉有点不优雅,但实际效果还是比较好的,分布式的世界没有银弹,我们只能尽量在当前设计现状下找到并实践能够解决问题的最优解。

    针对第二种情况,可以给 container 加 ReadinessProbe (就绪检查),让容器内进程真正启动完成后才更新 Service 的 Endpoint,然后 client 所在节点 kube-proxy 再更新转发规则,让流量进来。这样能够保证等 Pod 完全就绪了才会被转发流量,也就避免了链接异常的发生。

    最佳实践 yaml 示例:

    readinessProbe:
              httpGet:
                path: /healthz
                port: 80
                httpHeaders:
                - name: X-Custom-Header
                  value: Awesome
              initialDelaySeconds: 10
              timeoutSeconds: 1
            lifecycle:
              preStop:
                exec:
                  command: ["/bin/bash", "-c", "sleep 10"]

    健康检查怎么配才好?

    我们都知道,给 Pod 配置健康检查也是提高服务可用性的一种手段,配置 ReadinessProbe (就绪检查) 可以避免将流量转发给还没启动完全或出现异常的 Pod;配置 LivenessProbe (存活检查) 可以让存在 bug 导致死锁或 hang 住的应用重启来恢复。但是,如果配置配置不好,也可能引发其它问题,这里根据一些踩坑经验总结了一些指导性的建议:

    • 不要轻易使用 LivenessProbe,除非你了解后果并且明白为什么你需要它,参考 Liveness Probes are Dangerous
    • 如果使用 LivenessProbe,不要和 ReadinessProbe 设置成一样 (failureThreshold 更大)
    • 探测逻辑里不要有外部依赖 (db, 其它 pod 等),避免抖动导致级联故障
    • 业务程序应尽量暴露 HTTP 探测接口来适配健康检查,避免使用 TCP 探测,因为程序 hang 死时, TCP 探测仍然能通过 (TCP 的 SYN 包探测端口是否存活在内核态完成,应用层不感知)

    参考资料

    • Affinity and anti-affinity: https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity
    • Specifying a Disruption Budget for your Application: https://kubernetes.io/docs/tasks/run-application/configure-pdb/
    • Liveness Probes are Dangerous: https://srcco.de/posts/kubernetes-liveness-probes-are-dangerous.html
    展开全文
  • 一、 健康检查健康检查(Health Check)可用于服务运行的状态监控,比如腾讯旗下的DNSPOD的D监控,要求配置一个访问路径以判断网站是否可以正常访问实际上就是一个健康检查,当发现健康检查失败时会发送一个邮件通知...

    一、 健康检查


    健康检查(Health Check)可用于服务运行的状态监控,比如腾讯旗下的DNSPOD的D监控,要求配置一个访问路径以判断网站是否可以正常访问实际上就是一个健康检查,当发现健康检查失败时会发送一个邮件通知或者短信来告知网站管理员进行维修。

    d1c21005a663da70159c27cb151d2cbd.png

    而在现代一些分布式系统中,用户访问不再是单台主机,而是一个由成百上千台实例组成的集群,用户请求通过负载均衡器分发到不同的实例,负载均衡帮助解决单台服务器的访问压力,同时提高了系统的高可用性,而健康检查常常作为当前实例是否“可用”的判断标准。即:当系统发现某台实例健康检查不通过,负载均衡器将不会把流量导向该实例
    现在的云服务厂商比如AWS一般都为负载均衡配备了健康检查,而Kubernetes提供了两种探针来检查容器的状态,Liveliness和Readiness,根据官方文档,Liveliness探针是为了查看容器是否正在运行,翻译为存活探针(livenessProbe),Readiness探针是为了查看容器是否准备好接受HTTP请求,翻译为就绪探针(readinessProbe)。 在Kubernetes中,Pod是Kubernetes创建及管理的最小的可部署的计算单元,一个Pod由一个或者多个容器(Docker,rocket等等)组成,这些容器共享内存,网络以及运行容器的方式。
    在Kubernetes上下文中存活探针和就绪探针被称作健康检查。这些容器探针是一些周期性运行的小进程,这些探针返回的结果(成功,失败或者未知)反映了容器在Kubernetes的状态。基于这些结果,Kubernetes会判断如何处理每个容器,以保证弹性,高可用性和更长的正常运行时间。就绪探针
    就绪探针旨在让Kubernetes知道你的应用是否准备好为请求提供服务。Kubernetes只有在就绪探针通过才会把流量转发到Pod。如果就绪探针检测失败,Kubernetes将停止向该容器发送流量,直到它通过。

    存活探针


    Liveness探测器是让Kubernetes知道你的应用是否活着。如果你的应用还活着,那么Kubernetes就让它继续存在。如果你的应用程序已经死了,Kubernetes将移除Pod并重新启动一个来替换它。

    二、工作过程


    让我们看看两个场景,来看看就绪探针和存活探针怎样帮助我们构建更高可用的的系统。就绪探针
    一个应用往往需要一段时间来预热和启动,比如一个后端项目的启动需要连接数据库执行数据库迁移等等,一个Spring项目的启动也需要依赖Java虚拟机。即使该过程已启动,您的服务在启动并运行之前也无法运行。应用在完全就绪之前不应接收流量,但默认情况下,Kubernetes会在容器内的进程启动后立即开始发送流量。通过就绪探针探测,直到应用程序完全启动,然后才允许将流量发送到新副本。

    7825923a9412a2fbb411a9433469fb5e.gif

    存活探针
    让我们想象另一种情况,当我们的应用在成功启动以后因为一些原因“宕机”,或者遇到死锁情况,导致它无法响应用户请求。 在默认情况下,Kubernetes会继续向Pod发送请求,通过使用存活探针来检测,当发现服务不能在限定时间内处理请求(请求错误或者超时),就会重新启动有问题的pod。

    8b208bec37cb67416f2e48a7b345feaa.gif

    探针类型
    探针类型是指通过何种方式来进行健康检查,K8S有三种类型的探测:HTTP,Command和TCP。

    HTTP

    HTTP探测可能是最常见的探针类型。即使应用不是HTTP服务,也可以创建一个轻量级HTTP服务器来响应探测。比如让Kubernetes通过HTTP访问一个URL,如果返回码在200到300范围内,就将应用程序标记为健康状态,否则它被标记为不健康。 更多关于HTTP探测可参考这里。

    命令

    对于命令探测,是指Kubernetes在容器内运行命令。如果命令以退出代码0返回,则容器将标记为正常。否则,它被标记为不健康。 更多关于命令探测可参考这里。

    TCP

    最后一种类型的探测是TCP探测,Kubernetes尝试在指定端口上建立TCP连接。如果它可以建立连接,容器被认为是健康的; 如果它不能被认为是不健康的。这常用于对gRPC或FTP服务的探测。
    更多关于TCP探测可参考这里。

    初始探测延迟
    我们可以配置K8S健康检查运行的频率,检查成功或失败的条件,以及响应的超时时间。可参考有关配置探针的文档。
    存活探针探测失败会导致pod重新启动,所以配置初始探测延迟 initialDelaySeconds十分重要,要确保在应用准备之后探针才启动。否则,应用将无限重启!
    我建议使用p99启动时间作为initialDelaySeconds,或者取平均启动时间外加一个buffer。同时根据应用程序的启动时间更新这个值。

    三、举例


    以下面的一个K8S的配置代码为例,

    • K8S将在Pod开始启动后120s(initialDelaySeconds)后利用HTTP访问8080端口的 /actuator/health,如果超过10s或者返回码不在200~300内,就绪检查就失败
    • 类似的,在Pod运行过程中,K8S仍然会每隔5s(periodSeconds检测8080端口的 /actuator/health

    参考资料

    • 【Kubernetes best practices: Setting up health checks with readiness and liveness probes】
    • 【Kubernetes存活探针和就绪探针的最佳实践】

    原文链接:K8S使用就绪和存活探针配置健康检查 | 王柏元的博客

    b4141d3ccfd8fa830b9939483f8ea1a7.png
    关注《我是极客人》微信公众号
    展开全文
  • 9 月 7 日下午,在深圳南山软件产业基地,腾讯云 K8S & 云原生技术开放日成功落幕,来自腾讯、灵雀云、超参数科技、虎牙等资深技术专家与现场开发者共同探讨企业落地 K8S 的过程中遇到的难点以及解决问题的方法...

    9 月 7 日下午,在深圳南山软件产业基地,腾讯云 K8S & 云原生技术开放日成功落幕,来自腾讯、灵雀云、超参数科技、虎牙等资深技术专家与现场开发者共同探讨企业落地 K8S 的过程中遇到的难点以及解决问题的方法。

    K8S 逐渐成为容器编排的标准,越来越多的实现方式和使用方式已经成为了标准化的流程,但是在应用容器化、DevOps、监控、性能调优、发布方式等方面仍存在一些技术难点。在学习和实施容器交付的时候,我们对于 K8S 的认知和理解多少会存在一些偏差;在一些项目落地实施时,开发者经常会对 K8S 本身没有包含的问题或者是没有解决的问题而感到束手无策。腾讯云 K8S & 云原生技术开放日邀请多位技术专家,就和大家聊聊在 K8S 中存在哪些问题,以及如何解决这些问题。

    以下内容摘选自部分演讲速记,完整速记、音频和 PPT 请扫描文末二维码获取。 灵雀云微服务架构师 贺洪龙

    为什么要上云原生?这是灵雀云微服务架构师贺洪龙老师在演讲开始时问大家的问题。其实,传统的架构转向 DevOps 的架构,有点像以前 C/S 架构转向 B/S 架构,这是一个必然的趋势。不只是互联网公司适合用云原生,其实传统企业一样适用,像中石油、海关总署、一些央企或者是大型的部委,他们现在也非常关心整个核心系统的更新换代,这个需求并不是来源于业务或者技术的角度,部分是出于管理的角度。实现云原生要做到两点:一是能够统一企业所有内部的应用架构,包括中间件都可以统一;二是要做旧系统的迁移。比如一个部委的核心系统可能是 10 年前开发的,而如果开发一个新的核心系统要上线的话,开发周期有可能要两年。那么迁移的时候,原系统下有几百个子系统,如果还是采用单体结构,实现难度非常大。而且现在政府的系统其实对于互联网的需求很多,以前一套系统可以跑 10 年不用更新,现在的系统分分钟要修改、要迭代。因此对云原生架构的需求就变得非常强烈。

    DevOps 的价值体现在哪里?

    一是可以快速投放市场。有多快?每天迭代 N 个版本,贺洪龙提到,「我记得是 2016 年,某银行信用卡中心一周时间迭代了 183 次,每天差不多有几十次的小版本迭代,用蓝绿版本迭代,这样频繁的发布也只有通过 DevOps 才能实现。因为这个银行信用卡中心的运维服务器开发得很早,从 2014 年就开始做了,最开始是跑虚拟机。据我所知,做发布的兄弟们三个月走一批人,经常需要通宵,他们都受不了;相反,用容器来做,基本上可以不用加班,用两套环境,一套蓝、一套绿,下午做好部署,晚上一切网络就可以了。」

    二是降低成本。有 DevOps 工具之后,可以减少人工投入,进而减少因停机时间带来的损失。以手机制造厂商为例,他们的应用要发布,中间如果要停机,停一个小时损失 300 万。如果发布要 4 个小时,那就是 1200 万。而手机制造厂商的 IT 部门一年的投入也就一个亿。所以,通过 DevOps 基本上可以把 IT 的投入赚回来,这就是 DevOps 的价值体现。

    三是 DevOps 可以让开发者不用做一些低价值的事情,包括安装、部署、配置都可以用工具来做。DevOps 可以让运维人员做一些更高端的事情,类似于运维架构师的角色。DevOps 平台可以满足整个生命周期管理的需求,从最早的项目管理、需求再到构建、代码,到最后运维。


    腾讯高级工程师 卢承山

    腾讯高级工程师卢承山从实践的角度,重点介绍了云智中枢 AI 中台的建设思路,该平台要打通设备、数据、上层的应用,让应用开发者基于该平台,通过服务编排减少用户的开发量。

    云智中枢 AI 平台是从 0 到 1 构建是思路是:

    (1)技术选型,比如用什么微服务框架,用什么容器平台。

    (2)算法,算法可能有上百种,如何接入,并且发布成一个应用。

    (3)AI 产品怎么落地。还有一个持续交付的问题。

    很明确的是,用容器、微服务已经是一个趋势了。在架构选型方面,腾讯云容器服务 TKE 基于其强大的 K8S 的原生能力,同时对整个交付集成有一套完整的体系。

    腾讯云最新推出的企业级容器云平台 TKE(Tencent Kubernetes Engine )基于成熟的 Kubernetes 技术和生态,能够帮助企业快速构建自身的私有化容器管理平台。TKE 企业版在架构设计过程中作了针对性优化,通过采用与腾讯公有云容器服务一致的架构和管理模式,可以帮助企业在私有化管理容器服务的同时,便捷地打通云上的容器服务并获得一致的管理体验,实现混合云部署。

    另外,TKE 企业版还充分利用了腾讯内部微信、QQ、游戏等重量级业务在容器使用方面的经验,例如 GPU 虚拟化用于解决 GPU 共享问题 ;TAPP 应用管理用于让服务管理更加精细化、发布过程更加可控 ; 在离线混部技术提升资源利用率降低成本等。

    腾讯自己开发的服务,包括算法服务,都能接到 K8S 里面去,其实这个已经比较成熟了,但是有些组件,包括一些存储性的东西,分布式文件存储或者 MySQL 存储等等,业界也有相关的方案,但是从整个的稳定性来说,存储目前还是用的物理机的方式,除了服务以外的存储还是用的物理机。那怎么接入算法?最原始的方式可能是让它提供二进制包或者类似的方式来帮它做。我们最终提供的就是镜像制作的方式,最终都是通过镜像。如果用户提供了一个二进制包,怎么帮他们做镜像?这里其实有两种对接方式,第一种直接对接其镜像。这是最简单的,也有容器平台。第二种是自动构建镜像。比如说它还是物理机或者是虚拟机的方式,它提供的可能是一些包,我们帮它自动做镜像。我们把每个环境抽象成一个组件,比如说你需要 JDK、OpenSL 等等环境,我们把它抽象成一些组件,你只需要把包选出来在你的页面上,这里就是一个可视化的操作,你可以在我们的平台构成完做成你的镜像,把你的二进制包上传。

    这里有个难点,怎么缩短镜像制作的耗时?一个原始的 GCC 编译可能需要一个小时,CUDA 的安装也需要 20 分钟,做一个镜像如果环境变复杂,是不是需要一两个小时才能做一个镜像。那怎么缩短时间?思路是:第一次制作有可能确实需要花这么长时间。另外,腾讯也抽象了几点,把 GCC、CUDA 和镜像的版本做了绑定,因为是常用的,所以会做成基础镜像,每个用户制作的内容都会在后台分析,用户最耗时的以及最频繁使用的,可以在后台帮你分析,做成一个模板镜像,下次做的时候不会基于 Linux 来做,它可以基于镜像模板机来做,它的耗时明显就会减少。

    卢承山也介绍了 GPU 虚拟化的难点,并具体解释了腾讯和英伟达在 GPU 虚拟化上的不同。怎么在容器内使用 CUDA?容器可以做到 CPU 内存和 CPU 核的隔离,包括细分到 0.01。GPU 的最底层是 GPU 的设备,上面是 GPU 运行的环境。

    腾讯是做法是:

    一、最底层的两层是在物理机层面的,需要把它挂到容器上,最上层的 CUDA 是在镜像层面做的。

    二、解决在使用容器过程中 License 的问题。

    算法服务和普通服务不同的地方在于,算法厂商不希望这个服务你拿去就用,它有一些鉴权,不可能把服务给你。最早都是物理机过来的,它依赖物理机设备上的东西。怎么把这些东西挂到容器内,它依赖 MAC 地址,而容器的 MAC 地址是虚拟的。腾讯在这里面做了一部分改造,把物理机挂到容器,然后再做 License 的鉴权。

    GPU 虚拟化也涉及一些选型问题,英伟达 GPU 虚拟化存在一些问题:

    第一是物理层面,英伟达是在 CUDA 的驱动层面来做的,虽然性能很好,但由于是在虚拟机层面做的,因而不适合容器。

    第二是它不开源,而且收费。既然不开源,出现各种问题你就很难去查。

    另外,英伟达基于 MPS 做了一个软件的 GPU 虚拟化,要求必须平均分配,这会造成资源的浪费。比如,它是把一张卡虚拟成 0.01 之类的。使用一张卡其实很浪费,以一张 P40 的卡为例,很有可能你的算法根本用不到。基于这个痛点:腾讯做了一个选型,也是在 CUDA 层面上做了一层,所有的调用都是转到这个后面,再去调 CUDA 的底层,但是我们这个不会对 CUDA 底层的东西做任何改动,只是中间加了一层。


    超参数科技高级研发工程师 朱恒满

    超参数科技高级研发工程师朱恒满从 AI 与游戏的角度,讲解了游戏 AI 在实践中遇到的难点以及解决问题的思路。游戏 AI 近些年来在学术界已经有了很多的探索,在最近几年出现了比较显著的成果。2013 年 deepmind 在 Atari 的游戏上超过了人类,但是在当时并没有引起很大的轰动,在 2016 年 AlphaGo 击败了国际顶尖的围棋选手,使得 AI 有了很大的进展。最近,deepmind 和 OpenAI 分别在 rts 和 moba 游戏里面战胜了职业选手,资源不断升级,规模也是越来越大。

    游戏 AI 的实验流程:首先在本地是一些算法的设计、迭代,包括一开始去体验游戏,感受游戏需要怎样的特征,设计怎么样的流程更好;然后是模型的参数调整,做一些小范围的参数设置;接下来就是做一些大规模的实验。强化学习主要是 CPU 和 GPU 混合的异构的计算,规模会比较庞大。那么,现在 AI 真实对战的能力指标是不是已经达到我们的预期了?如果达到预期,实验就可能会停止;如果达不到,就会再回溯到之前的各个模块,看看在特征方面有没有什么需要改变;最后就是保存模型。

    那为什么要做一个平台化?

    首先是因为计算模式的复杂性。目前,强化学习在 K8S 上的编排模块比较多,包括 GPU、CPU 生产数据等方面,还有中间做了一些缓存。这么复杂的模式,如果没有做平台化,需要写很多的脚本,对于个人而言,很难掌握大规模、复杂的系统。另外,比较重要的一点是计算模式需要能够被复用。整个迭代流程更多的可能是修改参数,或者是一些模型、特征,其实整体的框架是不会动的,这就需要提供一些可复用的计算模式,进而可以提供对算法模型来说更加直接的分布式能力。

    其次是资源需要被更高效地管理和利用,这也是 K8S 赋予的能力。如果是个人或者团队分配机器,利用率是很低的,包括自己的业务可能需要去协商可以用哪些机器,这个流程非常拖沓。同时,也存在资源竞争的问题,比如两个人都想用 GPU,一台虚拟化的机器只有一张卡,怎么分配?还有就是个人很难管理这么大量的机器。

    最后,平台的通用化分析能力,可以开放给算法同学,包括算法的监控,硬件和业务的监控。另外,在日志处理方面,通过日志去判断一个 AI 是不是已经达到了能力上的需求,这里会有一些指标,包括模型方面的要求;还可以做日常定位的工作;在数据管理方面,训练数据和模型都需要做管理。


    虎牙直播高级开发工程师 王玉君

    因为虎牙直播业务方面的特性,它有很多业务是部署在边缘节点,因为涉及到主播推流等,对网络质量要求比较高,也在尝试边缘机房的建设。目前,虎牙有一些测试的机房,预计会在今年 Q4 完成生产环境的建设。这是目前的现状:虎牙现在 Node 机房有 700+ 物理机,Pod 有 7000 多,应用程序在 350+,这些数据还在不断增加。有时候有一些赛事需要紧急扩容,一天就会扩容 100 台,虎牙会根据实际的业务情况来增减。

    虎牙直播高级开发工程师王玉君分析了虎牙直播应用 K8S 的背景以及目前实践的一些思考。虎牙现在有一些 K8S 集群是搭建在公有云平台上的,目前用到了腾讯云、阿里云、AWS。对比这三家,腾讯云 TKE 可以大幅节约成本。比如说一台虚拟机上跑 10 个容器和跑 30 个容器是有本质差别的。虎牙当时也实践了不同的平台,在腾讯云 TKE 上,一台虚拟机可以跑到将近 40 个容器,它还可以提供更多的密度。

    通常情况下,K8S 如果直接提供给业务方,API 等方面用起来不是很方便,包括一些 CI/CD 的流程,如果没有把业务打通,用户是不愿意迁移上来的,因为要考虑自己的应用性成本,包括后期的部署,一些变更的成本等。虎牙一站式服务可以实现从代码编译到部署,所有的环节都帮助用户在页面上实现,用户只要在页面上点一下,就可以在很短的时间内把新版本发布。

    之前有用户不愿意上云,担心业务被其他人影响。虎牙使用了 TC 限速策略,做了一些容器的限速,有稍微的改动。如下图所示,左边底下这些三角形是容器,出向限速在左边,右边是入向限速,底下蓝色的方框是 TC 的模块。如果这个网卡是 1000M,左边这个图有两个方块,虎牙做了一些优化。因为机房用 BGP 的模式,要保证它有一个独享的带宽,不能被其它所干扰,否则对路由有影响。右边这部分就通过 filter 分给不同的容器,然后有一些不同的策略。右边这一块只是限出不限入,也是用开源的方案,通过一个网卡转发,网卡数据包进来,再出去,通过限制网卡的出速,相当于限制了容器进来的速度。

    那么,边缘节点如何接入?

    如下图所示,左下是数据中心,master 跑在数据中心里面,边缘节点分布在各个地方,它如何接入数据中心呢?图中右边这部分是通过公网直接接入集群,这种方式有很多风险,比较严重依赖虎牙自研的防火墙设备。比如说 K8S 的业务运维或者是系统运维,在扩容边缘节点的时候,它会先跟安全部门进行申请,开白名单,然后接入才能成功,跨部门的沟通是非常影响效率的。左边这一块是通过 IPsec VPN 的方式直接接入边缘节点,这种方式是比较依赖一个边缘网关、EdgeHub。另外它使用 VPN,在同样的链路下,它会有一些性能上的损耗。

    基于这一点,虎牙结合 K8S 的特性做了一些边缘节点更新的方案:

    (1)用户可以直接通过公网接入。

    (2)系统管理员不需要找安全部门开白名单。

    通过 kubectl 或者 Restful API 向 master API 发起一个授权,进而推送一个资源,安全资源有变更时,会把配置后的信息发送到一个源数据服务,源数据服务会实时更新该插件上的防火墙配置,业务的节点就会比较快速地接入集群。这样做的好处是:边缘节点分布在各个地方,edge mate 可以进行统一的管理,它会把边缘配置下发到各个节点,然后对自身进行配置,提供一种边缘集群的对外访问能力。

    另外,原地升级是对 K8S 比较好的一个补充。如果要进行升级,按照 K8S 现在的方式,会把 pod 销毁重建,这样业务是不答应的,所以原地升级可以 pod 不变,业务容器也不动,只是把 Sidecar 容器做一个更改。当集群的规模到一定的程度之后,有很多的业务要进行更新操作,更新的时候会对调度器带来一些压力,这是可以完全避免的。从这一点上看,K8S 原生设计上对规模比较大的集群还需要一定的优化。从资源锁定的角度,资源不足的时候被内部抢占,也可以通过原地升级来解决,因为 Pod 根本没有销毁,所以 pod 的立面没有改变,其它的 pod 不会调到这一台物理机上,不能达到 pod 锁定的目的。


    腾讯高级工程师 杜扬浩

    Harbor 是目前唯一的一个也是最流行的一个开源企业级镜像仓库解决方案。Harbor 除了包含最原始的镜像功能以外,还包含用户图形界面,以及它的认证、鉴权模型;同时,它还支持病毒扫描、镜像的复制。另外它也支持一个 RestfulAPI,这对企业来说是非常重要。最后 Harbor 也比较好部署,现在 Harbor 支持两种部署模式。

    腾讯高级工程师杜扬浩在演讲中主要介绍了 Harbor 的优势以及应用过程中的经验。他提到,目前 API 可以满足大部分企业的需求,但是随着企业的业务越来越复杂,应用越来越多,原有的 API 就有点不够了。杜扬浩举例说,「我查询过一个仓库所有的镜像列表,它最开始提供的 API 里面并没有企业用户所需要的一些信息,比如需要对某个用户进行过滤,或者对某个字段进行过滤,这时候它的 API 就不能满足企业用户的需求。」

    这时候就有一个问题,怎么在不改变 Harbor 的情况下来适应企业级的需求?

    有两种方案:第一种是内嵌式的修改方案。直接修改 Harbor API,让 Harbor 实现 API;另一种是非侵入式的方案。在 Harbor 的外面另外配置一个适配器,所有对 Harbor 的适配操作全部通过 Harbor Adapter 改造,无需修改 Harbor。

    这两种方案相比,使用非侵入的方案,需要几百行代码来完成这个逻辑,如果用修改 Harbor 代码的方式,可以通过几行代码实现一个非常简单的功能。但是内嵌式的方案有一个很大的缺点,它对 Harbor 是有侵入的,当 Harbor 升级、修改比较多的时候,维护成本随之会增加,有可能当 Harbor 进行了一个版本升级的时候,企业内定制的 Harbor 也需要进行升级,就需要一个完整的路径来进行升级的工作。

    对于非侵入式的 Harbor 修改方案来说,优点也很明显,唯一需要注意的是 API 的向下兼容。如果它的 API 不能实现向下兼容,就需要进行适配,它的缺点就是一个效率问题:可能一个很简单的操作,就需要很麻烦地拼凑才能实现同样的效果。还有就是对一些有状态的数据的操作,比如需要在 Harbor 原有的数据的模型下再插入一些数据,在外部就不是那么好做,还需要在里面存储一份数据,这份数据还要和 Harbor 原有的数据合并,这并不适合采用侵入式方案。综合来说,在满足性能要求的情况下,可以接受非侵入式对 HarborAPI 调用的损失。但更值得关心的是,这种升级所带来的维护成本。因为这种非侵入的方案有利于 Harbor 的升级和维护,当开源的 Harbor 升级的时候,可以用很少的工作量完成 Harbor 的迁移和升级。

    Harbor 虽然支持完善的认证和鉴权机制,但是企业内部一般都有自己定制的认证和鉴权逻辑,而这些特殊逻辑是无法通过 Harbor 现有的方式来兼容的。怎么在不修改 Harbor 的情况下进行认证和鉴权?

    首先是无侵入的认证和鉴权。它的核心就是把认证和鉴权从 Harbor 内部迁移到 Harbor 外部。现在的流程是平台调用认证中心,由企业的认证中心来完成这个认证和鉴权,当认证和鉴权通过之后,再调用 Harbor 的 API 来执行相关的操作。执行完相关的操作之后,还需要把对应的 RBAC 的资源写入到认证中心,这样就可以实现对 Harbor 的无侵入认证和鉴权修改方案。API 的认证、鉴权无侵入方案存在的一个问题就是,它不能兼容 docker 命令行,因为它不是使用我们的平台 API,它是由 dockdemo 加入,所以这里面还要对认证和鉴权的命令行做一个无侵入方案。

    在企业生产环境里如果需要部署 Harbor,要进行高并发来压测一下。杜扬浩在演讲里对比了基于普通的 CephFS、基于对象存储和文件存储这三个环境的压测对比。

    Harbor Ceph FS 压测

    Harbor Rook FS 压测

    Harbor Rook Ceph RGW 压测

    通过压测数据得出结论:随着并发量的增加,三种存储平均拉取时间都在增加,而且成功率也是越来越低。10 个并发的时候是 100%,30 个并发是 92%,600 个并发是 73%,当然这里面很大的原因是 Harbor 本身的 bug 问题。可以认为 rook 的文件系统和普通用物理机搭建的文件系统性能接近,rook 的对象存储的性能是远高于 rook 搭建的文件系统的。

    除了刚才提到的对象存储的性能本身就优于文件系统之外,为什么 Harbor 压测结果有这么高性能的提升?

    经分析可知:一方面,Harbor 切换了对象存储之后,它在与 docker 交互的过程中会采用一个重镜像的技术,这样流量就从 Harbor 切换到对象存储的服务里面来,Harbor 就不需要中转数据,节省了 Harbor 自己的一些资源以及时间。另一方面,数据由 Harbor 切到对象存储之后,流量瓶颈和并发瓶颈就由 Harbor 转到了对象存储,所以,基于上面的两个原因,就导致了 Harbor 在切换对象存储之后,它的性能有了一个质的提升。

    还有比较重要的一点是关于 ceph 文件系统的备份还原。对于 Harbor 的 ceph 文件系统来说,Harbor 的数据实际上是落地在文件系统的某一个路径上,这里备份的原理就很简单:通过 PV 获取到它的路径,然后把这个路径 mount 到本地的文件系统,通过这个文件系统进行一个压缩或者备份。文件系统的还原就是刚才备份的一个逆过程,只需要把备份的数据打入到刚才 mount 的文件系统里面就可以了。

    对于 ceph 的对象存储来说,它的备份还原的原理实际上是一样的,但是它的具体实现就有点区别:因为对于对象存储来说,它的数据不是保存在某个路径下,而是保存在对象存储的 bucket 的概念中,所以如果要对 Harbor 的对象存储进行备份还原,就需要对这个对象存储中 Harbor 所对应的 bucket 数据进行备份还原。 


    在现场提问环节,部分参会者也问到了关于腾讯云容器服务 TKE 的问题,为什么选择 TKE?开源自建 K8S 与 TKE 的对比如下:

    想了解更多?扫码回复:TKE 即可免费获取本次技术开放日完整 PPT 资源。

    点击

    展开全文
  • 李鑫 架构头条 今天作者 | 李鑫当微服务完成开发、测试后,就可以通过发布服务将其发布到线上。如果只看一个服务节点的部署,貌似是一项非常简单的工作,但如果同时发布成百上千个服务节点,尤其是需要在不影响线上...
  • 停止及启动k8s服务

    千次阅读 2021-09-10 18:00:10
    停止:kubectl drain 10.136.2.73 启动:kubectl undrain 10.136.2.73
  • K8S停止

    千次阅读 2020-12-24 09:24:12
    CMD=stop systemctl $CMD etcd echo "---------- $CMD: kube-apiserver --------" systemctl $CMD kube-apiserver echo "---------- $CMD: kube-controller-manager --------" systemctl $CMD kube-controller-...
  • 1. 程序出现死循环 2. 程序因为内存问题,已经僵死,但进程还在,但无响应; 3. 程序本身有 bug,本来应该返回 200,但因为代码问题,返回的是500; 4. Dockerfile编写写的不规范,应用程序不是主进程,那么主...
  • Linux k8s 启动 停止 查询状态 脚本

    千次阅读 2019-03-08 20:15:00
    echo "start ---- start k8s cluster" } executeCommand(){ echo "---------- $CMD etcd --------" systemctl $CMD etcd echo "---------- $CMD: docker --------" systemctl $CMD docker echo "---------- $...
  • proxy start 11.5.3 停止Node节点 service kubelet stop service kube-proxy stop service docker stop service flanneld stop 11.5.4 停止Master 节点 service kube-controller-manager stop service kube-...
  • k8s pod如何停止(不删除)

    千次阅读 2021-04-20 23:29:52
    问题描述 用户咨询 k8s上正在运行的pod 如何对它进行停止操作(不删除) 解决方案 将pod进行缩容操作 让其为0 即等同于停止操作 kubectl scale --replicas=0 deployment/<your-deployment>
  • 使用K8S集群的Selenium Grid 前提条件 确保在您的计算机上安装了kubectl和miniube。 安装完成后,运行以下命令以启动minikube minikube start 打开仪表板 minikube dashboard 停止minikube minikube stop 为了...
  • K8S】优雅停止Pod

    万次阅读 2020-01-06 14:32:13
    首先我们先简单的分析一下”优雅的停止Pod” 优雅停止(Graceful shutdown)这个说法来自于操作系统,比如我们windows关机系统首先会退出软件然后一步步到达关机,而相对的就是硬终止(Hard shutdown),简单的理解就是...
  • k8s停止容器,删除镜像

    千次阅读 2021-05-13 11:59:58
    【LAS K8S】查看srs 镜像内容 接下来,停止我开启的容器,删除镜像。 以便我重新构建。 停止镜像 ctl c 停止了镜像 停止容器 root@zhangbin-i58265u:/home/zhangbin/aliply/srs-las/srs# docker run 4c76011...
  • 1.k8s的常见资源类型 1)Namespace命名空间资源 概述:k8s实现了多租户的资源隔离,通过将集群内部的资源对象分配到不同的namespace中,形成逻辑上分组,便于区分管理,可以针对每个namespace做资源配额。 举例:...
  • k8s的dashboard服务

    2020-06-21 15:04:23
    k8s的dashboard服务 k8s的web交互页面插件 实现步骤 1:上传并导入镜像,打标签 2:创建dashborad的deployment和service vim dashboard.yaml apiVersion: extensions/v1beta1 kind: Deployment metadata: # Keep the...
  • kubectl get deploy -n default|grep -v 0|awk '{print $1}'|xargs -I ARG kubectl scale deploy ARG -n default --replicas=0
  • k8s禁用dockershim

    2021-03-08 08:42:03
    k8s禁用dockershim 一开始听说k8s要禁用docker,吓了自己一跳,然后查了一些文档,大概意思都是说没事,docker还能用,也没...管理容器,我们就假定k8s期望docker给k8s提供一些接口服务k8s 但实际情况如何,一开始k8s不开源,
  • java源码k8s_tutorial 建筑学 版本:1.17.2 master: 10.0.2.20/24 node01: 10.0.2.21/24 node02: 10.0.2.22/24 storage01: 10.0.2.30/24 设置 为 vm 设置保留所有 k8s 节点至少为 2 个 CPU。 停止 firewalld 和 ...
  • k8s常用操作命令

    万次阅读 多人点赞 2018-09-29 17:12:33
    想查看kubectl命令的方法: ...1、更改服务的type: ./kubectl edit svc test0927-1-service -n ns-2查看到type是ClusterIP的; 更改type为NodePort之后,该TYPE类型更新了: 如果要把类型从NodePort,改回Clust...
  • pod被删除或者 容器启动后,到服务真正工作起来,中间会有一段时间无法正常访问,但 k8s 却认为服务是正常就绪状态。 本篇文章主要解决这个问题,实现 平滑的发布,发布更新服务过程中保证服务一直可用,用户零...
  • K8S 滚动更新如何优雅停止 Pod

    千次阅读 2020-02-05 08:00:00
    何谓优雅停止?优雅停止(Graceful shutdown)这个说法来自于操作系统,我们执行关机之后都得 OS 先完成一些清理操作,而与之相对的就是硬中止(Hard shutdown)...
  • k8s部署-25-dubbo服务迁移到k8s系统中

    千次阅读 2022-03-31 12:18:53
    服务本身1、软件下载我发现这个不需要下载,因为本身不需要了解这些,我在这里只是为了有个清晰的认知的。你们操作的时候肯定是根据自己的实际业务中的dubbo环境进行的,当然了,感兴趣的同学可以私我哈,就不放下载...
  • k8s之Qos(服务质量)

    2021-11-04 22:05:02
    k8s之Qos(服务质量) 1. Qos简介 QoS的英文全称为"Quality of Service",中文名为"服务质量"。在kubernetes中,每个POD都有个QoS标记,通过这个Qos标记来对POD进行服务质量管理,它确定Pod的调度和驱逐优先级。它取...
  • Dubbo 在 K8s 下的思考

    2020-12-19 10:35:20
    计算机的世界变化很快,自从容器和K8s登上舞台之后,给原有的RPC领域带来了很大的挑战。这个文章主要讲述RPC领域遇到的问题,以及RPC怎么去拥抱K8s怀抱的一些思考。K8S介绍kubernetes是一个开源的,用于管理云平台中...
  • 1.1 创建k8s.sh 1.2 执行k8s.sh(很耗时) 1.3Master克隆 2master配置 2.1 初始化 2.2 安装pod网络插件 2.2.1 下载1.17.0版本的flannel的yaml文件: 2.2.2 安装flannel组件 3 Worker节点配置 3.1Master移植...
  • Kubernetes的资源控制器StatefulSet详解与示例 主机配置规划 服务器名称(hostname) 系统版本 配置 内网IP 外网IP(模拟) k8s-master CentOS7.7 2C/4G/20G 172.16.1.110 10.0.0.110 k8s-node01 CentOS7.7 2C/4G/20G ...
  • K8s系列之:Pod的升级和回滚

    千次阅读 2022-02-04 22:52:02
    K8s系列之:Pod的升级和回滚一、Deployment的升级 当集群中的某个服务需要升级时,需要停止目前与该服务相关的所有Pod,然后下载新版本镜像并创建新的Pod。集群规模比较大,需要先全部停止然后逐步升级的方式会导致...
  • k8s暂停某个节点调度

    2021-06-18 15:32:01
    kubectl cordon node_name #暂停 kubectl uncordon node_name #取消
  • 在Linux公网、云服务器搭建K8s集群

    千次阅读 热门讨论 2021-02-08 10:42:24
    echo "设置主节点主机名" > /dev/null hostnamectl set-hostname k8s-master echo "设置从节点主机名" > /dev/null hostnamectl set-hostname k8s-node1 配置系统环境 echo "停止、关闭防火墙" > /dev/null ...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 11,759
精华内容 4,703
关键字:

k8s停止服务

友情链接: Testing.zip