本文主要为您介绍网络管理中的常见问题。

旧版本CCM如何支持SLB重命名

Cloud Controller Manager组件V1.9.3.10后续版本创建的SLB支持自动打TAG从而可以重命名，而V1.9.3.10及之前的版本，您需要手动给该SLB打上一个特定的TAG从而支持SLB重命名。 操作步骤如下：
说明
  • 只有Cloud Controller Manager组件V1.9.3.10及之前版本创建的SLB才需要手动打TAG的方式来支持重命名。
  • Service类型为Loadbalancer。
  1. 登录到Kubernetes集群Master节点，请参见通过kubectl连接Kubernetes集群。
  2. 执行 # kubectl get svc -n ${namespace} ${service}命令，查看该Service类型及IP。service类型
    说明 您需要将${namespace}与${service}替换为所选集群的命名空间及服务名称。
  3. 执行以下命令，生成该SLB所需要的TAG。
    kubectl get svc -n ${namespace} ${service} -o jsonpath="{.metadata.uid}"|awk -F "-" '{print "kubernetes.do.not.delete: "substr("a"$1$2$3$4$5,1,32)}'
    tag
  4. 登录负载均衡控制台根据步骤2中所获取的IP，在其所在的地域搜索到该SLB。
  5. 根据步骤3生成的KEY值和VALUE值（分别对应上图的1和2），为该SLB打上一个TAG。详情请参见添加标签。

如何选择Kubernetes集群Terway和Flannel网络插件

下面为您详细介绍在ACK创建集群时使用的两种网络插件：Terway和Flannel。

在创建Kubernetes集群时，阿里云容器服务提供以下两种网络插件：
  • Flannel：使用的是简单稳定的社区的Flannel CNI插件，配合阿里云的VPC的高速网络，能给集群高性能和稳定的容器网络体验，但功能偏简单，支持的特性少，例如：不支持基于Kubernetes标准的Network Policy。
  • Terway：是阿里云容器服务自研的网络插件，功能上完全兼容Flannel，支持将阿里云的弹性网卡分配给容器，支持基于Kubernetes标准的NetworkPolicy来定义容器间的访问策略，支持对单个容器做带宽的限流。对于不需要使用Network Policy的用户，可以选择Flannel，其他情况建议选择Terway。了解更多Terway网络插件的相关内容，请参见如何使用Terway网络插件。

如何手动安装alicloud-application-controller

在阿里云容器服务中，1.10.4及以上版本默认安装alicloud-application-controller，来提供一种基于CRD的分批发布的能力。

说明 Kubernetes最新集群已经默认安装alicloud-application-controller，旧版本集群可以通过手动安装的方式部署alicloud-application-controller，要求Kubernetes集群版本不低于为V1.9.3。
您可通过kubectl create -f alicloud-application-controller.yml命令部署alicloud-application-controller，在alicloud-application-controller.yml中输入如下的编排模板。
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: alicloud-application-controller
  labels:
    owner: aliyun
    app: alicloud-application-controller
  namespace: kube-system
spec:
  replicas: 1
  selector:
    matchLabels:
      owner: aliyun
      app: alicloud-application-controller
  template:
    metadata:
      labels:
        owner: aliyun
        app: alicloud-application-controller
      annotations:
        scheduler.alpha.kubernetes.io/critical-pod: ''
    spec:
      tolerations:
      - effect: NoSchedule
        operator: Exists
        key: node-role.kubernetes.io/master
      - effect: NoSchedule
        operator: Exists
        key: node.cloudprovider.kubernetes.io/uninitialized
      containers:
        - name: alicloud-application-controller
          image: registry.cn-hangzhou.aliyuncs.com/acs/aliyun-app-lifecycle-manager:0.1-c8d5da8
          imagePullPolicy: IfNotPresent
      serviceAccount: admin

ACK是否支持hostPort的端口映射

  • 不支持hostPort。
  • 容器服务ACK的Pod地址是可以直接被VPC中其他资源访问的，不需要额外的端口映射。
  • 如果需要把服务暴露到外部，可以使用NodePort或者LoadBalancer类型的Service。

Local模式下如何自动设置Node权重

本文以业务Pod（app=nginx）部署在三台ECS上，通过Service A对外提供服务为例，说明在Local模式下Node权重的计算方式。
图 1.
CCM2

  • V1.9.3.164-g2105d2e-aliyun之前版本

    如图2所示，在V1.9.3.164-g2105d2e-aliyun之前版本，Local模式的Service其所有后端权重均为100，即所有流量平均分配到这三台ECS上，造成ECS 1上Pod负载较重而ECS 3上的Pod负载较轻，导致Pod负载不均。

    图 2.
    CCM3

  • V1.9.3.164-g2105d2e-aliyun之后及V1.9.3.276-g372aa98-aliyun之前版本

    如图3所示，在V1.9.3.164-g2105d2e-aliyun之后及V1.9.3.276-g372aa98-aliyun之前版本，CCM会根据Node上部署的Pod数量计算Node权重。经计算三台ECS权重分别为16、33、50，因此流量将大致按照1:2:3的比例分配给三台ECS，Pod负载更加均衡。

    计算公式如下。计算公式
    图 3.
    ccm4

  • V1.9.3.276-g372aa98-aliyun及之后版本

    图3的权重计算方式因为计算精度问题，Pod间还会存在轻微的负载不均。在V1.9.3.276-g372aa98-aliyun及之后版本，CCM将Node上部署的Pod数量设置为Node权重，如图4所示，三台ECS的权重分别为1、2、3，流量会按照1:2:3的比例分配给三台ECS，Pod负载比图3的方式更加均衡。

    计算公式如下。node权重
    图 4.
    node