k8s介绍

本文涉及的产品
传统型负载均衡 CLB,每月750个小时 15LCU
网络型负载均衡 NLB,每月750个小时 15LCU
应用型负载均衡 ALB,每月750个小时 15LCU
简介: •Kubernetes介绍 1.背景介绍   云计算飞速发展     - IaaS     - PaaS     - SaaS   Docker技术突飞猛进     - 一次构建,到处运行     - 容器的快速轻量     - 完整的生态环境 2.什么是kubernetes   首先,他是一个全新的基于容器技术的分布式架构领先方案。

•Kubernetes介绍

1.背景介绍

  云计算飞速发展

    - IaaS

    - PaaS

    - SaaS

  Docker技术突飞猛进

    - 一次构建,到处运行

    - 容器的快速轻量

    - 完整的生态环境

2.什么是kubernetes

  首先,他是一个全新的基于容器技术的分布式架构领先方案。Kubernetes(k8s)是Google开源的 容器集群管理系统(谷歌内部:Borg)。在Docker技术的基础上,为容器化的应用提供部署运行、资源调度、服务发现和动态伸缩等一系列完整功能,提高了大规模容器集群管理的便捷性。

  Kubernetes是一个完备的分布式系统支撑平台,具有完备的集群管理能力,多扩多层次的安全防护和准入机制、多租户应用支撑能力、透明的服务注册和发现机制、內建智能负载均衡器、强大的故障发现和自我修复能力、服务滚动升级和在线扩容能力、可扩展的资源自动调度机制以及多粒度的资源配额管理能力。同时Kubernetes提供完善的管理工具,涵盖了包括开发、部署测试、运维监控在内的各个环节。

Kubernetes中,Service是分布式集群架构的核心,一个Service对象拥有如下关键特征:

  • 拥有一个唯一指定的名字
  • 拥有一个虚拟IP(Cluster IP、Service IP、或VIP)和端口号
  • 能够体统某种远程服务能力
  • 被映射到了提供这种服务能力的一组容器应用上

  Service的服务进程目前都是基于Socket通信方式对外提供服务,比如Redis、Memcache、MySQL、Web Server,或者是实现了某个具体业务的一个特定的TCP Server进程,虽然一个Service通常由多个相关的服务进程来提供服务,每个服务进程都有一个独立的Endpoint(IP+Port)访问点,但Kubernetes能够让我们通过服务连接到指定的Service上。有了Kubernetes内奸的透明负载均衡和故障恢复机制,不管后端有多少服务进程,也不管某个服务进程是否会由于发生故障而重新部署到其他机器,都不会影响我们队服务的正常调用,更重要的是这个Service本身一旦创建就不会发生变化,意味着在Kubernetes集群中,我们不用为了服务的IP地址的变化问题而头疼了。

  容器提供了强大的隔离功能,所有有必要把为Service提供服务的这组进程放入容器中进行隔离。为此,Kubernetes设计了Pod对象,将每个服务进程包装到相对应的Pod中,使其成为Pod中运行的一个容器。为了建立Service与Pod间的关联管理,Kubernetes给每个Pod贴上一个标签Label,比如运行MySQL的Pod贴上name=mysql标签,给运行PHP的Pod贴上name=php标签,然后给相应的Service定义标签选择器Label Selector,这样就能巧妙的解决了Service于Pod的关联问题。

  在集群管理方面,Kubernetes将集群中的机器划分为一个Master节点和一群工作节点Node,其中,在Master节点运行着集群管理相关的一组进程kube-apiserver、kube-controller-manager和kube-scheduler,这些进程实现了整个集群的资源管理、Pod调度、弹性伸缩、安全控制、系统监控和纠错等管理能力,并且都是全自动完成的。Node作为集群中的工作节点,运行真正的应用程序,在Node上Kubernetes管理的最小运行单元是Pod。Node上运行着Kubernetes的kubelet、kube-proxy服务进程,这些服务进程负责Pod的创建、启动、监控、重启、销毁以及实现软件模式的负载均衡器。

  在Kubernetes集群中,它解决了传统IT系统中服务扩容和升级的两大难题。你只需为需要扩容的Service关联的Pod创建一个Replication Controller简称(RC),则该Service的扩容及后续的升级等问题将迎刃而解。在一个RC定义文件中包括以下3个关键信息。

  • 目标Pod的定义
  • 目标Pod需要运行的副本数量(Replicas)
  • 要监控的目标Pod标签(Label)

  在创建好RC后,Kubernetes会通过RC中定义的的Label筛选出对应Pod实例并实时监控其状态和数量,如果实例数量少于定义的副本数量,则会根据RC中定义的Pod模板来创建一个新的Pod,然后将新Pod调度到合适的Node上启动运行,知道Pod实例的数量达到预定目标,这个过程完全是自动化。

 Kubernetes优势:

    - 容器编排

    - 轻量级

    - 开源

    - 弹性伸缩

    - 负载均衡

