圖解kubernetes命令執行核心實現

K8s中的命令執行由apiserver、kubelet、cri、docker等組件共同完成, 其中最複雜的就是協議切換以及各種流拷貝相關,讓我們一起來看下關鍵實現,雖然代碼比較多，但是不會開發應該也能看懂，祝你好運

1. 基礎概念

K8s中的命令執行中有很多協議相關的處理, 我們先一起看下這些協議處理相關的基礎概念

1.1 Http協議中的Connection與Upgrade

HTTP/1.1中允許在同一個鏈接上通過Header頭中的Connection配合Upgrade來實現協議的轉換，簡單來說就是允許在通過HTTP建立的鏈接之上使用其他的協議來進行通信，這也是k8s中命令中實現協議升級的關鍵

1.2 Http協議中的101狀態碼

在HTTP協議中除了我們常見的HTTP1.1,還支持websocket/spdy等協議,那服務端和客戶端如何在http之上完成不同協議的切換呢，首先第一個要素就是這裏的101(Switching Protocal)狀態碼, 即服務端告知客戶端我們切換到Uprage定義的協議上來進行通信(複用當前鏈接)

1.3 SPDY協議中的stream

SPDY協議是google開發的TCP會話層協議, SPDY協議中將Http的Request/Response稱爲Stream，並支持TCP的鏈接複用，同時多個stream之間通過Stream-id來進行標記，簡單來說就是支持在單個鏈接同時進行多個請求響應的處理，並且互不影響，k8s中的命令執行主要也就是通過stream來進行消息傳遞的

1.4 文件描述符重定向

在Linux中進程執行通常都會包含三個FD：標準輸入、標準輸出、標準錯誤, k8s中的命令執行會將對應的FD進行重定向，從而獲取容器的命令的輸出，重定向到哪呢？當然是我們上面提到過的stream了(因爲對docker並不熟悉,所以這個地方並不保證Docker部分的準確性)

1.5 http中的Hijacker

在client與server之間通過101狀態碼、connection、upragde等完成基於當前鏈接的轉換之後, 當前鏈接上傳輸的數據就不在是之前的http1.1協議了，此時就要將對應的http鏈接轉成對應的協議進行轉換，在k8s命令執行的過程中，會獲取將對應的request和response，都通過http的Hijacker接口獲取底層的tcp鏈接，從而繼續完成請求的轉發

1.6 基於tcp的流對拷的轉發

在通過Hijacker獲取到兩個底層的tcp的readerwriter之後，就可以直接通過io.copy在兩個流上完成對應數據的拷貝，這樣就不需要在apiserver這個地方進行協議的轉換，而是直接通過tcp的流對拷就可以實現請求和結果的轉發

基礎大概就介紹這些，接下來我們一起去看看其底層的具體實現，我們從kubectl部分開始來逐層分析

2.kubectl

Kubectl執行命令主要分爲兩部分Pod合法性檢測和命令執行, Pod合法性檢測主要是獲取對應Pod的狀態,檢測是否在運行, 這裏我們重點關注下命令執行部分

2.1 命令執行核心流程

命令執行的核心分爲兩個步驟：1.通過SPDY協議建立鏈接 2）構建Stream建立鏈接

func (*DefaultRemoteExecutor) Execute(method string, url *url.URL, config *restclient.Config, stdin io.Reader, stdout, stderr io.Writer, tty bool, terminalSizeQueue remotecommand.TerminalSizeQueue) error {
    exec, err := remotecommand.NewSPDYExecutor(config, method, url)
    if err != nil {
        return err
    }
    return exec.Stream(remotecommand.StreamOptions{
        Stdin:             stdin,
        Stdout:            stdout,
        Stderr:            stderr,
        Tty:               tty,
        TerminalSizeQueue: terminalSizeQueue,
    })
}

2.2 exec請求構建

我們可以看到這個地方拼接的Url /pods/{namespace}/{podName}/exec其實就是對應apiserver上面pod的subresource接口，然後我們就可以去看apiserver端的請求處理了

    // 創建一個exec
        req := restClient.Post().
            Resource("pods").
            Name(pod.Name).
            Namespace(pod.Namespace).
            SubResource("exec")
        req.VersionedParams(&corev1.PodExecOptions{
            Container: containerName,
            Command:   p.Command,
            Stdin:     p.Stdin,
            Stdout:    p.Out != nil,
            Stderr:    p.ErrOut != nil,
            TTY:       t.Raw,
        }, scheme.ParameterCodec)
