48.c

PR # 1209

kubecfg -c option should let me specify a URL

Why

The kubecfg -c option is used to pass a file pointer to a representation of a model object on disk (pod, replicationController, service) for use by the operation.

It would be nice if I could do the following:

$ kubecfg -c "http://kubernetes-tutorials.com/tutorial1/pod.json"
$ kubecfg -c "http://mybuild-server.com/replicationController.json"

Where kubecfg sees the http:// and does a network operation to fetch resource for me.

This would let users who want to build tutorials on how to use kubernetes to avoid steps to manually download the files locally via curl and unzip, etc. and would also let scripters that use the kubecfg client to avoid needing write access on the terminal where they run kubecfg to perform basic actions.

How

PR # 1133

Add option to enable a simple CORS implementation for the api server

Why

Add option to enable a simple CORS implementation for the api server

背景：

CORS 是跨来源资源共享（Cross-Origin Resource Sharing）的缩写，是一种安全机制，用于控制位于不同源（origin）的网页如何请求另一个源的资源。这在现代的网页开发中是非常重要的，因为网页通常需要从不同的来源加载资源，例如脚本、图片、样式表和其他资源。

举个例子，假设你的网页位于 http://example.com，并且你想通过 AJAX 请求 http://api.example.com 上的数据。由于这两个 URL 有不同的源（不同的域名），因此浏览器的同源策略（same-origin policy）会阻止这种请求。CORS 是一种解决这个问题的方法。

CORS 的工作原理如下：

1. 预检请求（Preflight Request）: 在发送实际请求之前，浏览器会向目标服务器发送一个 OPTIONS 请求，询问它是否允许来自源网站的跨源请求。

2. 服务器响应: 目标服务器会通过响应头告诉浏览器它允许的操作。这些响应头包括：

• Access-Control-Allow-Origin: 指定允许访问的源，可以是具体的源，或者 * 表示允许任何源。
• Access-Control-Allow-Methods: 指定允许的 HTTP 方法（如 GET, POST）。
• Access-Control-Allow-Headers: 指定允许的请求头字段。
• Access-Control-Max-Age: 指定预检请求的结果可以被缓存多久。

3. 实际请求和响应: 如果预检请求通过，浏览器将发送实际的请求。目标服务器再次通过响应头告诉浏览器允许的操作。

4. 浏览器处理: 浏览器接收到服务器的响应后，根据响应头中的 CORS 配置，决定是否允许网页接收和处理响应。

通过这个过程，CORS 允许开发人员细致地控制不同源之间的资源共享。这对于保护用户的安全和数据隐私是非常重要的。同时，它也允许开发人员构建更加复杂和功能丰富的网页应用，通过从多个源加载和利用资源。

How

// Simple CORS implementation that wraps an http Handler
// For a more detailed implementation use https://github.com/martini-contrib/cors
// or implement CORS at your proxy layer
// Pass nil for allowedMethods and allowedHeaders to use the defaults
func CORS(handler http.Handler, allowedOriginPatterns []*regexp.Regexp, allowedMethods []string, allowedHeaders []string, allowCredentials string) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, req *http.Request) {
        origin := req.Header.Get("Origin")
        if origin != "" {
            allowed := false
            for _, pattern := range allowedOriginPatterns {
                if allowed = pattern.MatchString(origin); allowed {
                    break
                }
            }
            if allowed {
                w.Header().Set("Access-Control-Allow-Origin", origin)
                // Set defaults for methods and headers if nothing was passed
                if allowedMethods == nil {
                    allowedMethods = []string{"POST", "GET", "OPTIONS", "PUT", "DELETE"}
                }
                if allowedHeaders == nil {
                    allowedHeaders = []string{"Content-Type", "Content-Length", "Accept-Encoding", "X-CSRF-Token", "Authorization", "X-Requested-With", "If-Modified-Since"}
                }
                w.Header().Set("Access-Control-Allow-Methods", strings.Join(allowedMethods, ", "))
                w.Header().Set("Access-Control-Allow-Headers", strings.Join(allowedHeaders, ", "))
                w.Header().Set("Access-Control-Allow-Credentials", allowCredentials)

                // Stop here if its a preflight OPTIONS request
                if req.Method == "OPTIONS" {
                    w.WriteHeader(http.StatusNoContent)
                    return
                }
            }
        }
        // Dispatch to the next handler
        handler.ServeHTTP(w, req)
    })
}

PR #1268

Proposed ContainerStatus for each individual Container in a Pod.

Why

docker 现在可以报告更多详细的状态，State.Running, State.Paused, State.ExitCode (negative for signals IIRC), and State.FinishedAt。但是目前我们没法查看 pod 中具体容器的状态。

比如我们要实现一些查看操作

1. 使用 kubectl describe 命令查看详细信息

如果你需要查看 Pod 中容器的详细状态，可以使用 kubectl describe 命令。这个命令会给你一个详细的报告，包括每个容器的状态。在输出的报告中，找到 “Containers” 部分，你会看到每个容器的状态，包括是否正在运行，是否已经重启，等等。

kubectl describe pod <pod-name>

2. 使用 kubectl get 命令并输出为 JSON 格式:

这种方法允许你以 JSON 格式获取 Pod 的状态，并使用 jq 命令 (需要单独安装) 来解析输出。这个命令将会输出一个 JSON 数组，包含 Pod 中每个容器的状态信息。

kubectl get pod <pod-name> -o json | jq '.status.containerStatuses'

How

在我们的 api 目录中 定义 containerStatus 结构体

type ContainerStateWaiting struct {
    // Reason could be pulling image,
    Reason string `json:"reason,omitempty" yaml:"reason,omitempty"`
}

type ContainerStateRunning struct {
}

type ContainerStateTerminated struct {
    ExitCode int    `json:"exitCode,omitempty" yaml:"exitCode,omitempty"`
    Signal   int    `json:"signal,omitempty" yaml:"signal,omitempty"`
    Reason   string `json:"reason,omitempty" yaml:"reason,omitempty"`
}

type ContainerState struct {
    // Only one of the following ContainerState may be specified.
    // If none of them is specified, the default one is ContainerStateWaiting.
    Waiting     *ContainerStateWaiting    `json:"waiting,omitempty" yaml:"waiting,omitempty"`
    Running     *ContainerStateRunning    `json:"running,omitempty" yaml:"running,omitempty"`
    Termination *ContainerStateTerminated `json:"termination,omitempty" yaml:"termination,omitempty"`
}

type ContainerStatus struct {
    // TODO(dchen1107): Should we rename PodStatus to a more generic name or have a separate states
    // defined for container?
    State        ContainerState `json:"state,omitempty" yaml:"state,omitempty"`
    RestartCount int            `json:"restartCount" yaml:"restartCount"`
    // TODO(dchen1107): Introduce our own NetworkSettings struct here?
    // TODO(dchen1107): Once we have done with integration with cadvisor, resource
    // usage should be included.
    // TODO(dchen1107):  In long run, I think we should replace this with our own struct to remove
    // the dependency on docker.
    DetailInfo docker.Container `json:"detailInfo,omitempty" yaml:"detailInfo,omitempty"`
}

PR #1218

Authenticated docker pulls, pt. I

Why

Docker 现在没法拉取私有仓库的镜像。这里最简单的合理做法是读取 kubelet 已经可用的 .dockercfg 个文件。这仅在启动时发生，因此用户对 .dockercfg 所做的任何更改将仅在服务重新启动后应用。 这里的下一个合乎逻辑的步骤是将 docker 凭据的管理转移到 etcd 中。对此有什么想法吗？

How