热门标签 | HotTags
当前位置:  开发笔记 > 编程语言 > 正文

kubernetes监控

总体设计思想总体设计架构图Kubernetesmonitoringarchitecture设计介绍监控分成两个部分核心指标流程包括的组件有kubelet、resourceestim

总体设计思想



  1. 总体设计架构图Kubernetes monitoring architecture


  2. 设计介绍

    监控分成两个部分



    • 核心指标流程 包括的组件有 kubelet、resource estimator、metrics-server、API server。这些指标被kubernetes的核心组件使用:kubectl、sheduler、HPA。指标数据流转如上图中黑色部分所示,具体过程如下:

      1. kubelet运行在所有node节点上,通过内置的cAdvisor收集节点上所有的容器资源使用信息,然后通过kubelet合并成pod级别的指标信息,之后以API的形式对外暴露出来,供其他组件调用。详细的kubeletAPI可参考kubelet-api,在kubelet安装完成后可以通过如下命令尝试调用

        root@master:/etc/kubernetes/cert# curl -s --cacert ./ca.pem --cert ./admin.pem --key ./admin-key.pem https://192.168.0.107:10250/metrics | head
        # HELP apiserver_audit_event_total [ALPHA] Counter of audit events generated and sent to the audit backend.
        # TYPE apiserver_audit_event_total counter
        apiserver_audit_event_total 0
        # HELP apiserver_audit_requests_rejected_total [ALPHA] Counter of apiserver requests rejected due to an error in audit logging backend.
        # TYPE apiserver_audit_requests_rejected_total counter
        apiserver_audit_requests_rejected_total 0
        # HELP apiserver_client_certificate_expiration_seconds [ALPHA] Distribution of the remaining lifetime on the certificate used to authenticate a request.
        # TYPE apiserver_client_certificate_expiration_seconds histogram
        apiserver_client_certificate_expiration_seconds_bucket{le="0"} 0
        apiserver_client_certificate_expiration_seconds_bucket{le="1800"} 0


        • cacert 是授信kubelet证书的证书

        • cert 和 key 是具有访问kubelete权限的并且通过cacert指定的证书签名过的证书和私钥对

        • 10250是kubelet服务的端口


      2. metrics-server 组件通过调用kubelet的接口将信息汇总起来,虽然kubelet通过cAdvisor收集了很多信息,metrics-server只会取其中的一部分给用户。如果通过k8s提供的安装脚本kube-up.sh来安装集群,默认会直接安装metrics-server,如果是自己安装集群需要自己手动安装,参考metrics-server安装。

      3. metrics-server 组件收集好需要的指标信息后不会直接面向用户提供可用的API,而是通过 Kubernetes aggregator机制,将API注册到k8s的API server中,之后用户可以像操作通用API一样 来获取这些信息。

      4. metrics-server中只会保留最近一次的指标汇集数据,不会存储获取过的信息,所以k8s早期计划再开发一个基础存储组件,把metrics-server收集到的信息传递给存储组件,供dashboard、vertical autoscaling 等组件使用



    • 通用监控流程 用来收集各种各样的指标并暴露给用户,部分指标通过adapter适配后提供给HPA(Horizontal Pod Autoscaler)使用。这些指标也可以通过一个API adapter转换后存入到基础存储组件中给其他需要历史轨迹的组件使用。一般通用监控组件会在节点上都安装一个代理,然后会有一个集群级别的收集组件。指标数据流转参考架构图中的蓝色部分,具体流程如下

      • 各个节点上运行的agent收集节点上的指标信息,这些信息可包含以下信息类型的子集或全集(取决于监控组件的设计)

        • 核心系统指标(影响对一等资源进行隔离和使用的指标,如CPU、Memory、Disk)

        • 非核心系统指标

        • 用户应用程序中暴露的服务指标

        • Kubernetes 基础组件中的服务指标(Kubernetes基础组件无论是容器启动还是服务启动,都会暴露这些指标信息,因为格式都是Prometheus format)


      • 集群级别的收集组件把这些信息收集起来

      • 通过adapter转换成满足存储组件需要的格式存储起来

      • 对于用户自定义的HPA指标,通过adapter转换成HPA识别的形式参与HPA


      • 可选的技术方案

        • cAdvisor + collectd + Heapster

        • cAdvisor + Prometheus

        • snapd + Heapster

        • snapd + SNAP cluster-level agent

        • Sysdig



      这些都是刚开始设计时的想法,现在prometheus采用的是在节点上安装一个nodereporter来收集节点信息,汇报给Prometheus





