add KEP for pod ready++

keps/sig-network/0007-pod-ready++.md

@@ -0,0 +1,96 @@
+---
+kep-number: 1
+title: Pod Ready++
+authors:
+  - "freehan@"
+owning-sig: sig-network
+participating-sigs:
+  - sig-node
+  - sig-cli
+reviewers:
+  - thockin@
+  - dchen1107@
+approvers:
+  - thockin@
+  - dchen1107@
+editor: freehan@
+creation-date: 2018-04-01
+last-updated: 2018-04-01
+status: provisional
+
+---
+
+# Pod Ready++
+
+
+## Table of Contents
+
+A table of contents is helpful for quickly jumping to sections of a KEP and for highlighting any additional information provided beyond the standard KEP template.
+[Tools for generating][] a table of contents from markdown are available.
+
+* [Table of Contents](#table-of-contents)
+* [Summary](#summary)
+* [Motivation](#motivation)
+    * [Goals](#goals)
+    * [Non-Goals](#non-goals)
+* [Proposal](#proposal)
+    * [Implementation Details/Notes/Constraints [optional]](#implementation-detailsnotesconstraints-optional)
+    * [Risks and Mitigations](#risks-and-mitigations)
+* [Graduation Criteria](#graduation-criteria)
+
+
+## Summary
+
+This proposal aims to add extensibility to pod readiness. Besides container readiness, external feedback can be injected into PodStatus and influence pod readiness. Thus, achieving pod “ready++”. 
+
+
+## Motivation
+
+Pod readiness indicates whether the pod is ready to serve traffic. Pod readiness is dictated by kubelet with user specified readiness probe. On the other hand, pod readiness determines whether pod address shows up on the address list on related endpoints object. K8s primitives that manage pods, such as Deployment, only takes pod status into account for decision making, such as advancement during rolling update. 
+
+For example, during deployment rolling update, a new pod becomes ready. On the other hand, service, network policy and load-balancer are not yet ready for the new pod due to whatever reason (e.g. slowness in api machinery, endpoints controller, kube-proxy, iptables or infrastructure programming). This may cause service disruption or lost of backend capacity. In extreme cases, if rolling update completes before any new replacement pod actually start serving traffic, this will cause service outage. 
+
+
+### Goals
+
+- Allow extra signals for pod readiness.
+
+### Non-Goals
+
+- Provide generic framework to solve transition problems in k8s (e.g. blue green deployment).
+
+
+## Proposal
+
+[K8s Proposal: Pod Ready++](https://docs.google.com/document/d/1VFZbc_IqPf_Msd-jul7LKTmGjvQ5qRldYOFV0lGqxf8/edit#)
+
+
+
+### Implementation Details/Notes/Constraints
+
+This proposal mostly involves kubelet changes:
+- Use PATCH instead of PUT to update PodStatus fields that are dictated by kubelet. 
+- Only compare the fields that managed by kubelet for PodStatus reconciliation .
+- Watch PodStatus changes and evaluate ReadinessGates for pod readiness.
+
+### Risks and Mitigations
+
+Risks:
+- Features that utilize the extension point from this proposal may abuse the API.  
+- User confusion on pod ready++
+
+Mitigations:
+- Better specification and API validation.
+- Better CLI/UI/UX
+
+
+## Graduation Criteria
+
+- Kubelet changes should not have any impact on kubelet reliability
+- Feature adoption on the proposed extension.
+
+
+## Implementation History
+
+TBD
+