Implement service with IPVS

[Crazykev]

Replace service implement with IPVS.

This PR is implement through manipulating ipvsadm tool to admin ipvs rules. So Add/Delete/UpdateService operation will be converted to corresponding ipvsadm rules, here I call them patch.

How to test this:

1. build a hyperstart image with ipvs support from Add ipvsadm tool in favor of IPVS implement of service hyperstart#247.
2. build a hyperd with this patch. (already have runv parts(Implement service with IPVS runv#409) vendored)
3. start hyperd with cmd:

hyperd -v=3 --logtostderr --host=127.0.0.1:1246

4. start a server pod, such as nginx. and a check pod, busybox is fine.

# hyperctl run -d nginx
POD id is nginx-6290370006
Time to run a POD is 1518 ms

# hyperctl run -t busybox sh    //podID2
POD id is busybox-4084967684
Time to run a POD is 1412 ms

5. create service rules through curl api

# curl -X POST "http://localhost:1246/service/add?podId=busybox-4084967684&services=\[\{\"serviceIP\":\"1.1.1.1\",\"protocol\":\"TCP\",\"servicePort\":80,\"hosts\":\[\{\"hostIP\":\"192.168.123.2\",\"hostPort\":80\}\]\}\]"
["Result=success"]

# curl -X GET "http://localhost:1246/service/list?podId=busybox-4084967684"
[{"serviceIP":"1.1.1.1","protocol":"TCP","servicePort":80,"hosts":[{"hostIP":"192.168.123.2","hostPort":80}]}]

# hyperctl exec -t busybox-4084967684 sh
//before https://github.com/hyperhq/hyperd/pull/492 merge, we need add it manually.
# route add default gw 192.168.123.1 dev eth0 
# wget 1.1.1.1
Connecting to 1.1.1.1 (1.1.1.1:80)
index.html           100% |*******************************|   612   0:00:00 ETA

/cc @feiskyer @resouer

[feiskyer]

There are generally three problems for service operations:

1. We should operations VM first (if running), and update podspec later. or else, podspec needs to rollback if vm operations failed.
2. if podspec updated, it should also be saved to db so we don't lose it if pod restarted
3. how is ipvs rules being determined? could them support configurations? e.g. algorithms, mode (DR/NAT/FULLNAT)

[Crazykev]

@feiskyer Sorry for the delay.

We should operations VM first (if running), and update podspec later. or else, podspec needs to rollback if vm operations failed.

It is what is implemented. Won't rewrite service field in podspec until operation on VM succeed. And also ipvs rules in VM will rollback if operation failed.

if podspec updated, it should also be saved to db so we don't lose it if pod restarted

Indeed, I'll enhance it later.

how is ipvs rules being determined?

Currently, Each operation of service API will map to two types of operation on ipvs rules --- add and delete. Generation code is here. real/virtualServer and protocol is determined by API arguments. Proxy algorithm is hard coded as NAT(masquerading), scheduling algorithm as RR and weight of real server as 1.

could them support configurations? e.g. algorithms, mode (DR/NAT/FULLNAT)

I think part of them can support configuration if we need to. While I not sure about proxy algorithm, DR seems not meet our need, for can't support port mapping. I've not really concerned with FULLNAT before, I checked that alibaba LVS project just now, seems not updated for a long time, and that part of code has not merged to upstream, I'm not sure we really need that part of feature. If we do, we may could use that version of ipvsadm and some kernel patch maybe.
As for others, scheduling algorithm could be configured, and weight of real server can be configured through API change. What do you think?

[Crazykev]

UPDATE:

1. use hyperstart-exec feature, move runv part(Implement service with IPVS runv#409) to here.
2. save change to db when service update succeed.
3. add service field validation in podspec.
4. fix a bug that pod factory forget to init db.

@feiskyer PTAL

[feiskyer]

lgtm. cc/ @gnawux would you like to take another look?

[gnawux]

I will have a look soon.

[gnawux]

This patch set is really appreciated, and I have only one question -- Should we have a protocol field in serviceKey? @Crazykev @feiskyer

[feiskyer]

@gnawux It could, but I don't think there are such use cases.

[Crazykev]

Yeap, will add soon.

[gnawux]

I merged this PR, thank you @Crazykev