return p.Executor.Execute("POST", req.URL(), p.Config, p.In, p.Out, p.ErrOut, t.Raw, sizeQueue)

2.3 建立Stream

在exec.Stream主要是通過Headers傳遞要建立的Stream的類型，與server端進行協商

    // set up stdin stream
    if p.Stdin != nil {
        headers.Set(v1.StreamType, v1.StreamTypeStdin)
        p.remoteStdin, err = conn.CreateStream(headers)
        if err != nil {
            return err
        }
    }

    // set up stdout stream
    if p.Stdout != nil {
        headers.Set(v1.StreamType, v1.StreamTypeStdout)
        p.remoteStdout, err = conn.CreateStream(headers)
        if err != nil {
            return err
        }
    }

    // set up stderr stream
    if p.Stderr != nil && !p.Tty {
        headers.Set(v1.StreamType, v1.StreamTypeStderr)
        p.remoteStderr, err = conn.CreateStream(headers)
        if err != nil {
            return err
        }
    }

3.APIServer

APIServer在命令執行的過程中扮演了代理的角色，其負責將Kubectl和kubelet之間的請求來進行轉發，注意這個轉發主要是基於tcp的流對拷完成的，因爲kubectl和kubelet之間的通信，實際上是spdy協議，讓我們一起看下關鍵實現吧

3.1 Connection

Exec的SPDY請求會首先發送到Connect接口, Connection接口負責跟後端的kubelet進行鏈接的建立，並且進行響應結果的返回，在Connection接口中，首先會通過Pod獲取到對應的Node信息，並且構建Location即後端的Kubelet的鏈接地址和transport

func (r *ExecREST) Connect(ctx context.Context, name string, opts runtime.Object, responder rest.Responder) (http.Handler, error) {
    execOpts, ok := opts.(*api.PodExecOptions)
    if !ok {
        return nil, fmt.Errorf("invalid options object: %#v", opts)
    }
    // 返回對應的地址，以及建立鏈接
    location, transport, err := pod.ExecLocation(r.Store, r.KubeletConn, ctx, name, execOpts)
    if err != nil {
        return nil, err
    }
    return newThrottledUpgradeAwareProxyHandler(location, transport, false, true, true, responder), nil
}

3.2 獲取後端服務地址

在獲取地址主要是構建後端的location信息，這裏會通過kubelet上報來的信息獲取到對應的node的host和Port信息，並且拼裝出pod的最終指向路徑即這裏的Path字段/exec/{namespace}/{podName}/{containerName}

    loc := &url.URL{
        Scheme:   nodeInfo.Scheme,
        Host:     net.JoinHostPort(nodeInfo.Hostname, nodeInfo.Port),   // node的端口
        Path:     fmt.Sprintf("/%s/%s/%s/%s", path, pod.Namespace, pod.Name, container),    // 路徑
        RawQuery: params.Encode(),
    }

3.3 協議提升handler初始化

協議提升主要是通過UpgradeAwareHandler控制器進行實現, 該handler接收到請求之後會首先嚐試進行協議提升，其主要是檢測http頭裏面的Connection的值是不是Upragde來實現， 從之前kubelet的分析中可以知道這裏肯定是true

func newThrottledUpgradeAwareProxyHandler(location *url.URL, transport http.RoundTripper, wrapTransport, upgradeRequired, interceptRedirects bool, responder rest.Responder) *proxy.UpgradeAwareHandler {

    handler := proxy.NewUpgradeAwareHandler(location, transport, wrapTransport, upgradeRequired, proxy.NewErrorResponder(responder))
    handler.InterceptRedirects = interceptRedirects && utilfeature.DefaultFeatureGate.Enabled(genericfeatures.StreamingProxyRedirects)
    handler.RequireSameHostRedirects = utilfeature.DefaultFeatureGate.Enabled(genericfeatures.ValidateProxyRedirects)
    handler.MaxBytesPerSec = capabilities.Get().PerConnectionBandwidthLimitBytesPerSec
    return handler
}