配置Kubernetes aggregator


原理简介

kubernetes 引入Aggregation Layer机制,可以让用户方便的在核心API之外对k8s集群进行扩展。安装配置好集群后aggregation会运行在kube-apiserver进程里面,用户通过在集群中创建一个APIService对象,在其中设定对应的URL(路径 /apis/{group}/{version}/...),之后访问这个路径,API server会将请求转发到具体的后端服务,一般情况下,通过extension-apiserver服务实现,这个服务会作为一个pod运行在k8s集群中。



  1. 用户访问extension-apiserver的过程如下



    • 用户访问API server,提供需要的认证凭证

    • API server通过请求后(认证和鉴权),把请求代理到extension-apiserver服务

    • Extension-apiserver从API server处获取必要的信息,并对过来的请求进行认证

    • Extension apiserver对发起请求的用户进行鉴权

    • Extension apiserver开始执行相应的方法


  2. API server通过以下配置项向extension-apiserver提供访问的证书以及用户信息



    • --proxy-client-key-file 访问extension-apiserver的证书对应的私钥

    • --proxy-client-cert-file 访问extension-apiserver的证书

    • --requestheader-username-headers 请求头中标记用户名称的key

    • -requestheader-group-headers 请求头中标记用户组的key

    • --requestheader-extra-headers-prefix 请求头中标记其他额外信息的key

    • --requestheader-client-ca-file 用来签名proxy-client-cert-file对应证书的ca,这个ca会被API server会放到一个特定的configmap中,供Extension apiserver使用

    • --requestheader-allowed-names 有效的Common Name值(CNs),如果设置了这个值,则proxy-client-cert-file中设置的CN值要在--requestheader-allowed-names设定的列表中,这个值为空,代表接受任意cn值

    当API server有以上配置项时,API server会在kube-system命名空间下生成一个configmap:extension-apiserver-authentication,里面包含--requestheader* 相关的配置信息。Extension-apiserver要想对API server的请求认证,需要先拿到这个configmap中的信息,可以通过给Extension-apiserver使用的serviceAccount赋予kube-system:extension-apiserver-authentication-reader这个角色来实现。

    目前API server没有以上配置项时也会产生这个configmap,对应的内容如下

    root@master:/opt/k8s/work# kubectl get configmaps -n kube-system extension-apiserver-authentication -o yaml
    apiVersion: v1
    data:
    client-ca-file: |
    -----BEGIN CERTIFICATE-----
    MIIDmjCCAoKgAwIBAgIUMgmbH118p4mkwRHqgFl3bltHX1MwDQYJKoZIhvcNAQEL
    BQAwZTELMAkGA1UEBhMCQ04xEDAOBgNVBAgTB05hbkppbmcxEDAOBgNVBAcTB05h
    bkppbmcxDDAKBgNVBAoTA2s4czEPMA0GA1UECxMGc3lzdGVtMRMwEQYDVQQDEwpr
    NQIDAQABo0IwQDAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNV
    HQ4EFgQUcyfeeyf0LulhElMz7x4YXC7FBXIwDQYJKoZIhvcNAQELBQADggEBAHvN
    18jceQ9BthnxFNoCZ5yjiQGQViVcaw76gEm/OrmxKGFUXJyDmZghP+gjJ8ZOADZ9
    Brw+F66ULWMBfFQrESUf3nnnaScFdrZ9TcoKDPPhzibOfEqGMf6RNFTjlWk11ZUl
    qPTPmkJlGqMGvRgPMPm2xwucE5+o762C94iLFBfmqaS/FHGsoR7hfGSEAn0q9by5
    SotQpHpAt5tzE8N7KEXFIDOr8LlbXOd/lLn1+G84NY8lWWcARFgvAuOFgKQqfenm
    ezrX/nv45OvuKBYVf7o+8CXfoTK7vc7RTtqWHA+zNbjly7IaYeaPyDxQqWSY6cBZ
    Fzh51DLVlbmTyeagMXo=
    -----END CERTIFICATE-----
    kind: ConfigMap
    metadata:
    creationTimestamp: "2020-02-09T12:04:05Z"
    name: extension-apiserver-authentication
    namespace: kube-system
    resourceVersion: "21"
    selfLink: /api/v1/namespaces/kube-system/configmaps/extension-apiserver-authentication
    uid: 6cb1a94e-78e5-49c9-8f5a-ae8183f8de96


    • 里面只包含一个ca证书

    Extension-apiserver 要对请求的user进行鉴权,需要先发送一个SubjectAccessReview请求到API server,为了能够发送这个请求还需要给xtension-apiserver使用的serviceAccount赋予system:auth-delegator这个角色