•Kubernetes的核心概念

1.Master

  k8s集群的管理节点,负责管理集群,提供集群的资源数据访问入口。拥有Etcd存储服务(可选),运行Api Server进程,Controller Manager服务进程及Scheduler服务进程,关联工作节点Node。Kubernetes API server提供HTTP Rest接口的关键服务进程,是Kubernetes里所有资源的增、删、改、查等操作的唯一入口。也是集群控制的入口进程;Kubernetes Controller Manager是Kubernetes所有资源对象的自动化控制中心;Kubernetes Schedule是负责资源调度(Pod调度)的进程

2.Node

  Node是Kubernetes集群架构中运行Pod的服务节点(亦叫agent或minion)。Node是Kubernetes集群操作的单元,用来承载被分配Pod的运行,是Pod运行的宿主机。关联Master管理节点,拥有名称和IP、系统资源信息。运行docker eninge服务,守护进程kunelet及负载均衡器kube-proxy.

  • 每个Node节点都运行着以下一组关键进程
  • kubelet:负责对Pod对于的容器的创建、启停等任务
  • kube-proxy:实现Kubernetes Service的通信与负载均衡机制的重要组件
  • Docker Engine(Docker):Docker引擎,负责本机容器的创建和管理工作

  Node节点可以在运行期间动态增加到Kubernetes集群中,默认情况下,kubelet会想master注册自己,这也是Kubernetes推荐的Node管理方式,kubelet进程会定时向Master汇报自身情报,如操作系统、Docker版本、CPU和内存,以及有哪些Pod在运行等等,这样Master可以获知每个Node节点的资源使用情况,冰实现高效均衡的资源调度策略。、

3.Pod

  运行于Node节点上,若干相关容器的组合。Pod内包含的容器运行在同一宿主机上,使用相同的网络命名空间、IP地址和端口,能够通过localhost进行通。Pod是Kurbernetes进行创建、调度和管理的最小单位,它提供了比容器更高层次的抽象,使得部署和管理更加灵活。一个Pod可以包含一个容器或者多个相关容器。

  Pod其实有两种类型:普通Pod和静态Pod,后者比较特殊,它并不存在Kubernetes的etcd存储中,而是存放在某个具体的Node上的一个具体文件中,并且只在此Node上启动。普通Pod一旦被创建,就会被放入etcd存储中,随后会被Kubernetes Master调度到摸个具体的Node上进行绑定,随后该Pod被对应的Node上的kubelet进程实例化成一组相关的Docker容器冰启动起来,在。在默认情况下,当Pod里的某个容器停止时,Kubernetes会自动检测到这个问起并且重启这个Pod(重启Pod里的所有容器),如果Pod所在的Node宕机,则会将这个Node上的所有Pod重新调度到其他节点上。

4.Replication Controller

  Replication Controller用来管理Pod的副本,保证集群中存在指定数量的Pod副本。集群中副本的数量大于指定数量,则会停止指定数量之外的多余容器数量,反之,则会启动少于指定数量个数的容器,保证数量不变。Replication Controller是实现弹性伸缩、动态扩容和滚动升级的核心。