func (h *UpgradeAwareHandler) ServeHTTP(w http.ResponseWriter, req *http.Request) {
    // 如果協議提升成功，則由該協議完成
    if h.tryUpgrade(w, req) {
        return
    }
    // 省略N多代碼
}

3.4 協議提升處理

協議提升處理的邏輯比較多，這裏分爲幾個小節來進行依次說明, 主要是先從HTTP鏈接中獲取請求，並進行轉發，然後同時持有兩個鏈接，並且在鏈接上進行TCP流的拷貝

3.4.1 與kubelet建立鏈接

協議提升的第一步就是與後端的kubelet建立鏈接了，這裏會將kubelet發過來的請求進行拷貝，並且發送給後端的kubelet, 並且這裏也會獲取到一個與kubelet建立的http的鏈接，後面進行流對拷的時候需要用到, 注意實際上這個http請求響應的狀態碼，是101，即kubelet上實際上是構建了一個spdy協議的handler來進行通信的

        // 構建http請求
        req, err := http.NewRequest(method, location.String(), body)
        if err != nil {
            return nil, nil, err
        }

        req.Header = header

        // 發送請求建立鏈接
        intermediateConn, err = dialer.Dial(req)
        if err != nil {
            return nil, nil, err
        }

        // Peek at the backend response.
        rawResponse.Reset()
        respReader := bufio.NewReader(io.TeeReader(
            io.LimitReader(intermediateConn, maxResponseSize), // Don't read more than maxResponseSize bytes.
            rawResponse)) // Save the raw response.
            // 讀取響應信息
        resp, err := http.ReadResponse(respReader, nil)

3.4.2 Request請求的Hijack

這個請求實際上是spdy協議的，在通過Hijack獲取到底層的鏈接之後，需要先將上面的請求轉發給kubelet從而觸發kubelet發送後面的Stream請求建立鏈接，就是這裏的Write將kubelet的結果轉發

    requestHijackedConn, _, err := requestHijacker.Hijack()
    // Forward raw response bytes back to client.
    if len(rawResponse) > 0 {
        klog.V(6).Infof("Writing %d bytes to hijacked connection", len(rawResponse))
        if _, err = requestHijackedConn.Write(rawResponse); err != nil {
            utilruntime.HandleError(fmt.Errorf("Error proxying response from backend to client: %v", err))
        }
    }

3.4.3 雙向流對拷

經過上面的兩步操作，apiserver上就擁有來了兩個http鏈接，因爲協議不是http的所以apiserver不能直接進行操作，而只能採用流對拷的方式來進行請求和響應的轉發

    // 雙向拷貝鏈接
    go func() {
        var writer io.WriteCloser
        if h.MaxBytesPerSec > 0 {
            writer = flowrate.NewWriter(backendConn, h.MaxBytesPerSec)
        } else {
            writer = backendConn
        }
        _, err := io.Copy(writer, requestHijackedConn)
        if err != nil && !strings.Contains(err.Error(), "use of closed network connection") {
            klog.Errorf("Error proxying data from client to backend: %v", err)
        }
        close(writerComplete)
    }()

    go func() {
        var reader io.ReadCloser
        if h.MaxBytesPerSec > 0 {
            reader = flowrate.NewReader(backendConn, h.MaxBytesPerSec)
        } else {
            reader = backendConn
        }
        _, err := io.Copy(requestHijackedConn, reader)
        if err != nil && !strings.Contains(err.Error(), "use of closed network connection") {
            klog.Errorf("Error proxying data from backend to client: %v", err)
        }
        close(readerComplete)
    }()

4.kubelet

Kubelet上的命令執行主要是依賴於CRI.RuntimeService來執行的，kubelet只負責對應請求的轉發，並最終構建一個轉發後續請求的Stream代理，就完成了他的使命

4.1 執行命令主流程

主流程主要是獲取要執行的命令，然後檢測對應的Pod新，並調用host.GetExec返回一個對應的URL，然後後續的請求就由proxyStream來完成， 我們一步步開始深入