配置API server启用aggregator功能

启用aggregation功能需要在kube-apiserver配置项中追加如下信息

--requestheader-client-ca-file=


--requestheader-allowed-names=front-proxy-client
--requestheader-extra-headers-prefix=X-Remote-Extra-
--requestheader-group-headers=X-Remote-Group
--requestheader-username-headers=X-Remote-User
--proxy-client-cert-file=


--proxy-client-key-file=


如果运行API server的机器上没有运行kube-proxy进程,还需要追加如下一个配置项

--enable-aggregator-routing=true

CA 冲突问题

启用了aggregation功能后,API server会有两个配置



  • --client-ca-file

  • --requestheader-client-ca-file

如果配置不好,会造成CA冲突



  • client-ca-file:当一个请求到达API server时,用这个CA对请求携带的证书进行认证如kubectl、controller-manager、kubelet等组件请求API server。如果请求携带的证书是被这个CA签发的就被当作合法请求,之后证书中CN对应的值作为请求的用户,证书中的O对应的值作为请求的用户组。

  • requestheader-client-ca-file 正常情况下这个证书只是让扩展的API服务来对API server的身份进行认证的,不应该用到别的地方。但是如果这个值配置的话,当一个请求到达API server时,API server也会检查请求携带的证书是否是否是被这个CA签名的,如果是被这个签名的会再判断证书中的CN是否在requestheader-allowed-names指定的名称列表中,如果在里面,请求才会被允许通过,否则请求被拒绝。

