Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Update node.md #3790

Merged
merged 1 commit into from
Jan 27, 2015
Merged

Update node.md #3790

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
49 changes: 46 additions & 3 deletions docs/node.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -11,9 +11,52 @@ doc for more details.

## Node Status

Node Status is still under development. See:
[#2164](https://github.com/GoogleCloudPlatform/kubernetes/issues/2164),
[#2315](https://github.com/GoogleCloudPlatform/kubernetes/pull/2315).
Node status describes current status of a node. For now, there are three
pieces of information:

### HostIP

Host IP address is queried from cloudprovider and stored as part of node
status. If kubernetes runs without cloudprovider, node's ID will be used.
IP address can change, and there are different kind of IPs, e.g. public
IP, private IP, dynamic IP, ipv6, etc. It makes more sense to save it as
a status rather than spec.

### Node Phase

Node Phase is the current lifecycle phase of node, one of `Pending`,
`Running` and `Terminated`. Node Phase management is under development,
here is a brief overview: In kubernetes, node will be created in `Pending`
phase, until it is discovered and checked in by kubernetes, at which time,
kubernetes will mark it as `Running`. The end of a node's lifecycle is
`Terminated`. A terminated node will not receive any scheduling request,
and any running pods will be removed from the node.

Node with `Running` phase is necessary but not sufficient requirement for
scheduling Pods. For a node to be considered a scheduling candidate, it
must have appropriate conditions, see below.

### Node Condition
Node Condition describes the conditions of `Running` nodes. Current valid
conditions are `NodeReachable` and `NodeReady`. In the future, we plan to
add more. `NodeReachable` means the node can be reached within the cluster.
`NodeReady` means the kubelet returns StatusOK for HTTP health check. Different
condition provides different level of understanding for node health. Kubernetes
will make a comprehensive scheduling decision based on the information. Node
condition is represented as a json object. For example, the following conditions
mean the node is reachable from its cluster, but not ready to accept pods:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I might be confused here, but shouldn't the example you listed below is opposite of what you claimed above? Shouldn't be {"kind": "Reachable", "status": "Full"}, {"kind": "Ready", "status": "None"}?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, good catch, updated.

```json
"conditions": [
{
"kind": "Reachable",
"status": "Full",
},
{
"kind": "Ready",
"status": "None",
}
]
```

## Node Management

Expand Down