5.Service

  Service定义了Pod的逻辑集合和访问该集合的策略,是真实服务的抽象。Service提供了一个统一的服务访问入口以及服务代理和发现机制,关联多个相同Label的Pod,用户不需要了解后台Pod是如何运行。

外部系统访问Service的问题

  首先需要弄明白Kubernetes的三种IP这个问题

    Node IP:Node节点的IP地址

    Pod IP: Pod的IP地址

    Cluster IP:Service的IP地址

  首先,Node IP是Kubernetes集群中节点的物理网卡IP地址,所有属于这个网络的服务器之间都能通过这个网络直接通信。这也表明Kubernetes集群之外的节点访问Kubernetes集群之内的某个节点或者TCP/IP服务的时候,必须通过Node IP进行通信

  其次,Pod IP是每个Pod的IP地址,他是Docker Engine根据docker0网桥的IP地址段进行分配的,通常是一个虚拟的二层网络。

  最后Cluster IP是一个虚拟的IP,但更像是一个伪造的IP网络,原因有以下几点

  • Cluster IP仅仅作用于Kubernetes Service这个对象,并由Kubernetes管理和分配P地址
  • Cluster IP无法被ping,他没有一个“实体网络对象”来响应
  • Cluster IP只能结合Service Port组成一个具体的通信端口,单独的Cluster IP不具备通信的基础,并且他们属于Kubernetes集群这样一个封闭的空间。

Kubernetes集群之内,Node IP网、Pod IP网于Cluster IP网之间的通信,采用的是Kubernetes自己设计的一种编程方式的特殊路由规则。

6.Label

 Kubernetes中的任意API对象都是通过Label进行标识,Label的实质是一系列的Key/Value键值对,其中key于value由用户自己指定。Label可以附加在各种资源对象上,如Node、Pod、Service、RC等,一个资源对象可以定义任意数量的Label,同一个Label也可以被添加到任意数量的资源对象上去。Label是Replication Controller和Service运行的基础,二者通过Label来进行关联Node上运行的Pod。

我们可以通过给指定的资源对象捆绑一个或者多个不同的Label来实现多维度的资源分组管理功能,以便于灵活、方便的进行资源分配、调度、配置等管理工作。

一些常用的Label如下:

  • 版本标签:"release":"stable","release":"canary"......
  • 环境标签:"environment":"dev","environment":"qa","environment":"production"
  • 架构标签:"tier":"frontend","tier":"backend","tier":"middleware"
  • 分区标签:"partition":"customerA","partition":"customerB"
  • 质量管控标签:"track":"daily","track":"weekly"

  Label相当于我们熟悉的标签,给某个资源对象定义一个Label就相当于给它大了一个标签,随后可以通过Label Selector(标签选择器)查询和筛选拥有某些Label的资源对象,Kubernetes通过这种方式实现了类似SQL的简单又通用的对象查询机制。

  Label Selector在Kubernetes中重要使用场景如下:

    •   kube-Controller进程通过资源对象RC上定义Label Selector来筛选要监控的Pod副本的数量,从而实现副本数量始终符合预期设定的全自动控制流程
    •   kube-proxy进程通过Service的Label Selector来选择对应的Pod,自动建立起每个Service岛对应Pod的请求转发路由表,从而实现Service的智能负载均衡
    •   通过对某些Node定义特定的Label,并且在Pod定义文件中使用Nodeselector这种标签调度策略,kuber-scheduler进程可以实现Pod”定向调度“的特性

•Kubernetes架构和组件

  - 服务分组,小集群,多集群

  - 服务分组,大集群,单集群

