云服务器内容精选
-
命名空间权限 Kubernetes RBAC API定义了四种类型：Role、ClusterRole、RoleBinding与ClusterRoleBinding。当前CCI仅支持ClusterRole、RoleBinding，这两种类型之间的关系和简要说明如下： ClusterRole：描述角色和权限的关系。在Kubernetes的RBAC API中，一个角色定义了一组特定权限的规则。整个Kubernetes集群范围内有效的角色则通过ClusterRole对象实现。 RoleBinding：描述subjects（包含users，groups）和角色的关系。角色绑定将一个角色中定义的各种权限授予一个或者一组用户，该用户或用户组则具有对应绑定ClusterRole定义的权限。 表1 RBAC API所定义的两种类型 类型名称 说明 ClusterRole ClusterRole对象可以授予整个集群范围内资源访问权限。 RoleBinding RoleBinding可以将同一Namespace中的subject（用户）绑定到某个具有特定权限的ClusterRole下，则此subject即具有该ClusterRole定义的权限。 当前仅支持用户使用ClusterRole在Namespace下创建RoleBinding。
-
漏洞详情 近日Kubernetes官方披露了kube-apiserver组件的安全漏洞CVE-2020-8559，CVSS Rating: Medium (6.4) CVSS:3.1/AV:N/AC:H/PR:H/UI:R/S:U/C:H/I:H/A:H。攻击者可以通过截取某些发送至节点kubelet的升级请求，通过请求中原有的访问凭据转发请求至其它目标节点，攻击者可利用该漏洞提升权限。 参考链接：https://github.com/kubernetes/kubernetes/issues/92914
-
配置说明 您需要拥有一个主账号，仅主账号、授予了CCIFullAccess权限的用户或拥有RBAC所有权限的用户，才可以对其他用户进行授权操作。 本例将对用户和用户组授予操作不同命名空间资源的权限，在您的实际业务中，您可根据业务需求仅对用户或用户组授予不同的权限。 本例仅用于给用户或用户组在未授权过的命名空间下新增权限，已授权的用户或用户组的权限可以在“权限管理”的列表“操作”栏中单击“编辑”进行修改。 当给用户或用户组添加多个权限时，多个权限会同时生效（取并集）；为用户组设置的权限将作用于用户组下的全部用户。 在开启RBAC鉴权场景下，同类权限取并集，不同类权限取交集。例如， IAM 细粒度鉴权中给用户组添加了多个权限，此时权限取最高权限，同理CCI权限管理给用户或用户组添加了多个权限，此时权限也取最高权限，即为同类权限取并集。当用户拥有CCI CommonOperations权限时，本可以创建无状态负载，但如该用户以及用户所在用户组未在目标Namespace下被赋予对应RBAC权限，则创建无状态负载会鉴权失败，即为不同类权限取交集。
-
示例流程 命名空间是对一组资源和对象的抽象整合。在同一个集群内可创建不同的命名空间，不同命名空间中的数据彼此隔离，使得它们既可以共享同一个集群的服务，也能够互不干扰。命名空间的一个重要的作用是充当一个虚拟的集群，用于多种工作用途，满足多用户的使用需求。 本章节将沿用创建用户并授权使用CCI中创建的IAM用户“James”和用户组“开发人员组”进行说明，为IAM用户“James”和用户组“开发人员组”添加命名空间权限，可以参考如下操作： 步骤一：为IAM用户/用户组添加命名空间权限 步骤二：用户登录并验证权限
-
步骤一：为IAM用户/用户组添加命名空间权限 本步骤以主账号给CCI CommonOperations用户（James）赋予Namespace下view权限为例，被授权的CCI CommonOperations用户在该Namespace下只有只读权限。 登录云容器实例管理控制台，在左侧导航栏中选择“权限管理”，进入权限管理页面。 单击“添加授权”，进入添加授权页面。 图1 添加授权 在添加授权页面，选择要授权使用的命名空间，此处选择“cci-namespace-demo-rbac”。 图2 选择命名空间 为“开发人员组”增加“admin”权限，在展开的选项中进行如下配置： 用户/用户组：选择“用户组”，并在二级选项中选择“开发人员组”。 权限：选择“admin”。 图3 为用户组授予admin权限 单击下方的“添加命名空间权限”，为用户“James”增加在另一个命名空间“cci-namespace-demo-rbac01”的权限，在展开的选项中进行如下配置： 命名空间：选择“cci-namespace-demo-rbac01”。 用户/用户组：选择“用户”，并在二级选项中选择“James”。 权限：选择“view”。 图4 添加命名空间权限 单击“创建”，完成以上用户和用户组在命名空间中的相应权限设置。 图5 命名空间权限列表 经过以上操作，授权结果如下： 由于“开发人员组”包含IAM用户“James”，因此IAM用户“James”也同时获得了在命名空间“cci-namespace-demo-rbac”的“admin”权限。 为IAM用户“James”增加了在命名空间“cci-namespace-demo-rbac01”的“view”权限。
-
约束与限制 调度到CCI的实例的存储类型支持ConfigMap、Secret、EmptyDir、DownwardAPI、Projected、PersistentVolumeClaims几种Volume类型，其中Projected和DownwardAPI类型仅bursting 1.3.25版本及以上支持。 EmptyDir：不支持子路径。 PersistentVolumeClaims：只支持SFS、SFS Turbo 云存储 类型，且只支持使用 CS I类型的StorageClass。volcano调度器不支持调度所有云存储类型。 Projected：如配置了serviceAccountToken类型的source，那么弹性到CCI后挂载的会是对应service-account-token secret中的token，该token为长期有效的token且没有预期受众，即expirationSeconds和audience两项配置不会生效。
-
负载Hostpath配置方式 操作场景 在使用CCE或者其他K8s集群时，用户使用HostPath类型存储。但CCI是共享集群，不开放HostPath能力，因此使用HostPath的Pod通过bursting弹到CCI时，会被拦截。如无法改变Pod spec.volumes中配置的HostPath，可通过配置Annotation的形式，允许让使用HostPath的Pod弹性到CCI上，bursting在校验时需要去掉Pod中的HostPath或者将HostPath替换为emptyDir。 约束与限制 EmptyDir的sizeLimit需为1Gi的整数倍，且不能大于Pod CPU核数的10倍。 LocalDir和flexVolume当前暂不支持。 操作步骤 通过在Pod.Annotations中加入注解可以做到hostPath转emptydir。 单个hostPath替换为emptyDir配置方式： "coordinator.cci.io/hostpath-replacement": '[{"name":"source-hostpath-volume-3","policyType":"replaceByEmptyDir","emptyDir":{"sizeLimit":"10Gi"}}]' 单个hostPath忽略： "coordinator.cci.io/hostpath-replacement": '[{"name":"source-hostpath-volume-1","policyType":"remove"}]' 全部HostPath都忽略： "coordinator.cci.io/hostpath-replacement": '[{"name":"*","policyType":"remove"}]' 多个HostPath差异化替换策略： "coordinator.cci.io/hostpath-replacement": '[{"name":"source-hostpath-volume-1","policyType":"remove"},{"name":"source-hostpath-volume-3","policyType":"replaceByEmptyDir","emptyDir":{"sizeLimit":"10Gi"}}]' 对于path为/etc/localtime的HostPath存储，会被单个HostPath替换的策略（策略name为具体的volume name）替换，不会被全部HostPath替换的策略（策略name为"*"）替换。 参考deployment yaml示例： apiVersion: apps/v1kind: Deploymentmetadata: annotations: description: '' labels: virtual-kubelet.io/burst-to-cci: enforce appgroup: '' version: v1 name: test namespace: defaultspec: replicas: 2 selector: matchLabels: app: test version: v1 template: metadata: labels: app: test version: v1 annotations: coordinator.cci.io/hostpath-replacement: '[{"name": "test-log2", "policyType": "remove"}, {"name": "test-log", "policyType": "replaceByEmptyDir", "emptyDir":{"sizeLimit":"10Gi"}}, {"name": "test-log1", "policyType": "remove" }]' spec: containers: - name: container-1 image: nginx imagePullPolicy: IfNotPresent env: - name: PAAS_APP_NAME value: test - name: PAAS_NAMESPACE value: default - name: PAAS_PROJECT_ID value: 0b52a6e40b00d3682f36c0005163a82c resources: requests: cpu: 250m memory: 512Mi limits: cpu: 250m memory: 512Mi volumeMounts: - name: test-log mountPath: /tmp/log - name: test-log1 mountPath: /tmp/log1 - name: test-log2 mountPath: /tmp/log2 volumes: - hostPath: path: /var/paas/sys/log/virtual-kubelet type: "" name: test-log - hostPath: path: /var/paas/sys/log type: "" name: test-log1 - hostPath: path: /var/paas/sys/log2 type: "" name: test-log2
-
漏洞详情 Kubernetes官方发布安全漏洞CVE-2020-13401，CVSS Rating: CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:L/I:L/A:L (6.0 Medium)。 漏洞源于IPv6动态分配除提供了IPv6的DHCP技术外，还支持Router Advertisement技术。路由器会定期向节点通告网络状态，包括路由记录。客户端会通过NDP进行自身网络配置。 恶意攻击者可以篡改主机上其他容器或主机本身的IPv6路由记录，实现中间人攻击。即使现在系统或者服务上没有直接使用IPv6地址进行网络请求通知，但是如果DNS返回了A(IPv4)和AAAA(IPv6)记录，许多HTTP库都会尝试IPv6进行连接，如果再回退到IPv4，这为攻击者提供了响应的机会。 参考链接：https://github.com/kubernetes/kubernetes/issues/91507
-
支持的存储类型 用户在配置负载存储类型时，CCE的console有如下选项。 弹性CCI的负载对存储类型的支持情况如下： volume类型 是否支持 特殊场景说明 HostPath 否 CCI是共享集群，不直接开放HostPath能力。 1.5.9及以上版本可支持配置path为/etc/localtime的HostPath存储，配置后CCI侧容器中挂载的时区将会与CCE节点的时区一致。 ConfigMap 是 - Secret 是 - EmptyDir 是 挂载EmptyDir不支持子路径。 EmptyDir的sizeLimit需为1Gi的整数倍，且不能大于Pod CPU核数的10倍。 DownwardAPI 是 - Projected 是 如配置了serviceAccountToken类型的source，弹性到CCI后会挂载对应service-account-token secret中的token，该token为长期有效，且token没有预期受众，即expirationSeconds和audience两项配置不会生效。 PersistentVolumeClaims 是 只支持SFS、SFS Turbo云存储类型，且只支持使用CSI类型的StorageClass。
-
pod资源规格算法 弹性CCI的pod规格，根据container资源的Requests和Limits计算，调整至CCI允许范围。 pod规格的计算方式遵循如下规则： 所有应用容器和初始化容器对某个资源的Requests和Limits均会被设置为相等的值，如果配置了Limits，则取Limits值；如果没有配Limits，则取Requests值。 pod对某个资源的Requests和Limits，是取如下两项的较大者： 所有应用容器对某个资源的Limits之和。 所有初始化容器Limits的最大值。 Pod规格约束： Pod的CPU需大于0。 经过资源自动规整后，Pod的CPU在0.25核~32核范围内，或者等于48核或64核；Memory在1Gi~512Gi范围内，且必须为1Gi的整数倍，且满足CPU/Memory配比值在1:2~1:8之间。
-
使用Service方式访问-创建工作负载时设置 在云容器实例中，您只需要在创建负载时，填写服务名称和负载的端口配置，即可通过“服务名称:负载访问端口”访问到该负载。 服务名称：服务名称即Service的名称，Service是用于管理Pod访问的对象。Service的详细信息请参见https://support.huaweicloud.com/devg-cci/cci_05_0007.html。 安装coredns：coredns插件为您的其他负载提供内部 域名 解析服务，如果不安装coredns则无法通过“服务名称:负载访问端口”访问负载。 负载端口配置 协议：访问负载的通信协议，可选择TCP或UDP。 负载访问端口：负载提供的访问端口。 容器端口：容器监听的端口，负载访问端口映射到容器端口。
-
资源规整算法 假设根据pod资源规格算法求得CPU（core）、Memory（Gi），则自动规整规则如下： 将Pod中除了BestEffort的每个应用容器和初始化容器的CPU向上调整至0.25核的整数倍， Memory向上调整至大于等于0.2Gi。 CCE突发弹性引擎（对接 CCI）插件1.5.16版本及之后，不再进行容器级别的向上规整，仅进行pod级别的向上规整。 若此时Pod的CPU大于32u或者Memory大于256Gi，则不再继续进行自动调整，否则将继续调整。 将整个pod的CPU配额向上调整至0.25核的整数倍，Memory配额向上调整至1Gi的整数倍。 若pod Memory/CPU的比值小于2，需将pod Memory向上调整至大于等于CPU的2倍，且满足是1Gi的整数倍。 若pod Memory/CPU的比值大于8，需将pod CPU向上调整至大于等于Memory的1/8，且满足是0.25核的整数倍。 以上对pod级别资源向上调整造成的增量CPU和Memory，全部添加到Pod中第一个不为BestEffort的容器上。 BestEffort容器是指没有配置Requests和Limits的容器。 经过资源自动规整后，Pod规格约束： pod的CPU取值在0.25核~32核范围内，或者等于48核或64核，并且要求值为0.25的整数倍。 Memory在1Gi~256Gi范围内，或者等于384Gi或512Gi，且Memory是整数。 满足Memory/CPU配比值在2~8之间。 用户可以通过CCE侧的pod的annotation查看规整后的规格。 virtual-kubelet.cci.io/burst-pod-cpu: 0.5u virtual-kubelet.cci.io/burst-pod-memory: 1Gi
-
资源规整用例说明 资源规格 （CPU MEM） 规整后规格（CPU MEM） 说明 37U 37Gi 无法创建pod弹性到CCI。 CPU规格无效。 30U 257Gi 无法创建pod弹性到CCI。 存算比大于8，提高CPU。但无法满足CPU规格有效，拦截。 0.35U 0.5Gi 0.5U 1Gi CPU向上取整0.25的整数倍，MEM向上取整1的整数倍。存算比符合要求，不做调整。 0.35U 1.5Gi 0.5U 2Gi CPU向上取整0.25的整数倍，MEM向上取整1的整数倍。存算比符合要求，不做调整。 0.45U 18Gi 2.25U 18Gi CPU向上取整0.25的整数倍，MEM向上取整1的整数倍。存算比大于8，提高CPU。 2U 2Gi 2U 4Gi 存算比小于2，提高MEM。
-
命名空间与网络的关系 从网络角度，命名空间对应一个虚拟私有云（VPC）中一个子网，如图1所示，在创建命名空间时会关联已有VPC或创建一个新的VPC，并在VPC下创建一个子网。后续在该命名空间下创建的容器及其他资源都会在对应的VPC及子网之内。 通常情况下，如果您在同一个VPC下还会使用其他服务的资源，您需要考虑您的网络规划，如子网网段划分、IP数量规划等，确保有可用的网络资源。 图1 命名空间与VPC子网的关系
-
kubernetes中的域名解析逻辑 DNS策略可以在每个pod基础上进行设置，目前，Kubernetes支持Default、ClusterFirst、ClusterFirstWithHostNet和None四种DNS策略，具体请参见https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/。这些策略在pod-specific的dnsPolicy 字段中指定。 “Default”：如果dnsPolicy被设置为“Default”，则名称解析配置将从pod运行的节点继承。 自定义上游域名服务器和存根域不能够与这个策略一起使用。 “ClusterFirst”：如果dnsPolicy被设置为“ClusterFirst”，任何与配置的集群域后缀不匹配的DNS查询（例如，www.kubernetes.io）将转发到从该节点继承的上游名称服务器。集群管理员可能配置了额外的存根域和上游DNS服务器。 “ClusterFirstWithHostNet”：对于使用hostNetwork运行的Pod，您应该明确设置其DNS策略“ClusterFirstWithHostNet”。 “None”：它允许Pod忽略Kubernetes环境中的DNS设置。应使用dnsConfigPod规范中的字段提供所有DNS设置 。 Kubernetes 1.10及以上版本，支持Default、ClusterFirst、ClusterFirstWithHostNet和None四种策略；低于Kubernetes 1.10版本，仅支持default、ClusterFirst和ClusterFirstWithHostNet三种。 “Default”不是默认的DNS策略。如果dnsPolicy的Flag没有特别指明，则默认使用“ClusterFirst”。 路由请求流程： 未配置存根域：没有匹配上配置的集群域名后缀的任何请求，例如 “www.kubernetes.io”，将会被转发到继承自节点的上游域名服务器。 已配置存根域：如果配置了存根域和上游 DNS 服务器，DNS 查询将基于下面的流程对请求进行路由： 查询首先被发送到 coredns 中的 DNS 缓存层。 从缓存层，检查请求的后缀，并根据下面的情况转发到对应的 DNS 上： 具有集群后缀的名字（例如“.cluster.local”）：请求被发送到 coredns。 具有存根域后缀的名字（例如“.acme.local”）：请求被发送到配置的自定义 DNS 解析器（例如：监听在 1.2.3.4）。 未能匹配上后缀的名字（例如“widget.com”）：请求被转发到上游 DNS。 图7 路由请求流程
更多精彩内容
CDN加速
GaussDB
文字转换成语音
免费的服务器
如何创建网站
域名网站购买
私有云桌面
云主机哪个好
域名怎么备案
手机云电脑
SSL证书申请
云点播服务器
免费OCR是什么
电脑云桌面
域名备案怎么弄
语音转文字
文字图片识别
云桌面是什么
网址安全检测
网站建设搭建
国外CDN加速
SSL免费证书申请
短信批量发送
图片OCR识别
云数据库MySQL
个人域名购买
录音转文字
扫描图片识别文字
OCR图片识别
行驶证识别
虚拟电话号码
电话呼叫中心软件
怎么制作一个网站
Email注册网站
华为VNC
图像文字识别
企业网站制作
个人网站搭建
华为云计算
免费租用云托管
云桌面云服务器
ocr文字识别免费版
HTTPS证书申请
图片文字识别转换
国外域名注册商
使用免费虚拟主机
云电脑主机多少钱
鲲鹏云手机
短信验证码平台
OCR图片文字识别
SSL证书是什么
申请企业邮箱步骤
免费的企业用邮箱
云免流搭建教程
域名价格
