标签：spm 状态 有一个 资源 tor doc 均衡器 app log
在上一篇《单节点环境搭建》中，通过Docker for Windows在Windows开发机中搭建了一个单节点的K8S环境，接下来就是动人心弦的部署ASP.NET Core API到K8S了。但是，在部署之前，我还是把基本的一些概念快速地简单地不求甚解地过一下。
（1）集群
首先，K8S集群也是需要多台服务器组成，作为容器的编排管理平台，只有一个节点在生产环境是不够的。
（2）Node
其次，Node作为K8S集群中的工作节点，一个Node可以是VM或物理机，它运行真正的应用程序。
K8S中的Node又分为Master和Worker，和Hadoop集群中的NameNode和DataNode类似，简而言之就是一个是负责调度（维护集群状态）的，一个是负责干活（运行容器）的。
（3）资源
在K8S每个组件（比如Pod，Service等）开放对外暴露的都是一组RESTful API，所以我们所有对于组件的操作都可以通过RESTful API来完成，因此我们可以将其看作是资源。
（4）Kubectl
Kubectl是一个客户端命令行工具，使用它可以连接K8S集群和进行交互。
如下图所示，我们通过kubectl输入命令与远程的K8S集群连接，而这些命令本质是通过调用API访问Master节点提供的API，通过这些API去操作所谓的集群中的“资源”，对这些资源进行创建（POST），修改（PUT），删除（DELETE）等操作。
（1）Pod
Pod是K8S最基本的操作单元，包含一个或多个紧密相关的容器，一个Pod可以被一个容器化的环境看作是应用层的“逻辑宿主机”；
换句话说，在K8S中创建，调度和管理的最小单位就是Pod，而非容器（Container），多个容器之间的挂载是可以共享的，Pod通过提供更高层次的抽象，提供了更加灵活的部署和管理模式；
（2）Service
Service是一个抽象概念，它定义了逻辑集合下访问Pod组的策略。通过使用Service，我们就可以不用关心这个服务下面的Pod的增加和减少、故障重启等，只需通过Service就能够访问到对应服务的容器，即通过Service来暴露Pod的资源。
这样说可能还是有点难懂，举个例子，假设我们的一个服务Service A下面有3个Pod，我们都知道Pod的IP都不是持久化的，重启之后就会有变化。那么Service B想要访问Service A的Pod，它只需跟绑定了这3个Pod的Service A打交道就可以了，无须关心下面的3个Pod的IP和端口等信息的变化。换句话说，就像一个Service Discovery服务发现的组件，你无须关心具体服务的URL，只需知道它们在服务发现中注册的Key就可以通过类似Consul、Eureka之类的服务发现组件中获取它们的URL一样，还是实现了负载均衡效果的URL。
（3）Deployment
Deployment主要负责Pod的编排，例如我们可以使用下面的yaml文件来创建一个Deployment：
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.12.2
ports:
- containerPort: 80
熟悉Docker-Compose的朋友应该对这个yaml不陌生，可以看到Deployment定义了Pod内容，包括Pod数量、更新方式、使用的镜像，资源限制，容器中的映射端口等等。
（1）ClusterIP
ClusterIP 服务是 Kubernetes 的默认服务。它给你一个集群内的服务，集群内的其它应用都可以访问该服务，但是集群外部无法访问它。
因此，这种服务常被用于内部程序互相的访问，且不需要外部访问，那么这个时候用ClusterIP就比较合适，如下面的yaml文件所示：
apiVersion: v1
kind: Service
metadata:
name: my-internal-service
selector:
app: my-app
spec:
type: ClusterIP
ports:
- name: http
port: 80
targetPort: 80
protocol: TCP
那么，如果需要从外部访问呢（比如我们在开发模式下总得调试吧）？可以启用K8S的代理模式：
$ kubectl proxy --port=8080
如此一来，便可以通过K8S的API来访问了，例如下面这个URL就可以访问在yaml中定义的这个my-internal-service了：
http://localhost:8080/api/v1/proxy/namespaces/default/services/my-internal-service:http/
（2）NodePort
除了只在内部访问的服务，我们总有很多是需要暴露出来公开访问的服务吧。在ClusterIP基础上为Service在每台机器上绑定一个端口，这样就可以通过<NodeIP>:NodePort来访问这些服务。例如，下面这个yaml中定义了服务为NodePort类型：
apiVersion: v1 kind: Service metadata: name: my-nodeport-service selector: app: my-app spec: type: NodePort ports: - name: http port: 80 targetPort: 80 nodePort: 30036 protocol: TCP
PS：这种方式顾名思义需要一个额外的端口来进行暴露，且端口范围只能是 30000-32767，如果节点/VM 的 IP 地址发生变化，你需要能处理这种情况。
（3）LoadBalancer
LoadBalancer 服务是暴露服务到 internet 的标准方式，它借助Cloud Provider创建一个外部的负载均衡器，并将请求转发到<NodeIP>:NodePort（向节点导流）。
例如下面这个yaml中：
kind: Service apiVersion: v1 metadata: name: my-service spec: selector: app: MyApp ports: - protocol: TCP port: 80 targetPort: 9376 clusterIP: 10.0.171.239 loadBalancerIP: 78.11.24.19 type: LoadBalancer status: loadBalancer: ingress: - ip: 146.148.47.155
PS：每一个用 LoadBalancer 暴露的服务都会有它自己的 IP 地址，每个用到的 LoadBalancer 都需要付费，这将是比较昂贵的花费。
本文主要快速地不完全地不求甚解地过了一下K8S中的一些重要的基本概念，目的是为下一篇部署ASP.NET Core API到K8S有一个必要的认知。
ASP.NET Core on K8S学习初探（2）K8S基本概念快速一览
标签：spm 状态 有一个 资源 tor doc 均衡器 app log
原文地址：https://www.cnblogs.com/edisonchou/p/aspnet_core_on_k8s_firststudy_part2.html