•Kubernetes 组件:

  Kubernetes Master控制组件,调度管理整个系统(集群),包含如下组件:

  1.Kubernetes API Server

    作为Kubernetes系统的入口,其封装了核心对象的增删改查操作,以RESTful API接口方式提供给外部客户和内部组件调用。维护的REST对象持久化到Etcd中存储。

  2.Kubernetes Scheduler

    为新建立的Pod进行节点(node)选择(即分配机器),负责集群的资源调度。组件抽离,可以方便替换成其他调度器。

  3.Kubernetes Controller

    负责执行各种控制器,目前已经提供了很多控制器来保证Kubernetes的正常运行。

  4. Replication Controller

    管理维护Replication Controller,关联Replication Controller和Pod,保证Replication Controller定义的副本数量与实际运行Pod数量一致。

  5. Node Controller

    管理维护Node,定期检查Node的健康状态,标识出(失效|未失效)的Node节点。

  6. Namespace Controller

    管理维护Namespace,定期清理无效的Namespace,包括Namesapce下的API对象,比如Pod、Service等。

  7. Service Controller

    管理维护Service,提供负载以及服务代理。

  8.EndPoints Controller

    管理维护Endpoints,关联Service和Pod,创建Endpoints为Service的后端,当Pod发生变化时,实时更新Endpoints。

  9. Service Account Controller

    管理维护Service Account,为每个Namespace创建默认的Service Account,同时为Service Account创建Service Account Secret。

  10. Persistent Volume Controller

    管理维护Persistent Volume和Persistent Volume Claim,为新的Persistent Volume Claim分配Persistent Volume进行绑定,为释放的Persistent Volume执行清理回收。

  11. Daemon Set Controller

    管理维护Daemon Set,负责创建Daemon Pod,保证指定的Node上正常的运行Daemon Pod。

  12. Deployment Controller

    管理维护Deployment,关联Deployment和Replication Controller,保证运行指定数量的Pod。当Deployment更新时,控制实现Replication Controller和 Pod的更新。

  13.Job Controller

    管理维护Job,为Jod创建一次性任务Pod,保证完成Job指定完成的任务数目

  14. Pod Autoscaler Controller

    实现Pod的自动伸缩,定时获取监控数据,进行策略匹配,当满足条件时执行Pod的伸缩动作。

•Kubernetes Node运行节点,运行管理业务容器,包含如下组件:

  1.Kubelet

    负责管控容器,Kubelet会从Kubernetes API Server接收Pod的创建请求,启动和停止容器,监控容器运行状态并汇报给Kubernetes API Server。

  2.Kubernetes Proxy

    负责为Pod创建代理服务,Kubernetes Proxy会从Kubernetes API Server获取所有的Service信息,并根据Service的信息创建代理服务,实现Service到Pod的请求路由和转发,从而实现Kubernetes层级的虚拟转发网络。

  3.Docker

    Node上需要运行容器服务

二、基于kubernetes构建Docker集群环境实战

kubernetes是google公司基于docker所做的一个分布式集群,有以下主件组成

  etcd: 高可用存储共享配置和服务发现,作为与minion机器上的flannel配套使用,作用是使每台 minion上运行的docker拥有不同的ip段,最终目的是使不同minion上正在运行的docker containner都有一个与别的任意一个containner(别的minion上运行的docker containner)不一样的IP地址。

  flannel: 网络结构支持

  kube-apiserver: 不论通过kubectl还是使用remote api 直接控制,都要经过apiserver

  kube-controller-manager: 对replication controller, endpoints controller, namespace controller, and serviceaccounts controller的循环控制,与kube-apiserver交互,保证这些controller工作

  kube-scheduler: Kubernetes scheduler的作用就是根据特定的调度算法将pod调度到指定的工作节点(minion)上,这一过程也叫绑定(bind)

  kubelet: Kubelet运行在Kubernetes Minion Node上. 它是container agent的逻辑继任者

  kube-proxy: kube-proxy是kubernetes 里运行在minion节点上的一个组件, 它起的作用是一个服务代理的角色

图为GIT+Jenkins+Kubernetes+Docker+Etcd+confd+Nginx+Glusterfs架构:

如下:

环境:

centos7系统机器三台:

10.0.0.81: 用来安装kubernetes master

10.0.0.82: 用作kubernetes minion (minion1)

