Cluster planning

• Network planning:

  • Network type: Flannel or Terway

Terway is a self-developed network plug-in of Ali Cloud container service. It is fully compatible with Flannel in functions. If Flannel is conservative, it is still used

• Pod CIDR network

The default large network segment is 16. The valid network segment or its subnet is 10.0.0.0/8, 172.16-31.0.0/12-16, 192.168.0.0/16

• Service CIDR

  • The default network segment is 20. You can set this parameter to 10.0.0.0/16-24, 172.16-31.0.0/16-24, and 192.168.0.0/16-24
  • Network segments must be unique and cannot be modified after being created.
  • Multiple switches in multiple areas.

• Access ApiServer from the public network

  • For clusters with high security requirements such as online, you can choose not to expose Apiserver and only have private NETWORK SLB, but in this way, cloud effect publishing is not possible.
  • After a cluster is established, access control is established for the SLB to restrict the ACCESS of the SLB to the cloud effect only.

Note: Every security vulnerability of K8s is almost related to ApiServer. For online K8s cluster, patch should be updated in time, or ApiServer on public network should not be opened, and strict security group and access control should be used.

• The security group

  • Set security group limited access range for master and worker machines.

• Master Machine Planning

For high availability, three nodes are generally used. The Master selection rules are as follows:

It is recommended that the storage of the master machine be 50-100 GB SSD with high performance. Because ETCD is running, the operating system takes up no more than 8 GB.

• Worker machine planning

  • Ali Cloud is the first to promote Shenlong machine. In areas where there is no Shenlong machine, ECS with high configuration is selected. The configuration specifications are multiplied by a certain number according to the POD specifications deployed. Set a fixed request/limit for pod at deployment time.

  • The machine configuration we choose:

    • 32C64G ECS
    • Storage. System disk: 100 GB SSD; data disk: 400 GB efficient cloud disk
    • Operating system: centos 7.4 64-bit

Stateless deployment

Using stateless Deployment, refer to this article for batch Deployment. Optimization Settings template:

apiVersion: apps/v1beta2
kind: Deployment
metadata:
  annotations:
    deployment.kubernetes.io/revision: '34'
# tag, map service
  labels:
    app: {app_name}-aone
  name: {app_name}-aone-1
  namespace: {app_name}
spec:
  progressDeadlineSeconds: 600
  replicas: 1
  revisionHistoryLimit: 10
  selector:
    matchLabels:
      app: {app_name}-aone
# Batch restart update policy
  strategy:
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%
    type: RollingUpdate
  template:
    metadata:
      labels:
        app: {app_name}-aone
    spec:
      containers:
       The environment variable increases the time zone
        - env:
            - name: TZ
              value: Asia/Shanghai
        - image: >-
            registry-vpc.cn-north-2-gov-1.aliyuncs.com/{namespace}/{app_name}:20190820190005
          imagePullPolicy: Always
          Perform graceful offline removal service registration before startup
          lifecycle:
            preStop:
              exec:
                command:
                  - sudo
                  - '-u'
                  - admin
                  - /home/{user_name}/{app_name}/bin/appctl.sh
                  - {app_name}
                  - stop
          # Survival check, highly recommended
          livenessProbe:
            failureThreshold: 10
            initialDelaySeconds: 30
            periodSeconds: 10
            successThreshold: 1
            tcpSocket:
              port: 5900
            timeoutSeconds: 1
          name: {app_name}-aone
          # Readiness check, strongly recommended
          readinessProbe:
            failureThreshold: 10
            initialDelaySeconds: 30
            periodSeconds: 10
            successThreshold: 1
            tcpSocket:
              port: 5900
            timeoutSeconds: 1
          # Resource limit, this must be set properly
          resources:
            limits:
              cpu: '4'
              memory: 8Gi
            requests:
              cpu: '4'
              memory: 8Gi
          terminationMessagePath: /dev/termination-log
          terminationMessagePolicy: File
          /home/{user_name}/logs = /home/{user_name}/logs = /home/{user_name}/logs
          volumeMounts:
            - mountPath: /home/{user_name}/logs
              name: volume-1553755418538
      dnsPolicy: ClusterFirst
      The private mirror repository key is obtained from the private field
      imagePullSecrets:
        - name: {app_name}-987
      restartPolicy: Always
      schedulerName: default-scheduler
      securityContext: {}
      terminationGracePeriodSeconds: 30
      /var/lib/docker/logs/directory
      volumes:
        - hostPath:
            path: /var/lib/docker/logs/{app_name}
            type: ' '
          name: volume-1553755418538Copy the code

conclusion

Although ali cloud container service console is a new product on the cloud, it provides extremely simple one-click deployment function, as well as simple console management. In the past year, THE author has witnessed the transformation process of Ali Cloud container service console from simple to powerful. Despite repeated stumps, the seriousness, responsibility and excellent service attitude of ali Cloud container service students are admirable.

The container service management console also needs to consider more actual operation and maintenance requirements, and closely integrate existing cloud products, such as cloud effect, EDAS, cloud monitoring, log services, etc., to provide better services on an application basis.

The author: Yi Luzhou

The original link

This article is the original content of the cloud habitat community, shall not be reproduced without permission.