当两者都配置后,API server会先检查证书是否被requestheader-client-ca-file签名,不是时才会用client-ca-file来判断。所以一般情况下这两个ca要不一致,如果两个配置的一样,可能会造成原来能正常访问API server的证书在API server启用aggregator不能再访问了,因为有可能原来正常访问的证书中的CN不在requestheader-allowed-names这个列表中,(官方文档说法,实际使用时测试了下,用同一个ca,没有报错,不知道是什么原因)



  1. 生成 client ca,要安装cfssl工具集cfssl



    1. 签名配置文件

      cd /opt/k8s/work
      cat > client-ca-config.json <{
      "signing": {
      "default": {
      "expiry": "87600h"
      },
      "profiles": {
      "kubernetes": {
      "usages": [
      "signing",
      "key encipherment",
      "server auth",
      "client auth"
      ],
      "expiry": "87600h"
      }
      }
      }
      }
      EOF


    2. 证书请求文件

      cd /opt/k8s/work
      cat > client-ca-csr.json <{
      "CN": "kubernetes",
      "key": {
      "algo": "rsa",
      "size": 2048
      },
      "names": [
      {
      "C": "CN",
      "ST": "NanJing",
      "L": "NanJing",
      "O": "k8s",
      "OU": "system"
      }
      ],
      "ca": {
      "expiry": "87600h"
      }
      }
      EOF


    3. 生成客户端根证书

      cd /opt/k8s/work
      cfssl gencert -initca client-ca-csr.json | cfssljson -bare client-ca
      ls client-ca*.pem


    4. 将证书放到k8s证书目录(多个API server节点时,其他节点也要分发)

      cd /opt/k8s/work
      cp client-ca*.pem client-ca-config.json /etc/kubernetes/cert/



  2. 生成proxy用证书



    1. 证书请求文件

      cd /opt/k8s/work
      cat > proxy-client-csr.json <{
      "CN": "front-proxy-client",
      "hosts": [],
      "key": {
      "algo": "rsa",
      "size": 2048
      },
      "names": [
      {
      "C": "CN",
      "ST": "NanJing",
      "L": "NanJing",
      "O": "k8s",
      "OU": "system"
      }
      ]
      }
      EOF


      • 证书中的CN要和API server中配置的--requestheader-allowed-names参数中


    2. 生成证书


      cfssl gencert -ca=/etc/kubernetes/cert/client-ca.pem \
      -ca-key=/etc/kubernetes/cert/client-ca-key.pem \
      -cOnfig=/etc/kubernetes/cert/client-ca-config.json \
      -profile=kubernetes proxy-client-csr.json | cfssljson -bare proxy-client
      ls proxy-client*.pem


    3. 将证书放到k8s证书目录(多个API server节点时,其他节点也要分发)

      cd /opt/k8s/work
      cp proxy-client*.pem /etc/kubernetes/cert/



  3. 配置API server追加如下配置项

    --requestheader-client-ca-file=/etc/kubernetes/cert/client-ca.pem
    --requestheader-allowed-names=front-proxy-client
    --requestheader-extra-headers-prefix=X-Remote-Extra-
    --requestheader-group-headers=X-Remote-Group
    --requestheader-username-headers=X-Remote-User
    --proxy-client-cert-file=/etc/kubernetes/cert/proxy-client.pem
    --proxy-client-key-file=/etc/kubernetes/cert/proxy-client-key.pem

    重启API server

    systemctl daemon-reload
    systemctl restart kube-apiserver

    对应的extension-apiserver-authentication中的内容

    root@master:/opt/k8s/work# kubectl get configmaps -n kube-system extension-apiserver-authentication -o yaml
    apiVersion: v1
    data:
    client-ca-file: |
    -----BEGIN CERTIFICATE-----
    MIIDmjCCAoKgAwIBAgIUMgmbH118p4mkwRHqgFl3bltHX1MwDQYJKoZIhvcNAQEL
    BQAwZTELMAkGA1UEBhMCQ04xEDAOBgNVBAgTB05hbkppbmcxEDAOBgNVBAcTB05h
    ...
    Fzh51DLVlbmTyeagMXo=
    -----END CERTIFICATE-----
    requestheader-allowed-names: '["front-proxy-client"]'
    requestheader-client-ca-file: |
    -----BEGIN CERTIFICATE-----
    MIIDmjCCAoKgAwIBAgIULBdSC4QJy1MBYwGDb0b9g7YMDH0wDQYJKoZIhvcNAQEL
    ...
    QKHtdMypc3mPUO6sBcY=
    -----END CERTIFICATE-----
    requestheader-extra-headers-prefix: '["X-Remote-Extra-"]'
    requestheader-group-headers: '["X-Remote-Group"]'
    requestheader-username-headers: '["X-Remote-User"]'
    kind: ConfigMap
    metadata:
    creationTimestamp: "2020-02-09T12:04:05Z"
    name: extension-apiserver-authentication
    namespace: kube-system
    resourceVersion: "2930987"
    selfLink: /api/v1/namespaces/kube-system/configmaps/extension-apiserver-authentication
    uid: 6cb1a94e-78e5-49c9-8f5a-ae8183f8de96


    • 追加了requestheader*相关的一些信息