10.0.0.83: 用作kubbernetes minion (minion2)

一、关闭系统运行的防火墙及selinux

1。如果系统开启了防火墙则按如下步骤关闭防火墙(所有机器)

# systemctl stop firewalld # systemctl disable firewalld

2.关闭selinux



  
  
  1. #setenforce 0

  2. #sed -i '/^SELINUX=/cSELINUX=disabled' /etc/sysconfig/selinux

二、MASTER安装配置

1. 安装并配置Kubernetes master(yum 方式)

# yum -y install etcd kubernetes

配置etcd。确保列出的这些项都配置正确并且没有被注释掉,下面的配置都是如此



  
  
  1. #vim /etc/etcd/etcd.conf

  2. ETCD_NAME=default

  3. ETCD_DATA_DIR="/var/lib/etcd/default.etcd"

  4. ETCD_LISTEN_CLIENT_URLS="http://0.0.0.0:2379"

  5. ETCD_ADVERTISE_CLIENT_URLS="http://localhost:2379"

 配置kubernetes



  
  
  1. vim /etc/kubernetes/apiserver

  2. KUBE_API_ADDRESS="--address=0.0.0.0"KUBE_API_PORT="--port=8080"

  3. KUBELET_PORT="--kubelet_port=10250"

  4. KUBE_ETCD_SERVERS="--etcd_servers=http://127.0.0.1:2379"

  5. KUBE_SERVICE_ADDRESSES="--service-cluster-ip-range=10.254.0.0/16"

  6. KUBE_ADMISSION_CONTROL="--admission_control=NamespaceLifecycle,NamespaceExists,LimitRanger,SecurityContextDeny,ResourceQuota"

  7. KUBE_API_ARGS=""

2. 启动etcd, kube-apiserver, kube-controller-manager and kube-scheduler服务

# for SERVICES in etcd kube-apiserver kube-controller-manager kube-scheduler; do systemctl restart $SERVICES systemctl enable $SERVICES systemctl status $SERVICES done

3.设置etcd网络

#etcdctl -C 10.0.0.81:2379 set /atomic.io/network/config '{"Network":"10.1.0.0/16"}'

4. 至此master配置完成,运行kubectl get nodes可以查看有多少minion在运行,以及其状态。这里我们的minion还都没有开始安装配置,所以运行之后结果为空

# kubectl get nodes NAME LABELS STATUS

三、MINION安装配置(每台minion机器都按如下安装配置)

1. 环境安装和配置

# yum -y install flannel kubernetes

  配置kubernetes连接的服务端IP



  
  
  1. #vim /etc/kubernetes/config

  2. KUBE_MASTER="--master=http://10.0.0.81:8080"

  3. KUBE_ETCD_SERVERS="--etcd_servers=http://10.0.0.81:2379"

  配置kubernetes ,(请使用每台minion自己的IP地址比如10.0.0.81:代替下面的$LOCALIP)



  
  
  1. #vim /etc/kubernetes/kubelet<br>KUBELET_ADDRESS="--address=0.0.0.0"

  2. KUBELET_PORT="--port=10250"

  3. # change the hostname to this host’s IP address KUBELET_HOSTNAME="--hostname_override=$LOCALIP"

  4. KUBELET_API_SERVER="--api_servers=http://10.0.0.81:8080"

  5. KUBELET_ARGS=""

2. 准备启动服务(如果本来机器上已经运行过docker的请看过来,没有运行过的请忽略此步骤)

运行ifconfig,查看机器的网络配置情况(有docker0)



  
  
  1. # ifconfig docker0

  2. Link encap:Ethernet HWaddr 02:42:B2:75:2E:67 inet addr:172.17.0.1 Bcast:0.0.0.0 Mask:255.255.0.0 UP

  3. BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0

  4. errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0

  5. RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

  warning:在运行过docker的机器上可以看到有docker0,这里在启动服务之前需要删掉docker0配置,在命令行运行:sudo ip link delete docker0

