Skip to content

Commit fa71005

Browse files
authored
Merge pull request #28613 from jboxman/OSDOCS-1674
OSDOCS#1674 - Add PodNetworkConnectivityCheck documentation
2 parents deb9447 + 466a678 commit fa71005

6 files changed

+416
-0
lines changed

_topic_map.yml

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -757,6 +757,8 @@ Topics:
757757
- Name: Understanding the Ingress Operator
758758
File: ingress-operator
759759
Distros: openshift-enterprise,openshift-webscale,openshift-origin
760+
- Name: Verifying connectivity to an endpoint
761+
File: verifying-connectivity-endpoint
760762
- Name: Configuring the node port service range
761763
File: configuring-node-port-service-range
762764
- Name: Using SCTP
Lines changed: 162 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,162 @@
1+
// Module included in the following assemblies:
2+
//
3+
// * networking/verifying-connectivity-endpoint.adoc
4+
5+
[id="nw-pod-network-connectivity-check-object_{context}"]
6+
= PodNetworkConnectivityCheck object fields
7+
8+
The `PodNetworkConnectivityCheck` object fields are described in the following tables.
9+
10+
.PodNetworkConnectivityCheck object fields
11+
[cols="2,1,3a",options="header"]
12+
|===
13+
14+
|Field|Type|Description
15+
16+
|`metadata.name`
17+
|`string`
18+
|The name of the object in the following format: `<source>-to-<target>`. The destination described by `<target>` includes one of following strings:
19+
20+
* `load-balancer-api-external`
21+
* `load-balancer-api-internal`
22+
* `kubernetes-apiserver-endpoint`
23+
* `kubernetes-apiserver-service-cluster`
24+
* `network-check-target`
25+
* `openshift-apiserver-endpoint`
26+
* `openshift-apiserver-service-cluster`
27+
28+
|`metadata.namespace`
29+
|`string`
30+
|The namespace that the object is associated with. This value is always `openshift-network-diagnostics`.
31+
32+
|`spec.sourcePod`
33+
|`string`
34+
|The name of the pod where the connection check originates, such as `network-check-source-596b4c6566-rgh92`.
35+
36+
|`spec.targetEndpoint`
37+
|`string`
38+
|The target of the connection check, such as `api.devcluster.example.com:6443`.
39+
40+
|`spec.tlsClientCert`
41+
|`object`
42+
|Configuration for the TLS certificate to use.
43+
44+
|`spec.tlsClientCert.name`
45+
|`string`
46+
|The name of the TLS certificate used, if any. The default value is an empty string.
47+
48+
|`status`
49+
|`object`
50+
|An object representing the condition of the connection test and logs of recent connection successes and failures.
51+
52+
|`status.conditions`
53+
|`array`
54+
|The latest status of the connection check and any previous statuses.
55+
56+
|`status.failures`
57+
|`array`
58+
|Connection test logs from unsuccessful attempts.
59+
60+
|`status.outages`
61+
|`array`
62+
|Connect test logs covering the time periods of any outages.
63+
64+
|`status.successes`
65+
|`array`
66+
|Connection test logs from successful attempts.
67+
68+
|===
69+
70+
The following table describes the fields for objects in the `status.conditions` array:
71+
72+
.status.conditions
73+
[cols="2,1,3",options="header"]
74+
|===
75+
|Field |Type |Description
76+
77+
|`lastTransitionTime`
78+
|`string`
79+
|The time that the condition of the connection transitioned from one status to another.
80+
81+
|`message`
82+
|`string`
83+
|The details about last transition in a human readable format.
84+
85+
|`reason`
86+
|`string`
87+
|The last status of the transition in a machine readable format.
88+
89+
|`status`
90+
|`string`
91+
|The status of the condition.
92+
93+
|`type`
94+
|`string`
95+
|The type of the condition.
96+
97+
|===
98+
99+
The following table describes the fields for objects in the `status.conditions` array:
100+
101+
.status.outages
102+
[cols="2,1,3",options="header"]
103+
|===
104+
|Field |Type |Description
105+
106+
|`end`
107+
|`string`
108+
|The timestamp from when the connection failure is resolved.
109+
110+
|`endLogs`
111+
|`array`
112+
|Connection log entries, including the log entry related to the successful end of the outage.
113+
114+
|`message`
115+
|`string`
116+
|A summary of outage details in a human readable format.
117+
118+
|`start`
119+
|`string`
120+
|The timestamp from when the connection failure is first detected.
121+
122+
|`startLogs`
123+
|`array`
124+
|Connection log entries, including the original failure.
125+
126+
|===
127+
128+
[discrete]
129+
== Connection log fields
130+
131+
The fields for a connection log entry are described in the following table. The object is used in the the following fields:
132+
133+
* `status.failures[]`
134+
* `status.successes[]`
135+
* `status.outages[].startLogs[]`
136+
* `status.outages[].endLogs[]`
137+
138+
.Connection log object
139+
[cols="2,1,3",options="header"]
140+
|===
141+
|Field |Type |Description
142+
143+
|`latency`
144+
|`string`
145+
|Records the duration of the action.
146+
147+
|`message`
148+
|`string`
149+
|Provides the status in a human readable format.
150+
151+
|`reason`
152+
|`string`
153+
|Provides the reason for status in a machine readable format. The value is one of `TCPConnect`, `TCPConnectError`, `DNSResolve`, `DNSError`.
154+
155+
|`success`
156+
|`boolean`
157+
|Indicates if the log entry is a success or failure.
158+
159+
|`time`
160+
|`string`
161+
|The start time of connection check.
162+
|===
Lines changed: 19 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,19 @@
1+
// Module included in the following assemblies:
2+
//
3+
// * networking/verifying-connectivity-endpoint.adoc
4+
5+
[id="nw-pod-network-connectivity-checks_{context}"]
6+
= Connection health checks performed
7+
8+
To verify that cluster resources are reachable, a TCP connection is made to each of the following cluster API services:
9+
10+
* Kubernetes API server service
11+
* Kubernetes API server endpoints
12+
* OpenShift API server service
13+
* OpenShift API server endpoints
14+
* Load balancers
15+
16+
To verify that services and service endpoints are reachable on every node in the cluster, a TCP connection is made to each of the following targets:
17+
18+
* Health check target service
19+
* Health check target endpoints
Lines changed: 14 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,14 @@
1+
// Module included in the following assemblies:
2+
//
3+
// * networking/verifying-connectivity-endpoint.adoc
4+
5+
[id="nw-pod-network-connectivity-implementation_{context}"]
6+
= Implementation of connection health checks
7+
8+
The connectivity check controller orchestrates connection verification checks in your cluster. The results for the connection tests are stored in `PodNetworkConnectivity` objects in the `openshift-network-diagnostics` namespace. Connection tests are performed every minute in parallel.
9+
10+
The Cluster Network Operator (CNO) deploys several resources to the cluster to send and receive connectivity health checks:
11+
12+
Health check source:: This program deploys in a single pod replica set managed by a `Deployment` object. The program consumes `PodNetworkConnectivity` objects and connects to the `spec.targetEndpoint` specified in each object.
13+
14+
Health check target:: A pod deployed as part of a daemon set on every node in the cluster. The pod listens for inbound health checks. The presence of this pod on every node allows for the testing of connectivity to each node.

0 commit comments

Comments
 (0)