* Sessions are stored in memory with automatic expiration.
 *
 * <p><b>Note:</b> Sessions are stored in a local in-memory ConcurrentHashMap.
 * In multi-instance deployments (e.g., behind a load balancer), sessions are
 * not shared between instances. Use sticky sessions or an external session
 * store if session affinity across instances is required.</p>
 *
 * @author FessProject
 */
public class ChatSessionManager {

- Add cluster name to load balancer description
- Add synchronization between Kubernetes and Keystone projects
- Add use internal DNS name for 'hostname' of nodes.
- Add support for CSI spec v0.3.0 for both Cinder and Manilla
- Add 'cascade delete' support for Octavia load balancers to improve performance.
- Add improved load balancer naming.

### SIG-scheduling

- Fixed two scheduler metrics...

在這些情況下，你大概會想要如[上面所述](#dockerfile)從零開始建置一個 Docker 映像，安裝你的相依，並且只執行「單一 Uvicorn 行程」，而不是使用多個 Uvicorn workers。

### 負載平衡器 { #load-balancer }

使用容器時，通常會有某個元件在「主埠口」上監聽。它也可能是另一個同時做為「TLS 終止代理」的容器來處理「HTTPS」，或類似的工具。

由於這個元件會承接請求的「負載」，並將其分配給 workers，使其（希望）「平衡」，因此也常被稱為「負載平衡器（Load Balancer）」。

/// tip | 提示

用於 HTTPS 的同一個「TLS 終止代理」元件通常也會是「負載平衡器」。

///

그런 경우에는 [위에서 설명한 대로](#dockerfile) 의존성을 설치하고, 여러 Uvicorn 워커를 사용하는 대신 **단일 Uvicorn 프로세스**를 실행하는 **처음부터 만든 Docker 이미지**를 사용하는 것이 좋을 것입니다.

### 로드 밸런서 { #load-balancer }

컨테이너를 사용할 때는 보통 **메인 포트에서 대기(listening)하는** 컴포넌트가 있습니다. **HTTPS**를 처리하기 위한 **TLS 종료 프록시** 역할을 하는 다른 컨테이너일 수도 있고, 유사한 도구일 수도 있습니다.

이 컴포넌트가 요청의 **부하(load)**를 받아 워커들에 (가능하면) **균형 있게** 분산한다면, 보통 **로드 밸런서**라고 부릅니다.

* Fix load balancer issues when running zero nodes in Azure vmss. ([#68775](https://github.com/kubernetes/kubernetes/pull/68775), [@feiskyer](https://github.com/feiskyer))
* Fix potential panic when getting azure load balancer status ([#68609](https://github.com/kubernetes/kubernetes/pull/68609), [@feiskyer](https://github.com/feiskyer))

* Ensure ownership when deleting a load balancer security group ([#74311](https://github.com/kubernetes/kubernetes/pull/74311), [@hpedrorodrigues](https://github.com/hpedrorodrigues))
* kubelet: updated logic of verifying a static critical pod. ([#75144](https://github.com/kubernetes/kubernetes/pull/75144), [@Huang-Wei](https://github.com/Huang-Wei))

* Allow disable outbound SNAT when Azure standard load balancer is used together with outbound rules.  ([#75282](https://github.com/kubernetes/kubernetes/pull/75282), [@feiskyer](https://github.com/feiskyer))

### 프록시 전달 헤더가 동작하는 방식 { #how-proxy-forwarded-headers-work }

다음은 **프록시**가 클라이언트와 **애플리케이션 서버** 사이에서 전달 헤더를 추가하는 과정을 시각적으로 나타낸 것입니다:

```mermaid
sequenceDiagram
    participant Client
    participant Proxy as Proxy/Load Balancer
    participant Server as FastAPI Server

    Client->>Proxy: HTTPS Request<br/>Host: mysuperapp.com<br/>Path: /items

    Note over Proxy: Proxy adds forwarded headers

Here's a visual representation of how the **proxy** adds forwarded headers between the client and the **application server**:

```mermaid
sequenceDiagram
    participant Client
    participant Proxy as Proxy/Load Balancer
    participant Server as FastAPI Server

    Client->>Proxy: HTTPS Request<br/>Host: mysuperapp.com<br/>Path: /items

    Note over Proxy: Proxy adds forwarded headers