Kubernetes 架构

Kubernetes又称之为k8s，其运作种共分层三个架构层面，1. Components 如etcd, dns server ...，2. 或者以可以从service 运作的角度出发，最後就是3.内部网路的运作。本文章将会对此进行归纳整理，并提供例子。
gitbook drafts

Overview Kubernetes 架构

以Components 角度看Kubernetes

• Control Pane:用於管理其他Node、Service、Pod的工具，是由K8s Server拥有，也可以透过该原件排程等等。
• DNS Server: 赋予Node、Service、Pod的Domain Name。
• Kubelete: Node 透过该工具去管理Node 中的Service、Pod。
• etcd: 储存各种k8s的状态。
• Kube Proxy: 用於管理除了Server Node Network。

在K8s 分成两种Node，K8s Server 与 agent两种[5]，差别在於是否具有权限管理其他的Node，也就是是否具有Control Pane 元件的Node。而Control Pane 主要能够透过kubelete 去操作其他的Node中的Pod、Service...等等。

以服务角度看Kubernetes

在K8s定义下，Service 是抽象化一群Pod的意思，举个例子一套系统会有各种DB、Message Queue、Functionalities 共由三个Pod，使用者可以定义这三个Pod 作为一组Service，称Backend Service。

然而在实际的应用是由多个 Service 组成，像是一般网站至少有两个Service，Frontend Service、Backend Service，以下图为例，在k8s要组成一个应用则会有多个Service相互作用才能达成。

Service 主要分成四种网路型态[1]:

• ClusterIP: Exposes the Service on a cluster-internal IP.
• NodePort: Exposes the Service on each Node's IP at a static port (the NodePort).
• LoadBalancer:Exposes the Service externally using a cloud provider's load balancer
• ExternalName:Maps the Service to the contents of the externalName field

网路状态看Kubernetes

对於开发服务的工程师而言，各Container其实才是真的功能面的最小单位，如http, ssh, mqtt等。在k8s 中是把一群的container 视为最小单位(Pod)，换句话说以维运的角度整体服务才是最小单位。因此k8s 需要Mapping机制使得Container, Pod, Service 这之间可以对的上。以下图为例，k8s 中共分成3个component分别为Container, Pod, Service。在Container 的部分维运者需要为各功能取名，如http, mqtt, ssh 等功能名称於Pod 设定档，此时的Pod 就被视为一个单一功能。而Service则会将这些功能组合成一个服务，透过Mapping Pod 中所定义的名称、Port组合。最後将服务的存取位置释放给Node，也就是Endpoint 设定。

对於在k8s 中除了Node 内部网路的设定，也还包含Cluster 中 Node 网路的设定，也就是 Ingress 。

Ingress 使用於External Client 实际Query 的请求Route，Client 不用特别指定使用的机器，而是开发者事先设定Cluster 的Routing。可参考下图示例。

 (1).png>)

范例实作

由於k8s 本身的硬体需求比较庞大，因此各家机构纷纷推出自己的k8s开放工具，如Ubuntu基金会的Micro-K8s 或者 Rancher 的 k3s...等等，本范例使用k3s 进行解说，测试环境作业系统为ubuntu 20.04。共解说两个范例1. Run A Service in K8s, 2. Run A Service in k8s agent。

K8s ymal 档案主要有几个必填项目：

• apiVersion - Which version of the Kubernetes API you're using to create this object
• kind - What kind of object you want to create
• metadata - Data that helps uniquely identify the object, including a name string, UID, and optional namespace
• spec - What state you desire for the object

Attachment(1) nginx Pod config

其中 pod中的 labels 非常重要，这里决定Service 的selector 中要完全一样才能够成功mapping.

apiVersion: v1
kind: Pod
metadata:
  name: nginx-demo
  labels:
    app: nginx
spec:
  containers:
  - name: nginx
    image: nginx:1.14.2
    ports:
    - containerPort: 80

Attachement(2) nginx Serivce config

Service 中 selector 指的是所选择的Pod 名称，然而也可以选择多个但以下范例只填一个。在Service yaml 档案中，需要住要 type 栏位，如果选择NodePort 可以供外部电脑存取。

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  type: NodePort
  selector:  
    app: nginx
  ports:
    - name: http
      protocol: TCP
      port: 80
      targetPort: 80
      nodePort: 30390

执行 pod

sudo kubectl apply -f nginx-pod.yaml

执行service

sudo kubectl apply -f nginx-service.yaml

Describe Service

Test

• curl 10.42.0.50.80 -> 透过Endpoint : port 由server 内部进入

• curl 172.20.10.3:30390 -> curl external ip : nodePort

Reference

[1] https://kubernetes.io/docs/concepts/services-networking/service/
[2] https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#spec-and-status
[3] https://rancher.com/docs/k3s/latest/
[4] Luksa, Marko. Kubernetes in action. Simon and Schuster, 2017.
[5] https://k3s.io/