metrics-server 安装

在安装metrics-server之前,虽然kubelet收集了系统信息,但是这些信息只能通过kubelet的接口进行访问,调用kubectl top nodes会报如下错误

$ kubectl top nodes
Error from server (NotFound): the server could not find the requested resource (get services http:heapster:)


  1. 下载metrics-server对应的镜像,上传到自己的私有镜像库中

    docker pull gcr.azk8s.cn/google_containers/metrics-server-amd64:v0.3.6
    docker tag gcr.azk8s.cn/google_containers/metrics-server-amd64:v0.3.6 192.168.0.107/k8s/metrics-server-amd64:v0.3.6
    docker push 192.168.0.107/k8s/metrics-server-amd64:v0.3.6


  2. 下载metrics-server启动文件

    $ cd /opt/k8s/work/
    $ wget https://github.com/kubernetes-sigs/metrics-server/archive/master.zip
    $ unzip master.zip
    $ cd metrics-server-master/deploy/kubernetes


  3. 修改 metrics-server-deployment.yaml 文件,为 metrics-server 添加两个命令行参数,并修改镜像名称,指向自己的私有仓库

    $ diff metrics-server-deployment.yaml metrics-server-deployment.yaml.bak
    32c32
    ---
    > image: k8s.gcr.io/metrics-server-amd64:v0.3.6
    36,37d35
    <- --metric-resolution=30s
    <- --kubelet-preferred-address-types=InternalIP,Hostname,InternalDNS,ExternalDNS,ExternalIP


    • kubelet-preferred-address:优先选择用IP访问kubelet,否则会用主机的hostname来访问,默认安装的coreDns不支持hostname的解析,也可通过修改coreDNS的配置文件,追加 hosts配置

      ...
      Corefile: |
      .:53 {
      errors
      health
      hosts {
      192.168.0.107 master
      192.168.0.114 slave
      fallthrough
      }
      ...



  4. 启动metrics-server

    $ cd /opt/k8s/work/metrics-server-master/deploy/kubernetes
    $ kubectl create -f .
    clusterrole.rbac.authorization.k8s.io/system:aggregated-metrics-reader created
    clusterrolebinding.rbac.authorization.k8s.io/metrics-server:system:auth-delegator created
    rolebinding.rbac.authorization.k8s.io/metrics-server-auth-reader created
    apiservice.apiregistration.k8s.io/v1beta1.metrics.k8s.io created
    serviceaccount/metrics-server created
    deployment.apps/metrics-server created
    service/metrics-server created
    clusterrole.rbac.authorization.k8s.io/system:metrics-server created
    clusterrolebinding.rbac.authorization.k8s.io/system:metrics-server created


  5. 查看运行情况

    $ kubectl -n kube-system get all -l k8s-app=metrics-server
    NAME READY STATUS RESTARTS AGE
    pod/metrics-server-857d7c4878-swpvk 1/1 Running 0 72s
    NAME READY UP-TO-DATE AVAILABLE AGE
    deployment.apps/metrics-server 1/1 1 1 72s
    NAME DESIRED CURRENT READY AGE
    replicaset.apps/metrics-server-857d7c4878 1 1 1 72s


  6. 查看 metrics-server 输出的 metrics

    $ kubectl get --raw https://192.168.0.107:6443/apis/metrics.k8s.io/v1beta1/nodes | jq .
    {
    "kind": "NodeMetricsList",
    "apiVersion": "metrics.k8s.io/v1beta1",
    "metadata": {
    "selfLink": "/apis/metrics.k8s.io/v1beta1/nodes"
    },
    "items": [
    {
    "metadata": {
    "name": "master",
    "selfLink": "/apis/metrics.k8s.io/v1beta1/nodes/master",
    "creationTimestamp": "2020-02-27T09:30:12Z"
    },
    "timestamp": "2020-02-27T09:29:35Z",
    "window": "30s",
    "usage": {
    "cpu": "414650216n",
    "memory": "6069004Ki"
    }
    },
    {
    "metadata": {
    "name": "slave",
    "selfLink": "/apis/metrics.k8s.io/v1beta1/nodes/slave",
    "creationTimestamp": "2020-02-27T09:30:12Z"
    },
    "timestamp": "2020-02-27T09:29:35Z",
    "window": "30s",
    "usage": {
    "cpu": "80942639n",
    "memory": "2393408Ki"
    }
    }
    ]
    }
    $ kubectl top nodes
    NAME CPU(cores) CPU% MEMORY(bytes) MEMORY%
    master 427m 10% 5928Mi 76%
    slave 92m 2% 2335Mi 62%



遇到问题

启动完后,服务都正常,获取不到指标信息

$ kubectl top nodes
Error from server (ServiceUnavailable): the server is currently unable to handle the request (get nodes.metrics.k8s.io)

kube-apiserver 服务中一直出现下面的错

E0227 16:52:50.472445 19192 available_controller.go:419] v1beta1.metrics.k8s.io failed with: failing or missing response from https://10.0.0.96:443/apis/metrics.k8s.io/v1beta1: bad status from https://10.0.0.96:443/apis/metrics.k8s.io/v1beta1: 403

