diff options
| author | lixiaobing10051267 <li.xiaobing1@zte.com.cn> | 2016-08-15 22:23:39 +0800 |
|---|---|---|
| committer | lixiaobing10051267 <li.xiaobing1@zte.com.cn> | 2016-08-15 22:23:39 +0800 |
| commit | bac11ffca49896d22d665239ce3e2df2b43a8153 (patch) | |
| tree | 1e0c353b1d2171d33774602b212ef8e49e741753 | |
| parent | 778d883558cf18510f53cf76ef20a23dd2d5a377 (diff) | |
fix wrong path for all registries
| -rw-r--r--[-rwxr-xr-x] | flannel-integration.md | 6 |
1 files changed, 3 insertions, 3 deletions
diff --git a/flannel-integration.md b/flannel-integration.md index 0468ac09..98aa3e85 100755..100644 --- a/flannel-integration.md +++ b/flannel-integration.md @@ -124,7 +124,7 @@ Kubernetes integration is fairly straight-forward once we understand the pieces * Flannel server consults the Kubernetes master for everything network related * Flannel daemon works through network plugins in a generic way without bothering the kubelet: needs CNI x Kubernetes standardization -The first is accomplished in this PR, while a timeline for 2. and 3. are TDB. To implement the flannel api we can either run a proxy per node and get rid of the flannel server, or service all requests in the flannel server with something like a go-routine per node: +The first is accomplished in this PR, while a timeline for 2. and 3. is TDB. To implement the flannel api we can either run a proxy per node and get rid of the flannel server, or service all requests in the flannel server with something like a go-routine per node: * `/network/config`: read network configuration and return * `/network/leases`: - Post: Return a lease as understood by flannel @@ -136,7 +136,7 @@ The first is accomplished in this PR, while a timeline for 2. and 3. are TDB. To - Put: This is a request for a lease. If the nodecontroller is allocating CIDRs we can probably just no-op. * `/network/reservations`: TDB, we can probably use this to accommodate node controller allocating CIDR instead of flannel requesting it -The ick-iest part of this implementation is going to the the `GET /network/leases`, i.e the watch proxy. We can side-step by waiting for a more generic Kubernetes resource. However, we can also implement it as follows: +The ick-iest part of this implementation is going to the `GET /network/leases`, i.e the watch proxy. We can side-step by waiting for a more generic Kubernetes resource. However, we can also implement it as follows: * Watch all nodes, ignore heartbeats * On each change, figure out the lease for the node, construct a [lease watch result](https://github.com/coreos/flannel/blob/0bf263826eab1707be5262703a8092c7d15e0be4/subnet/subnet.go#L72), and send it down the watch with the RV from the node * Implement a lease list that does a similar translation @@ -158,7 +158,7 @@ This proposal is really just a call for community help in writing a Kubernetes x * Flannel server talks to apiserver, described in proposal above * HTTPs between flannel daemon/server * Investigate flannel server running on every node (as done in the reference implementation mentioned above) -* Use flannel reservation mode to support node controller podcidr alloction +* Use flannel reservation mode to support node controller podcidr allocation <!-- BEGIN MUNGE: GENERATED_ANALYTICS --> |