The way of Openstack+kubernetes+docker micro-service--elastic expansion

Service on the line to the top of the live pressure, carry the test, or to be said or we do things brother, remember this scene above?

The old method is a service cluster deployment, but there is always a limit, before with Ali when they have a flexible calculation can be set by the CPU's threshold to dynamically expand and shrink computing capacity, at that time the feeling is very strong, at least at that time our conventional approach is difficult to do, Did not expect to have kubernetes today we can also elated, see me to give you a real show.

Kubernetes automatic expansion for the Replicationcontroller, it will monitor all pods CPU usage, if more than proportional to start more pods to provide services, conversely reduce pods, In general, we will not set the upper limit of pods CPU, but to use automatic expansion will set its threshold so also set the pods CPU use, or Kubernetes no way to calculate its occupancy ratio, so we create RC when we need to specify each pod Upper-bound configuration for CPU resource consumption

APIVERSION:V1
kind:replicationcontroller
metadata:
  name:thrift-c
  Namespace:thrift-demo
Spec:
  replicas:1
  selector:
    app:thrift-c
  Template: Metadata
    :
      name:thrift-c Labels :
        app:thrift-c
    Spec:
      containers:
      -name:thrift-c Resources
        :
          requests:
            CPU: 200m
        image:registry2.io/thrift/thrift-c:0.0.2
        imagepullpolicy:always
        ports:
        -Containerport : 9091
      imagepullsecrets:
        -Name:registry2key

Note the configuration of resources, specify the maximum CPU occupancy of 200m, if it is modified, you must delete RC, recreate, apply not, and note that our replicas here is 1.

Viewed in dashboard, is not in effect,

Stress Test

Our configuration to determine the effective after the kubernetes elastic expansion of the effect of the first step to our services to increase the capacity of automatic expansion, there are two ways, one is the configuration file, the other is done through the KUBECTL command, see command

Kubectl Autoscale RC thrift-c-nthrift-demo--max=10--cpu-percent=10--min=1

The parameter--max is the elasticity expands the maximum pods quantity, the--min nature is the minimum quantity,--cpu-percent is the valve value, is a percentage is the equivalent 10%, this command runs after has given us the appointed RC Thrift-c to increase the automatic expansion ability, the view

We can see target and current as well as quantity and so on, so we don't have any traffic.

The second step, pressure, increase traffic and concurrency, give you a simple command

While true; Do wget-q-o-http://test.k8s.io/hi?name=3213; Done

I executed the command on three machines, and the pressure went straight up,

When the CPU is over 10%, we look at the number of pods.

Pods from one rapidly to 4, if the service capacity does not meet the requirements will increase the number of pods, when I put the pressure test command terminated after the CPU down kubernetes about a few minutes after the pods reduced to the first one, I repeatedly tested several times, this function is very useful and stable , it can timely according to the service pressure to respond, in the contraction of the time delay may be to prevent a short period of time, the CPU stable for a period of time after pods was reduced to our configuration of the--min.

With this feature we are no longer afraid to burst its pressure and server downtime, bottlenecks to the network and disk IO and the database, the server if there is a downtime kubernetes will pods all of it to the other node to start up, to ensure that your pods is always running, But there is a bit of Kubernetes master is a single point of operation, in the back if there is time to study the high availability of master, in fact, there have been many netizens have studied and given solutions, if interested can first understand.