3.配置flannel网络



  
  
  1. #vim /etc/sysconfig/flanneld

  2. FLANNEL_ETCD_ENDPOINTS="http://10.0.0.81:2379"

  3. FLANNEL_ETCD_PREFIX="/atomic.io/network"

PS:其中atomic.io与上面etcd中的Network对应

4. 启动服务

# for SERVICES in flanneld kube-proxy kubelet docker; do systemctl restart $SERVICES systemctl enable $SERVICES systemctl status $SERVICES done

四、配置完成验证安装

确定两台minion(10.0.0.82和10.0.0.83)和一台master(10.0.0.81)都已经成功的安装配置并且服务都已经启动了。

切换到master机器上,运行命令kubectl get nodes



  
  
  1. # kubectl get nodes

  2. NAME STATUS AGE

  3. 10.0.0.82 Ready 1m

  4. 10.0.0.83 Ready 1m

可以看到配置的两台minion已经在master的node列表中了。如果想要更多的node,只需要按照minion的配置,配置更多的机器就可以了。

三、Kubernetes之深入了解Pod

1、yaml格式的Pod配置文件内容及注解

  深入Pod之前,首先我们来了解下Pod的yaml整体文件内容及功能注解。

如下:



  
  
  1. # yaml格式的pod定义文件完整内容:

  2. apiVersion: v1 #必选,版本号,例如v1

  3. kind: Pod #必选,Pod

  4. metadata: #必选,元数据

  5. name: string #必选,Pod名称

  6. namespace: string #必选,Pod所属的命名空间

  7. labels: #自定义标签

  8. - name: string #自定义标签名字

  9. annotations: #自定义注释列表

  10. - name: string

  11. spec: #必选,Pod中容器的详细定义

  12. containers: #必选,Pod中容器列表

  13. - name: string #必选,容器名称

  14. image: string #必选,容器的镜像名称

  15. imagePullPolicy: [Always | Never | IfNotPresent] #获取镜像的策略 Alawys表示下载镜像 IfnotPresent表示优先使用本地镜像,否则下载镜像,Nerver表示仅使用本地镜像

  16. command: [string] #容器的启动命令列表,如不指定,使用打包时使用的启动命令

  17. args: [string] #容器的启动命令参数列表

  18. workingDir: string #容器的工作目录

  19. volumeMounts: #挂载到容器内部的存储卷配置

  20. - name: string #引用pod定义的共享存储卷的名称,需用volumes[]部分定义的的卷名

  21. mountPath: string #存储卷在容器内mount的绝对路径,应少于512字符

  22. readOnly: boolean #是否为只读模式

  23. ports: #需要暴露的端口库号列表

  24. - name: string #端口号名称

  25. containerPort: int #容器需要监听的端口号

  26. hostPort: int #容器所在主机需要监听的端口号,默认与Container相同

  27. protocol: string #端口协议,支持TCP和UDP,默认TCP

  28. env: #容器运行前需设置的环境变量列表

  29. - name: string #环境变量名称

  30. value: string #环境变量的值

  31. resources: #资源限制和请求的设置

  32. limits: #资源限制的设置

  33. cpu: string #Cpu的限制,单位为core数,将用于docker run --cpu-shares参数

  34. memory: string #内存限制,单位可以为Mib/Gib,将用于docker run --memory参数

  35. requests: #资源请求的设置

  36. cpu: string #Cpu请求,容器启动的初始可用数量

  37. memory: string #内存清楚,容器启动的初始可用数量

  38. livenessProbe: #对Pod内个容器健康检查的设置,当探测无响应几次后将自动重启该容器,检查方法有exec、httpGet和tcpSocket,对一个容器只需设置其中一种方法即可

  39. exec: #对Pod容器内检查方式设置为exec方式

  40. command:

本文转自CSDN-k8s基本概念

