Skip to content

Commit f9b2fd8

Browse files
authored
Merge pull request #465 from droot/book/status-subresource-docs
book: added docs for status subresource
2 parents 29907a2 + a14e053 commit f9b2fd8

File tree

2 files changed

+126
-0
lines changed

2 files changed

+126
-0
lines changed

docs/book/SUMMARY.md

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -17,6 +17,7 @@
1717
* Resources
1818
* [What is a Resource](basics/what_is_a_resource.md)
1919
* [Resource Example](basics/simple_resource.md)
20+
* [Status Subresource](basics/status_subresource.md)
2021
* Controllers
2122
* [What is a Controller](basics/what_is_a_controller.md)
2223
* [Controller Example](basics/simple_controller.md)
Lines changed: 125 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,125 @@
1+
# Status Subresource
2+
By convention, the Kubernetes API makes a distinction between the specification
3+
of the desired state of an object (a nested object field called "spec") and the
4+
status of the object at the current time (a nested object field called "status").
5+
The specification is a complete description of the desired state, including
6+
configuration settings provided by the user, default values expanded by the
7+
system, and properties initialized or otherwise changed after creation by other
8+
ecosystem components (e.g., schedulers, auto-scalers), and is persisted in Etcd
9+
with the API object. The status summarizes the current state of the object in
10+
the system, and is usually persisted with the object by an automated processes
11+
but may be generated on the fly. At some cost and perhaps some temporary
12+
degradation in behavior, the status could be reconstructed by observation if it
13+
were lost.
14+
15+
The PUT and POST verbs on objects MUST ignore the "status" values, to avoid
16+
accidentally overwriting the status in read-modify-write scenarios. A /status
17+
subresource MUST be provided to enable system components to update statuses of
18+
resources they manage.
19+
20+
You can read more about the API convention in [Kubernetes API Convention
21+
doc](https://github.com/kubernetes/community/blob/master/contributors/devel/api-conventions.md#spec-and-status).
22+
23+
{% panel style="info", title="Status subresource support in Kubernetes" %}
24+
Subresource support for CRD is enabled by default in 1.10+ releases
25+
, so ensure that you are running kubernetes with the minimum version. You can
26+
use `kubectl version` command to check the Kubernetes version.
27+
{% endpanel %}
28+
29+
{% method %}
30+
## Enabling Status subresource in CRD definition
31+
First step is to enable status subresource in the CRD definition. This can be
32+
achieved by adding a comment `// +kubebuilder:subresource:status` just above the
33+
Go type definition as shown in example below.
34+
35+
36+
{% sample lang="go" %}
37+
```Go
38+
// MySQL is the Schema for the mysqls API
39+
// +k8s:openapi-gen=true
40+
// +kubebuilder:subresource:status
41+
type MySQL struct {
42+
metav1.TypeMeta `json:",inline"`
43+
metav1.ObjectMeta `json:"metadata,omitempty"`
44+
45+
Spec MySQLSpec `json:"spec,omitempty"`
46+
Status MySQLStatus `json:"status,omitempty"`
47+
}
48+
```
49+
50+
CRD generation tool will use the `+kubebuilder:subresource:status` annotation to
51+
enable status subresource in the CRD definition. So, if you run, `make manifests`,
52+
it will regenerate the CRD manifests under `config/crds/<kind_types.yaml`. Here
53+
is an example manifests with status subresource enabled. Note the `subresources`
54+
section with an empty `status` field.
55+
56+
```yaml
57+
apiVersion: apiextensions.k8s.io/v1beta1
58+
kind: CustomResourceDefinition
59+
metadata:
60+
creationTimestamp: null
61+
labels:
62+
controller-tools.k8s.io: "1.0"
63+
name: mysqls.myapps.examples.org
64+
spec:
65+
group: myapps.examples.org
66+
names:
67+
kind: MySQL
68+
plural: mysqls
69+
scope: Namespaced
70+
subresources:
71+
status: {}
72+
validation:
73+
openAPIV3Schema:
74+
properties:
75+
apiVersion:
76+
type: string
77+
kind:
78+
type: string
79+
metadata:
80+
type: object
81+
spec:
82+
type: object
83+
status:
84+
type: object
85+
version: v1
86+
status:
87+
acceptedNames:
88+
kind: ""
89+
plural: ""
90+
conditions: []
91+
storedVersions: []
92+
```
93+
94+
Ensure you have updated the CRD definition in your cluster by running `kubectl
95+
apply -f config/crds`
96+
97+
{% endmethod %}
98+
99+
{% method %}
100+
## Getting and Updating status in Reconciler code
101+
102+
In order to get the status subresource, you don't have do anything new. The
103+
`Get` client method returns the entire object which contains the status field.
104+
105+
For updating the status subresource, compute the new status value and update it
106+
in the object and then issue `client.Status().Update(context.Background(), &obj)` to update the
107+
status.
108+
109+
{% sample lang="go" %}
110+
```go
111+
instance := &myappsv1.MySQL{}
112+
err := r.Get(context.TODO(), request.NamespacedName, instance)
113+
if err != nil {
114+
// handle err
115+
}
116+
117+
// updating the status
118+
instance.Status.SomeField = "new-value"
119+
err = r.Status().Update(context.Background(), instance)
120+
if err != nil {
121+
return reconcile.Result{}, err
122+
}
123+
```
124+
125+
{% endmethod %}

0 commit comments

Comments
 (0)