func (s *Server) getExec(request *restful.Request, response *restful.Response) {
    // 獲取執行命令
    params := getExecRequestParams(request)
    streamOpts, err := remotecommandserver.NewOptions(request.Request)
    // 獲取pod的信息
    pod, ok := s.host.GetPodByName(params.podNamespace, params.podName)
    podFullName := kubecontainer.GetPodFullName(pod)
    url, err := s.host.GetExec(podFullName, params.podUID, params.containerName, params.cmd, *streamOpts)
    proxyStream(response.ResponseWriter, request.Request, url)
}

4.2 Exec返回執行結果

host.GetExec最終會調用到runtimeService即cri.RuntimeService的Exec接口來進行請求的執行，該接口會返回一個地址即/exec/{token},此時並沒有執行真正的命令只是創建了一個命令執行請求而已

func (m *kubeGenericRuntimeManager) GetExec(id kubecontainer.ContainerID, cmd []string, stdin, stdout, stderr, tty bool) (*url.URL, error) {
    // 省略請求構造
    // 執行命令
    resp, err := m.runtimeService.Exec(req)
    return url.Parse(resp.Url)
}

最終其實就是調用cri的的exec接口, 我們先忽略該接口具體返回的啥，將kubelet剩餘的邏輯看完

func (c *runtimeServiceClient) Exec(ctx context.Context, in *ExecRequest, opts ...grpc.CallOption) (*ExecResponse, error) {
    err := c.cc.Invoke(ctx, "/runtime.v1alpha2.RuntimeService/Exec", in, out, opts...)
}

4.3 proxyStream

這裏我們可以發現，又是我們之前見過的UpgradeAwareHandler，不過這次的url是後端exec執行返回的url了，然後剩下部分就跟apiserver裏面的差不多，在兩個http鏈接之間進行流對拷

我們想一下這個地方Request和Response,其實是對應的apiserver與kubelet建立的鏈接，這個鏈接上是spdy的頭，記住這個地方， 則此時又跟後端繼續建立鏈接，後端其實也是一個spdy協議的server, 至此我們還差最後一個部分就是返回的那個鏈接到底是啥，對應的控制器又是誰，進行下一節cri部分

// proxyStream proxies stream to url.
func proxyStream(w http.ResponseWriter, r *http.Request, url *url.URL) {
    // TODO(random-liu): Set MaxBytesPerSec to throttle the stream.
    handler := proxy.NewUpgradeAwareHandler(url, nil /*transport*/, false /*wrapTransport*/, true /*upgradeRequired*/, &responder{})
    handler.ServeHTTP(w, r)
}

5.CRI

CRI.RuntimeService負責最終的命令執行，也是命令執行真正執行的位置，其中也涉及到很多的協議處理相關的操作，讓我們一起來看下關鍵實現吧

5.1 DockerRuntime的註冊

在上面我們調用了RuntimeService的Exec接口，在kubelet中最終發現如下代碼，創建了一個DockerServer並啓動