相关实践学习
通过Ingress进行灰度发布
本场景您将运行一个简单的应用,部署一个新的应用用于新的发布,并通过Ingress能力实现灰度发布。
容器应用与集群管理
欢迎来到《容器应用与集群管理》课程,本课程是“云原生容器Clouder认证“系列中的第二阶段。课程将向您介绍与容器集群相关的概念和技术,这些概念和技术可以帮助您了解阿里云容器服务ACK/ACK Serverless的使用。同时,本课程也会向您介绍可以采取的工具、方法和可操作步骤,以帮助您了解如何基于容器服务ACK Serverless构建和管理企业级应用。 学习完本课程后,您将能够: 掌握容器集群、容器编排的基本概念 掌握Kubernetes的基础概念及核心思想 掌握阿里云容器服务ACK/ACK Serverless概念及使用方法 基于容器服务ACK Serverless搭建和管理企业级网站应用
相关文章
|
微服务 数据库 持续交付
带你读《微服务架构设计模式》之一:逃离单体地狱
本书中,微服务架构的先驱、Java 开发者社区的意见领袖 Chris Richardson 收集、分类并解释了 44 个架构设计模式,这些模式用来解决诸如服务拆分、事务管理、查询和跨服务通信等难题。本书不仅仅是一个模式目录,还提供了经验驱动的建议,以帮助你设计、实现、测试和部署基于微服务的应用程序。
10352 1
|
4月前
|
监控 安全 网络协议
|
6月前
|
消息中间件 存储 Kafka
浅谈现代消息队列与云存储
讲述消息系统在现代化演进中软硬一体化,百万队列,分级存储等诸多竞争力特性的诞生和落地效果。探讨业界领先的 Shared-Log 存储计算分离,FFM与协程,RDMA 传输,列式存储等技术,将消息向流的领域延伸。
|
6月前
|
存储 运维 监控
使用Terraform玩转SLS告警
本文主要介绍使用Terraform来操作SLS告警监控,告警管理。
110 0
使用Terraform玩转SLS告警
|
Kubernetes 前端开发 API
Kubernetes 认证机制学习
# 引言 Kubernetes API Server 组件是 Kubernetes 具有网关性质的组件,它是 Kubernetes 集群资源操作的唯一入口,它通过 HTTP RESTful 的形式暴露服务,允许不同的用户、外部组件等访问它。我们使用 curl 命令去模拟访问 apisever 请求过程中,发生了什么。 ```bash iZj6ccqyhc7xduup9vl8mvZ :: ~ »
|
Cloud Native 混合部署
《云原生混部系统 Koordinator 架构详解》电子版地址
云原生混部系统 Koordinator 架构详解
316 0
《云原生混部系统 Koordinator 架构详解》电子版地址
|
分布式计算 运维 DataWorks
DataWorks 数据服务介绍及实践 | 学习笔记
快速学习 DataWorks 数据服务介绍及实践,介绍了 DataWorks 数据服务介绍及实践系统机制, 以及在实际应用过程中如何使用。
DataWorks 数据服务介绍及实践 | 学习笔记
|
机器学习/深度学习 Kubernetes Cloud Native
【云原生】学习K8s的扩展技能(CRD)
【云原生】学习K8s的扩展技能(CRD)
479 0
【云原生】学习K8s的扩展技能(CRD)
|
分布式计算 Kubernetes Cloud Native
直播回顾 | 云原生混部系统 Koordinator 架构详解(附完整PPT)
近期,来自 Koordinator 社区的两位技术专家从项目的架构和特性出发,分享了 Koordinator 是如何应对混部场景下的挑战,特别是提升混部场景下工作负载的运行的效率和稳定性,以及对后续技术演进的思考与规划。我们也将本次直播的核心内容进行了整理,希望能给大家带来一些深入的启发。
直播回顾 | 云原生混部系统 Koordinator 架构详解(附完整PPT)
阿里云ACE怎么考?现在的考试方式难不难?
但是从另一方面来讲,这样也是在大幅度提升ACE的含金量,过去的考试难度比较低,很多人都能考这个证书,造成了人才泛滥的现象,于是阿里云提高了ACE的门槛,一是为了推广ACP,一是为了抬高ACE。
566 1