按照这个错,应该是kube-apiserver访问metrics-server时权限不足,可我们明明提供了proxy*相关的参数,最后再一次检查kube-apiserver的启动文件,发现--proxy-client-cert-file参数后面少了个分行符



  • 错误

    --proxy-client-cert-file=/etc/kubernetes/cert/proxy-client.pem
    --proxy-client-key-file=/etc/kubernetes/cert/proxy-client-key.pem \


  • 正确

    --proxy-client-cert-file=/etc/kubernetes/cert/proxy-client.pem \
    --proxy-client-key-file=/etc/kubernetes/cert/proxy-client-key.pem \




推荐阅读
  • 【实例简介】本文详细介绍了如何在PHP中实现微信支付的退款功能,并提供了订单创建类的完整代码及调用示例。在配置过程中,需确保正确设置相关参数,特别是证书路径应根据项目实际情况进行调整。为了保证系统的安全性,存放证书的目录需要设置为可读权限。值得注意的是,普通支付操作无需证书,但在执行退款操作时必须提供证书。此外,本文还对常见的错误处理和调试技巧进行了说明,帮助开发者快速定位和解决问题。 ... [详细]
  • Java Socket 关键参数详解与优化建议
    Java Socket 的 API 虽然被广泛使用,但其关键参数的用途却鲜为人知。本文详细解析了 Java Socket 中的重要参数,如 backlog 参数,它用于控制服务器等待连接请求的队列长度。此外,还探讨了其他参数如 SO_TIMEOUT、SO_REUSEADDR 等的配置方法及其对性能的影响,并提供了优化建议,帮助开发者提升网络通信的稳定性和效率。 ... [详细]
  • 在Cisco IOS XR系统中,存在提供服务的服务器和使用这些服务的客户端。本文深入探讨了进程与线程状态转换机制,分析了其在系统性能优化中的关键作用,并提出了改进措施,以提高系统的响应速度和资源利用率。通过详细研究状态转换的各个环节,本文为开发人员和系统管理员提供了实用的指导,旨在提升整体系统效率和稳定性。 ... [详细]
  • 在启用分层编译的情况下,即时编译器(JIT)的触发条件涉及多个因素,包括方法调用频率、代码复杂度和运行时性能数据。本文将详细解析这些条件,并探讨分层编译如何优化JVM的执行效率。 ... [详细]
  • Envoy 流量分配策略优化
    在本研究中,我们对Envoy的流量分配策略进行了优化,旨在提高系统的稳定性和性能。实验环境包括一个前端代理服务(Envoy,IP地址为172.31.57.10)和五个后端服务。通过调整Envoy的配置,实现了更高效的流量分发和负载均衡,显著提升了整体系统的响应速度和可靠性。 ... [详细]
  • 本文将介绍如何在混合开发(Hybrid)应用中实现Native与HTML5的交互,包括基本概念、学习目标以及具体的实现步骤。 ... [详细]
  • 多线程基础概览
    本文探讨了多线程的起源及其在现代编程中的重要性。线程的引入是为了增强进程的稳定性,确保一个进程的崩溃不会影响其他进程。而进程的存在则是为了保障操作系统的稳定运行,防止单一应用程序的错误导致整个系统的崩溃。线程作为进程的逻辑单元,多个线程共享同一CPU,需要合理调度以避免资源竞争。 ... [详细]
  • 本文总结了一些开发中常见的问题及其解决方案,包括特性过滤器的使用、NuGet程序集版本冲突、线程存储、溢出检查、ThreadPool的最大线程数设置、Redis使用中的问题以及Task.Result和Task.GetAwaiter().GetResult()的区别。 ... [详细]
  • 在Java Web服务开发中,Apache CXF 和 Axis2 是两个广泛使用的框架。CXF 由于其与 Spring 框架的无缝集成能力,以及更简便的部署方式,成为了许多开发者的首选。本文将详细介绍如何使用 CXF 框架进行 Web 服务的开发,包括环境搭建、服务发布和客户端调用等关键步骤,为开发者提供一个全面的实践指南。 ... [详细]
  • 在开发过程中,我最初也依赖于功能全面但操作繁琐的集成开发环境(IDE),如Borland Delphi 和 Microsoft Visual Studio。然而,随着对高效开发的追求,我逐渐转向了更加轻量级和灵活的工具组合。通过 CLIfe,我构建了一个高度定制化的开发环境,不仅提高了代码编写效率,还简化了项目管理流程。这一配置结合了多种强大的命令行工具和插件,使我在日常开发中能够更加得心应手。 ... [详细]
  • 基于Node.js的高性能实时消息推送系统通过集成Socket.IO和Express框架,实现了高效的高并发消息转发功能。该系统能够支持大量用户同时在线,并确保消息的实时性和可靠性,适用于需要即时通信的应用场景。 ... [详细]
  • 在前一篇文章中,我们介绍了如何使用Requests库发送GET请求。本文将深入探讨如何通过Requests库发送POST请求,包括参数格式、请求封装等关键技巧,并通过“历史上的今天”API实例进行详细说明。 ... [详细]
  • 前言: 网上搭建k8s的文章很多,但很多都无法按其说明在阿里云ecs服务器成功搭建,所以我就花了些时间基于自己成功搭建k8s的步骤写了个操作手册,希望对想搭建k8s环境的盆友有所帮 ... [详细]
  • kubernetes 下实现socket.io 的集群模式
    2019独角兽企业重金招聘Python工程师标准socket.io单节点模式是很容易部署的,但是往往在生产环境一个节点不能满足业务需求,况且还要保 ... [详细]
  • prometheus09-k8s部署grafana
    1.部署grafana?apiVersion:?appsv1?kind:?StatefulSet?metadata:??name:?grafana??namespace:?kube-systemspec:??serviceName:?grafana??repl ... [详细]
author-avatar
谭禅心_136
这个家伙很懒,什么也没留下!
PHP1.CN | 中国最专业的PHP中文社区 | DevBox开发工具箱 | json解析格式化 |PHP资讯 | PHP教程 | 数据库技术 | 服务器技术 | 前端开发技术 | PHP框架 | 开发工具 | 在线工具
Copyright © 1998 - 2020 PHP1.CN. All Rights Reserved | 京公网安备 11010802041100号 | 京ICP备19059560号-4 | PHP1.CN 第一PHP社区 版权所有