ds, err := dockershim.NewDockerService(kubeDeps.DockerClientConfig, crOptions.PodSandboxImage, streamingConfig,
dockerServer := dockerremote.NewDockerServer(remoteRuntimeEndpoint, ds)
        if err := dockerServer.Start(); err != nil {
            return err
        }

其中在Start函數裏面，註冊了下面兩個RuntimeService,寫過grpc的朋友都知道，這個其實就是註冊對應rpc接口的實現，其實最終我們調用的是DockerService的接口

    runtimeapi.RegisterRuntimeServiceServer(s.server, s.service)
    runtimeapi.RegisterImageServiceServer(s.server, s.service)

5.2 DockerService的Exec實現

Exec最終的實現可以發現實際上是調用streamingServer的GetExec接口，返回了一個/exec/{token}的接口

func (ds *dockerService) Exec(_ context.Context, req *runtimeapi.ExecRequest) (*runtimeapi.ExecResponse, error) {
    // 執行Exec請求
    return ds.streamingServer.GetExec(req)
}

我們繼續追蹤streamingServer可以看到GetExec接口實現如下, 最終build了一個url=/exec/{token},注意這裏實際上存儲了當前的Request請求在cache中

func (s *server) GetExec(req *runtimeapi.ExecRequest) (*runtimeapi.ExecResponse, error) {
    // 生成token
    token, err := s.cache.Insert(req)
    return &runtimeapi.ExecResponse{
        Url: s.buildURL("exec", token),
    }, nil
}

5.3 構建命令參數執行Exec

首先通過token來獲取之前緩存的Request，然後通過exec請求命令，構建StreamOpts,並最終調用ServeExec進行執行，接下來就是最不容易看懂的部分了，前方高能

func (s *server) serveExec(req *restful.Request, resp *restful.Response) {
    // 獲取token
    token := req.PathParameter("token")
    // 緩存請求
    cachedRequest, ok := s.cache.Consume(token)
    // 構建exec參數s
    exec, ok := cachedRequest.(*runtimeapi.ExecRequest)

    streamOpts := &remotecommandserver.Options{
        Stdin:  exec.Stdin,
        Stdout: exec.Stdout,
        Stderr: exec.Stderr,
        TTY:    exec.Tty,
    }

    // 構建ServerExec執行請求
    remotecommandserver.ServeExec(
        resp.ResponseWriter,
        req.Request,
        s.runtime,
        "", // unused: podName
        "", // unusued: podUID
        exec.ContainerId,
        exec.Cmd,
        streamOpts,
        s.config.StreamIdleTimeout,
        s.config.StreamCreationTimeout,
        s.config.SupportedRemoteCommandProtocols)
}

5.4 ServerExec

ServerExec關鍵步驟就兩個：1）創建stream 2)執行請求， 比較複雜的主要是集中在創建stream部分，我們注意下ExecInContainer的參數部分，傳入了通過創建流獲取的ctx的相關文件描述符的Stream, createStreams裏面的實現有兩種協議websocket和https,這裏我們主要分析https(我們使用kubectl使用的就是https協議)

func ServeExec(w http.ResponseWriter, req *http.Request, executor Executor, podName string, uid types.UID, container string, cmd []string, streamOpts *Options, idleTimeout, streamCreationTimeout time.Duration, supportedProtocols []string) {
    // 創建serveExec
    ctx, ok := createStreams(req, w, streamOpts, supportedProtocols, idleTimeout, streamCreationTimeout)

    defer ctx.conn.Close()

    // 獲取執行，這是一個阻塞的過程，err會獲取當前的執行是否成功, 這裏將ctx裏面的信息，都傳入進去，對應的其實就是各種流
    err := executor.ExecInContainer(podName, uid, container, cmd, ctx.stdinStream, ctx.stdoutStream, ctx.stderrStream, ctx.tty, ctx.resizeChan, 0)

}

5.5 創建HTTPS Stream

Stream的建立我將其概括成下面幾個步驟：1）進行https的握手 2)協議升級爲spdy 3)等待stream的建立，我們依次來看

1.完成https的握手

protocol, err := httpstream.Handshake(req, w, supportedStreamProtocols)

2.協議提升

    // 流管道
    streamCh := make(chan streamAndReply)

    upgrader := spdy.NewResponseUpgrader()
    // 構建spdy鏈接
    conn := upgrader.UpgradeResponse(w, req, func(stream httpstream.Stream, replySent <-chan struct{}) error {
        // 當新請求建立之後，會追加到streamch
        streamCh <- streamAndReply{Stream: stream, replySent: replySent}
        return nil
    })

這裏有一個關鍵機制就是後面func回調函數的傳遞和streamch的傳遞，這裏建立一個鏈接之後會創建一個Server,並且傳入了一個控制器就是func回調函數，該函數每當建立一個鏈接之後，如果獲取到對應的stream就追加到StreamCh中，下面就是最複雜的網絡處理部分了，因爲太複雜，所以還是單獨開一節吧

5.6 spdy stream的建立

總體流程上看起來簡單，主要是先根據請求來進行協議切換，然後返回101，並且基於當前的鏈接構建SPDY的請求處理，然後等待kubectl通過apiserver發送的需要建立的Stream，就完成了彼此通信流stream的建立

5.6.1 進行協議提升響應

