Kubernetes Spec / Status - CRD 와 Operator 개발 中

Operator에서 Controller를 만들 때, 해당 리소스의 status, spec 을 명시해주어야만 한다.

• spec 은 말 그대로 해당 리소스의 스펙을 의미해서 별로 헷갈리는게 없었는데, status 는 뭐지 하는 생각과 동시에 spec 도 해당 리소스의 스펙이라지만 어떻게 되는거지 라는 생각이 겹쳐져 전체가 헷갈리게 되버렸다.

 

---

TL;DR

• spec: 원하는 상태(desired state)를 의미
• status: 현재 상태(current state)를 의미

spec, status 가 다르다면, 쿠버네티스 시스템/Operator 등을 통해 status를 spec에 맞게 변경해나가게 된다.

 

단순히 보면 spec과 status가 같은 값을 가지고 status를 spec으로 맞춰주겠구나 할 수 있지만, 꼭 그런 것만은 아니다.

- 여러가지 Operator를 보면 status를 현재 상태를 나타내는 필드의 값으로만 활용하는 경우도 있다. (어떠한 상태 값의 단일 진실의 원천 개념으로 활용)

---

 

쿠버네티스 공식문서에는 아래와 같이 나와있다. (쿠버네티스 오브젝트 이해하기)

오브젝트 명세(spec)와 상태(status)

거의 모든 쿠버네티스 오브젝트는 오브젝트의 구성을 결정해주는 두 개의 중첩된 오브젝트 필드를 포함하는데 오브젝트 spec 과 오브젝트 status 이다.

spec을 가진 오브젝트는 오브젝트를 생성할 때 리소스에 원하는 특징(의도한 상태)에 대한 설명을 제공해서 설정한다.

status 는 쿠버네티스 시스템과 컴포넌트에 의해 제공되고 업데이트된 오브젝트의 현재 상태 를 설명한다. 쿠버네티스 컨트롤 플레인은 모든 오브젝트의 실제 상태를 사용자가 의도한 상태와 일치시키기 위해 끊임없이 그리고 능동적으로 관리한다.

예를 들어, 쿠버네티스 디플로이먼트는 클러스터에서 동작하는 애플리케이션을 표현해줄 수 있는 오브젝트이다. 디플로이먼트를 생성할 때, 디플로이먼트 spec에 3개의 애플리케이션 레플리카가 동작되도록 설정할 수 있다. 쿠버네티스 시스템은 그 디플로이먼트 spec을 읽어 spec에 일치되도록 상태를 업데이트하여 3개의 의도한 애플리케이션 인스턴스를 구동시킨다. 만약, 그 인스턴스들 중 어느 하나가 어떤 문제로 인해 멈춘다면(상태 변화 발생), 쿠버네티스 시스템은 보정(이 경우에는 대체 인스턴스를 시작하여)을 통해 spec과 status간의 차이에 대응한다.

 

 

스택오버플로에도 비슷한 질문과 괜찮은 답변이 있다. (What is the use for CRD status?)

While the spec defines the desired state of that particular resource, basically I declare what I want, the status instead explains the current situation of the resource I declared on the cluster and should help in understanding what is different between the desired state and the actual state.

Like a StatefulSet spec could say I want 3 replicas and its status say that right now only 1 of those replicas is ready and the next one is still starting, a custom resource status may tell me what is the current situation of whatever I declared in the specs.

 

 

Kubernetes community github 에도 관련된 내용이 있다. (community/api-conventions.md at master · kubernetes/community)

By convention, the Kubernetes API makes a distinction between the specification of the desired state of an object (a nested object field called "spec") and the status of the object at the current time (a nested object field called "status").

The specification is a complete description of the desired state, including configuration settings provided by the user, default values expanded by the system, and properties initialized or otherwise changed after creation by other ecosystem components (e.g., schedulers, auto-scalers), and is persisted in stable storage with the API object. If the specification is deleted, the object will be purged from the system.

The status summarizes the current state of the object in the system, and is usually persisted with the object by automated processes but may be generated on the fly. At some cost and perhaps some temporary degradation in behavior, the status could be reconstructed by observation if it were lost.

When a new version of an object is POSTed or PUT, the "spec" is updated and available immediately. Over time the system will work to bring the "status" into line with the "spec". The system will drive toward the most recent "spec" regardless of previous versions of that stanza. In other words, if a value is changed from 2 to 5 in one PUT and then back down to 3 in another PUT the system is not required to 'touch base' at 5 before changing the "status" to 3. In other words, the system's behavior is level-based rather than edge-based. This enables robust behavior in the presence of missed intermediate state changes.