ASP.NET Core on K8S 学习初探(二)

  [LOG] ASP.NET Core on K8S Starting...

在上一篇《 单节点环境搭建 》中,通过Docker for Windows在Windows开发机中搭建了一个单节点的K8S环境,接下来就是动人心弦的部署ASP.NET Core API到K8S了。但是,在部署之前,我还是把基本的一些概念 快速地简单地不求甚解地 过一下。

01

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)等操作。

02

三大核心对象

(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数量、更新方式、使用的镜像,资源限制,容器中的映射端口等等。

03

Service的几种类型

(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中,定义type为LoadBalancer:


  

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 都需要付费,这将是比较昂贵的花费。

04

小结

本文主要快速地不完全地不求甚解地过了一下K8S中的一些重要的基本概念,目的是为下一篇部署ASP.NET Core API到K8S有一个必要的认知。

参考资料

  • Jesse,http://video.jessetalk.cn/my/course/6

  • 阿里云,https://github.com/AliyunContainerService/k8s-for-docker-desktop/tree/18.09

  • 阿里云,https://yq.aliyun.com/articles/508460?spm=a2c4e.11153940.blogcont221687.18.7dd57733hFolMo

  • 小黑老,https://www.jianshu.com/p/1555c9b7fccd

  • 腾讯云,http://www.sohu.com/a/227967825_212034

  • 池剑锋(译者),http://dockone.io/article/4884

我来评几句
登录后评论

已发表评论数()

相关站点

+订阅
热门文章