首先第一步會先進行協議提升的響應，這裏我們注意幾個關鍵部分，spdy協議，以及101狀態碼

    // 協議
    hijacker, ok := w.(http.Hijacker)
    if !ok {
        errorMsg := fmt.Sprintf("unable to upgrade: unable to hijack response")
        http.Error(w, errorMsg, http.StatusInternalServerError)
        return nil
    }

    w.Header().Add(httpstream.HeaderConnection, httpstream.HeaderUpgrade)
    // sydy協議
    w.Header().Add(httpstream.HeaderUpgrade, HeaderSpdy31)
    w.WriteHeader(http.StatusSwitchingProtocols)

5.6.2 建立spdyServer

spdyConn, err := NewServerConnection(connWithBuf, newStreamHandler)

最終會通過newConnection負責新鏈接的建立

func NewServerConnection(conn net.Conn, newStreamHandler httpstream.NewStreamHandler) (httpstream.Connection, error) {
    // 創建一個新的鏈接, 通過一個已經存在的網絡鏈接
    spdyConn, err := spdystream.NewConnection(conn, true)

    return newConnection(spdyConn, newStreamHandler), nil
}

這裏我們可以看到是啓動一個後臺的server來進行鏈接請求的處理

func newConnection(conn *spdystream.Connection, newStreamHandler httpstream.NewStreamHandler) httpstream.Connection {
    c := &connection{conn: conn, newStreamHandler: newStreamHandler}
    // 當建立鏈接後，進行syn請求創建流的時候，會調用newSpdyStream
    go conn.Serve(c.newSpdyStream)
    return c
}

5.6.3 Serve

1.首先會啓動多個goroutine來負責請求的處理，這裏的worker數量是5個，隊列大小是20，

frameQueues := make([]*PriorityFrameQueue, FRAME_WORKERS)
    for i := 0; i < FRAME_WORKERS; i++ {
        frameQueues[i] = NewPriorityFrameQueue(QUEUE_SIZE)

        // Ensure frame queue is drained when connection is closed
        go func(frameQueue *PriorityFrameQueue) {
            <-s.closeChan
            frameQueue.Drain()
        }(frameQueues[i])

        wg.Add(1)
        go func(frameQueue *PriorityFrameQueue) {
            // let the WaitGroup know this worker is done
            defer wg.Done()

            s.frameHandler(frameQueue, newHandler)
        }(frameQueues[i])
    }

2.監聽synStreamFrame,分流frame,會按照frame的streamID來進行hash選擇對應的frameQueues隊列

        case *spdy.SynStreamFrame:
            if s.checkStreamFrame(frame) {
                priority = frame.Priority
                partition = int(frame.StreamId % FRAME_WORKERS)
                debugMessage("(%p) Add stream frame: %d ", s, frame.StreamId)
                // 添加到對應的StreamId對應的frame裏面
                s.addStreamFrame(frame)
            } else {
                debugMessage("(%p) Rejected stream frame: %d ", s, frame.StreamId)
                continue

                // 最終會講frame push到上面的優先級隊列裏面
                frameQueues[partition].Push(readFrame, priority)

3.讀取frame進行並把讀取到的stream通過newHandler傳遞給上面的StreamCH

func (s *Connection) frameHandler(frameQueue *PriorityFrameQueue, newHandler StreamHandler) {
    for {
        popFrame := frameQueue.Pop()
        if popFrame == nil {
            return
        }

        var frameErr error
        switch frame := popFrame.(type) {
        case *spdy.SynStreamFrame:
            frameErr = s.handleStreamFrame(frame, newHandler)
    }
}

消費的流到下一節

5.7 等待建立Stream

Stream的等待建立主要是通過Headers裏面的StreamType來實現，這裏面會講對應的stdinStream和對應的spdy裏面的stream綁定，其他類型也是這樣

func (*v3ProtocolHandler) waitForStreams(streams <-chan streamAndReply, expectedStreams int, expired <-chan time.Time) (*context, error) {
    ctx := &context{}
    receivedStreams := 0
    replyChan := make(chan struct{})
    stop := make(chan struct{})
    defer close(stop)
WaitForStreams:
    for {
        select {
        case stream := <-streams:
            streamType := stream.Headers().Get(api.StreamType)
            switch streamType {
            case api.StreamTypeError:
                ctx.writeStatus = v1WriteStatusFunc(stream)
                go waitStreamReply(stream.replySent, replyChan, stop)
            case api.StreamTypeStdin:
                ctx.stdinStream = stream
                go waitStreamReply(stream.replySent, replyChan, stop)
            case api.StreamTypeStdout:
                ctx.stdoutStream = stream
                go waitStreamReply(stream.replySent, replyChan, stop)
            case api.StreamTypeStderr:
                ctx.stderrStream = stream
                go waitStreamReply(stream.replySent, replyChan, stop)
            case api.StreamTypeResize:
                ctx.resizeStream = stream
                go waitStreamReply(stream.replySent, replyChan, stop)
            default:
                runtime.HandleError(fmt.Errorf("unexpected stream type: %q", streamType))
            }
        case <-replyChan:
            receivedStreams++
            if receivedStreams == expectedStreams {
                break WaitForStreams
            }
        case <-expired:
            // TODO find a way to return the error to the user. Maybe use a separate
            // stream to report errors?
            return nil, errors.New("timed out waiting for client to create streams")
        }
    }

    return ctx, nil
}

5.8 CRI適配器執行命令

跟蹤調用鏈最終可以看到如下的調用，最終指向了execHandler.ExecInContainer接口用於在容器中執行命令

func (a *criAdapter) ExecInContainer(podName string, podUID types.UID, container string, cmd []string, in io.Reader, out, err io.WriteCloser, tty bool, resize <-chan remotecommand.TerminalSize, timeout time.Duration) error {
    // 執行command
    return a.Runtime.Exec(container, cmd, in, out, err, tty, resize)
}
func (r *streamingRuntime) Exec(containerID string, cmd []string, in io.Reader, out, err io.WriteCloser, tty bool, resize <-chan remotecommand.TerminalSize) error {
    //  執行容器
    return r.exec(containerID, cmd, in, out, err, tty, resize, 0)
}

// Internal version of Exec adds a timeout.
func (r *streamingRuntime) exec(containerID string, cmd []string, in io.Reader, out, errw io.WriteCloser, tty bool, resize <-chan remotecommand.TerminalSize, timeout time.Duration) error {
    // exechandler
    return r.execHandler.ExecInContainer(r.client, container, cmd, in, out, errw, tty, resize, timeout)
}

5.9 命令執行主流程

命令的指向的主流程主要分爲兩個部分：1）創建exec執行任務 2)啓動exec執行任務

func (*NativeExecHandler) ExecInContainer(client libdocker.Interface, container *dockertypes.ContainerJSON, cmd []string, stdin io.Reader, stdout, stderr io.WriteCloser, tty bool, resize <-chan remotecommand.TerminalSize, timeout time.Duration) error {
    // 在容器中執行命令
    done := make(chan struct{})
    defer close(done)

    // 執行命令
    createOpts := dockertypes.ExecConfig{
        Cmd:          cmd,
        AttachStdin:  stdin != nil,
        AttachStdout: stdout != nil,
        AttachStderr: stderr != nil,
        Tty:          tty,
    }
    // 創建執行命令任務
    execObj, err := client.CreateExec(container.ID, createOpts)

    startOpts := dockertypes.ExecStartCheck{Detach: false, Tty: tty}
    // 這裏我們可以看到我們將前面獲取到的stream的封裝,都作爲FD傳入到容器的執行命令裏面去了
    streamOpts := libdocker.StreamOptions{
        InputStream:  stdin,
        OutputStream: stdout,
        ErrorStream:  stderr,
        RawTerminal:  tty,
        ExecStarted:  execStarted,
    }
    // 執行命令
    err = client.StartExec(execObj.ID, startOpts, streamOpts)

    ticker := time.NewTicker(2 * time.Second)
    defer ticker.Stop()
    count := 0
    for {
        //  獲取執行結果
        inspect, err2 := client.InspectExec(execObj.ID)
        if !inspect.Running {
            if inspect.ExitCode != 0 {
                err = &dockerExitError{inspect}
            }
            break
        }
        <-ticker.C
    }

    return err
}

Docker的命令執行接口調用

func (cli *Client) ContainerExecCreate(ctx context.Context, container string, config types.ExecConfig) (types.IDResponse, error) {
    resp, err := cli.post(ctx, "/containers/"+container+"/exec", nil, config, nil)
    return response, err
}

5.10 命令執行核心實現

命令執行的核心實現主要是兩個步驟：1）首先發送exec執行請求 2）啓動對應的exec並獲取結果， 複雜的還是SPDY相關的Stream的邏輯

func (d *kubeDockerClient) StartExec(startExec string, opts dockertypes.ExecStartCheck, sopts StreamOptions) error {
    // 啓動執行命令, 獲取結果
    resp, err := d.client.ContainerExecAttach(ctx, startExec, dockertypes.ExecStartCheck{
        Detach: opts.Detach,
        Tty:    opts.Tty,
    })
    // 將輸入流拷貝到輸出流， 這裏會講resp裏面的結果拷貝到outputSTream裏面
    return d.holdHijackedConnection(sopts.RawTerminal || opts.Tty, sopts.InputStream, sopts.OutputStream, sopts.ErrorStream, resp)
}

5.10.1 命令執行請求

cli.postHijacked(ctx, "/exec/"+execID+"/start", nil, config, headers)

5.10.2 發送請求獲取連接

這裏的HiHijackConn功能跟之前介紹的類似，其核心也是通過建立http鏈接，然後進行協議提升，其conn就是底層的tcp鏈接，同時還給對應的鏈接設置了Keepliave當前是30s, 到此我們就又有了一個基於spdy雙向通信的鏈接

func (cli *Client) postHijacked(ctx context.Context, path string, query url.Values, body interface{}, headers map[string][]string) (types.HijackedResponse, error) {
    conn, err := cli.setupHijackConn(ctx, req, "tcp")
    return types.HijackedResponse{Conn: conn, Reader: bufio.NewReader(conn)}, err
}

5.10.3 建立流對拷

至此在kubelet上面我們獲取到了與後端執行命令的Stream還有與apiserver建立的Stream， 此時就只需要將兩個流直接進行拷貝，就可以實現數據的傳輸了

func (d *kubeDockerClient) holdHijackedConnection(tty bool, inputStream io.Reader, outputStream, errorStream io.Writer, resp dockertypes.HijackedResponse) error {
    receiveStdout := make(chan error)
    if outputStream != nil || errorStream != nil {
        // 將響應結果拷貝到outputstream裏面
        go func() {
            receiveStdout <- d.redirectResponseToOutputStream(tty, outputStream, errorStream, resp.Reader)
        }()
    }

    stdinDone := make(chan struct{})
    go func() {
        if inputStream != nil {
            io.Copy(resp.Conn, inputStream)
        }
        resp.CloseWrite()
        close(stdinDone)
    }()

    return nil
}

5.10.4 檢測執行狀態

在發生完成執行命令以後，會每隔2s鍾進行一次執行狀態的檢查，如果發現執行完成，則就直接退出

func (*NativeExecHandler) ExecInContainer(client libdocker.Interface, container *dockertypes.ContainerJSON, cmd []string, stdin io.Reader, stdout, stderr io.WriteCloser, tty bool, resize <-chan remotecommand.TerminalSize, timeout time.Duration) error {
    ticker := time.NewTicker(2 * time.Second)
    defer ticker.Stop()
    count := 0
    for {
        //  獲取執行結果
        inspect, err2 := client.InspectExec(execObj.ID)
        if err2 != nil {
            return err2
        }
        if !inspect.Running {
            if inspect.ExitCode != 0 {
                err = &dockerExitError{inspect}
            }
            break
        }
        <-ticker.C
    }

    return err
}

func (cli *Client) ContainerExecInspect(ctx context.Context, execID string) (types.ContainerExecInspect, error) {
    resp, err := cli.get(ctx, "/exec/"+execID+"/json", nil, nil)
    return response, err
}

6.總結

整個命令執行的過程其實還是蠻複雜的，主要是在於網絡協議切換那部分，我們可以看到其實在整個過程中，都是基於SPDY協議來進行的，並且在CRI.RuntimeService那部分我們也可以看到Stream的請求處理其實也是多goroutine併發的，仰慕一下大牛的設計，有什麼寫的不對的地方，歡迎一起討論，謝謝大佬們能看到這裏

kubernetes學習筆記地址: https://www.yuque.com/baxiaoshi/tyado3