Kubernetes初探[1]：部署你的第一个ASP.NET Core应用到k8s集群
转自：https://www.cnblogs.com/RainingNight/p/first-aspnetcore-app-in-k8s.html
Kubernetes简介
Kubernetes是Google基于Borg开源的容器编排调度引擎，作为CNCF（Cloud Native Computing Foundation）最重要的组件之一，它的目标不仅仅是一个编排系统，而是提供一个规范，可以让你来描述集群的架构，定义服务的最终状态，Kubernetes可以帮你将系统自动得达到和维持在这个状态。
更直白的说，Kubernetes可以让用户通过编写一个yaml或者json格式的配置文件，也可以是通过工具/代码生成或者是直接请求Kubernetes API来创建应用，该配置文件中包含了用户想要应用程序保持的状态，不管整个Kubernetes集群中的个别主机发生什么问题，都不会影响应用程序的状态，你还可以通过改变该配置文件或请求Kubernetes API来改变应用程序的状态。
这意味着开发人员不需要在意节点的数目，也不需要在意从哪里运行容器以及如何与它们交流。开发人员也不需要管理硬件优化，或担心节点关闭（它们将遵循墨菲法则），因为新的节点会添加到Kubernetes集群，同时Kubernetes会在其他运行的节点中添加容器，Kubernetes会发挥最大的作用。
总结：Kubernetes是容器控制平台，可以抽象所有的底层基础设施（容器运行用到的基础设施）。
Kubernetes——让容器应用进入大规模工业生产。
Kubernetes另一个深入人心的特点是：它标准化了云服务提供商。比如，有一个Azure、Google云平台或其他云服务提供商的专家，他担任了一个搭建在全新的云服务提供商的项目。这可能引起很多后果，比如说：他可能无法在截止期限内完成；公司可能需要招聘更多相关的人员，等等。相对的，Kubernetes就没有这个问题。因为不论是哪家云服务提供商，你都可以在上面运行相同的命令，以既定的方式向Kubernetes API服务器发送请求，Kubernetes会负责抽象，并在不同的云服务商中实现。
对于公司来说，这意味着他们不需要绑定到任何一家云服务商。他们可以计算其他云服务商的开销，然后转移到别家，并依旧保留着原来的专家，原来的人员，他们还可以花更少的钱。
Pod
Kubernetes有很多技术概念，同时对应很多API对象，最重要的也是最基础的对象就是Pod。Pod是Kubernetes集群中运行部署应用的最小单元，并且是支持多个容器的。
Pod的设计理念是支持多个容器在一个Pod中共享网络地址和文件系统，可以通过进程间通信和文件共享这种简单高效的方式组合完成服务。Pod对多容器的支持是Kubernetes最基础的设计理念。比如你运行一个操作系统发行版的软件仓库，一个Nginx容器用来发布软件，另一个容器专门用来从源仓库做同步，这两个容器的镜像不太可能是一个团队开发的，但是他们一块儿工作才能提供一个微服务；这种情况下，不同的团队各自开发构建自己的容器镜像，在部署的时候组合成一个微服务对外提供服务。不过，在大多数情况下，我们只会在Pod中运行一个容器，本文中的例子也是这样的。
Pod 的另一个特征是：如果我们希望使用其他
RKE等技术的话，我们可以做到不依赖Docker容器。
Docker是kubernetes中最常用的容器运行时，但是Pod也支持其他容器运行时。
总的来说，Pod的主要特征包括：
-
每个Pod可以在Kubernetes集群内拥有唯一的IP地址；
-
Pod可以拥有多个容器。这些容器共享同一个端口空间，所以他们可以通过
localhost
交流（可想而知它们无法使用相同的端口），与其他Pod内容器的交流可以通过结合Pod的IP来完成； -
一个Pod内的容器共享同一个卷、同一个 IP、端口空间、IPC 命名空间。
定义一个Pod
如下，我们定义一个最简单的Pod：
apiVersion: v1 kind: Pod # 定义Kubernetes资源的类型为Pod metadata: name: demo-web # 定义资源的名称 labels: # 为Pod贴上标签，后面会介绍其用处 app: demo-web spec: # 定义资源的状态，对于Pod来说，最重要属性就是containers containers: # containers一个数组类型，如果你希望部署多个容器，可以添加多项 - name: web # 定义本Pod中该容器的名称 image: rainingnight/aspnetcore-web # 定义Pod启动的容器镜像地址 ports: - containerPort: 80 # 定义容器监听的端口（与Dockerfile中的EXPOSE类似，只是为了提供文档信息）
然后保存，我这里命名为[code]demo-web-pod.yaml。[/code]
现在我们可以在终端中输入以下命令来创建该Pod：
kubectl create -f demo-web-pod.yaml # 输出 # pod/demo-web created
可以使用如下命令，来查看kubernetes中的Pod列表:
kubectl get pods # 输出 # NAME READY STATUS RESTARTS AGE # demo-web 1/1 Running 0 65s
如果该Pod还处于
ContainerCreating状态的话，你可以在运行命令的时候加入
--watch参数，这样当Pod变成运行状态的时候，会自动显示在终端中。
访问应用程序
在上面，我们成功部署了一个ASP.NET Core Mvc程序的Pod，那么如何访问它呢？如果只是为了调试，我们可以使用转发端口的方式来快速访问：
kubectl port-forward demo-web 8080:80 # 输出 # Forwarding from 127.0.0.1:8080 -> 80
然后我们再浏览器中访问：127.0.0.1:8080，显示如下：
如上，还展示了Pod的主机名和IP，这是因为我在应用中添加了如下代码：
public void OnGet()
{
HostName = Dns.GetHostName();
HostIP = Dns.GetHostEntry(HostName).AddressList.FirstOrDefault(x => x.AddressFamily == AddressFamily.InterNetwork).ToString();
}
不过，端口转发的方式只能在本机访问，为了从外部访问应用程序，我们需要创建Kubernetes中的另外一种资源：Service。
Service
Kubernetes中的Service资源可以作为一组提供相同服务的Pod的入口，这个资源肩负发现服务和平衡Pod之间负荷的重任。
在Kubernetes集群中，我们拥有提供不同服务的Pod，那么Service如何知道该处理哪个Pod呢？
这个问题就用标签来解决的，具体分两个步骤：
- 给所有需要Service处理的对象Pod贴上标签。
- 在Service中使用一个选择器（
Label Selector
），该选择器定义了所有贴有对应的标签的对象Pod。
标签
标签提供了一种简单的方法用于管理Kubernetes中的资源。它们用一对键值表示，且可以用于所有资源。
其实在上面的Pod定义中，我们已经定义了标签：
metadata: name: demo-web labels: app: demo-web
如上，我们为Pod附加了标签
app:demo-web，在查看Pod的时候，可以使用
--show-labels参数来显示Pod对应的标签：
ubectl get pods --show-labels # 输出 # NAME READY STATUS RESTARTS AGE LABELS # demo-web 1/1 Running 0 1m52s app=demo-web
可以看到，我们的Pod都拥有一个
app=demo-web标签。
定义Service
现在，让我们为刚才创建的Pod定义一个Service：
apiVersion: v1 kind: Service # 定义Kubernetes资源的类型为Service metadata: name: demo-web-service # 定义资源的名称 spec: selector: # 指定对应的Pod app: demo-web # 指定Pod的标签为demo-web ports: - protocol: TCP # 协议类型 port: 80 # 指定Service访问的端口 targetPort: 80 # 指定Service转发请求的端口 nodePort: 30000 type: NodePort # 指定Service的类型，在这里使用NodePort来对外访问
如上，我们使用
selector属性来选择相应的标签，并把服务类型（type）设置为
NodePort，
type的取值有以下4种：
-
ClusterIP：默认值，通过集群的内部IP暴露服务，该模式下，服务只能够在集群内部可以访问。
-
NodePort：通过每个Node上的IP和静态端口（NodePort）暴露服务，NodePort服务会路由到ClusterIP服务，这个ClusterIP服务会自动创建。
-
LoadBalancer：使用云提供商的负载均衡器，可以向外部暴露服务，外部的负载均衡器可以路由到NodePort服务和ClusterIP服务。
-
ExternalName：通过返回CNAME和它的值，可以将服务映射到
externalName
字段的内容（如：foo.bar.example.com）。没有任何类型代理被创建，这只有 Kubernetes 1.7 或更高版本的kube-dns才支持。
对于服务类型我们先了解这么多就可以了，后续会再来详细介绍。
然后使用如下命令创建Service：
kubectl create -f demo-web-service.yaml # 输出 # service/demo-web-service created
使用如下命令来检查服务的状态：
kubectl get services # 输出 # NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE # demo-web-service NodePort 10.105.132.214 <none> 80:30000/TCP 10s
如上，它有一个CLUSTER-IP为
10.105.132.214，因此我们可以在集群内使用
10.105.132.214:80来访问该服务，如果是在集群外部，可以使用
NodeIP:30000来访问。
服务发现与负载均衡
在上面我们说到，Service肩负着发现服务和平衡Pod之间负荷的重任，那它是怎么做的呢？让我们先再添加一个Pod：
apiVersion: v1 kind: Pod metadata: name: demo-web-copy labels: app: demo-web spec: containers: - name: web image: rainingnight/aspnetcore-web ports: - containerPort: 80
如上，其定义与之前的Pod一样，只是把
name改成了
demo-web-copy，然后创建Pod:
kubectl create -f demo-web-copy.pod.yaml # 查看Pod kubectl get pods # 输出 # NAME READY STATUS RESTARTS AGE # demo-web 1/1 Running 0 10m # demo-web-copy 1/1 Running 0 29s
现在我们使用
NodeIP:30000来访问，打开两个浏览器窗口，多刷新几次，以便让它们分别路由到不同的Pod，最终显示如下：
可以看到，我们新创建的Pod已经通过Servie来接受请求了，不需要修改成任何程序代码，Kubernetes就已经帮我们实现了服务发现和负载均衡，是不是非常爽。
Deployment
在上面我们手动部署了两个Pod，但是这只是单机的玩法，它与直接使用Docker容器相比并无太大优势，如果我们需要部署一千个实例，那就是一个痛苦的过程，或者我们又想快速更新和迅速回滚，这根本就是不可能的！
其实在k8s中，我们很少直接使用Pod，更多的是使用Kubernetes的另外一种资源：Deployment。
Deployment表示用户对Kubernetes集群的一次更新操作。可以是创建一个新的服务或是更新一个新的服务，也可以是滚动升级一个服务。Deployment可以帮助每一个应用程序的生命都保持相同的一点：那就是变化。此外，只有挂掉的应用程序才会一尘不变，否则，新的需求会源源不断地涌现，更多代码会被开发出来、打包以及部署，这个过程中的每一步都有可能出错。Deployment可以自动化应用程序从一版本升迁到另一版本的过程，并保证服务不间断，如果有意外发生，它可以让我们迅速回滚到前一个版本。
Deployment定义
现在，我们使用Deployment来部署我们的Pod，并实现在部署期间服务不间断服务，可以如下定义：
apiVersion: apps/v1 kind: Deployment # 定义Kubernetes资源的类型为Deployment metadata: name: demo-web-deployment # 定义资源的名称 labels: app: demo-web-deployment spec: # 定义资源的状态。 replicas: 2 # 定义我们想运行多少个Pod，在这里我们希望运行2个 selector: matchLabels: # 定义该部署匹配哪些Pod app: demo-web minReadySeconds: 5 # 可选，指定Pod可以变成可用状态的最小秒数，默认是0 strategy: # 指定更新版本时，部署使用的策略 type: RollingUpdate # 策略类型，使用RollingUpdate可以保证部署期间服务不间断 rollingUpdate: maxUnavailable: 1 # 部署时最大允许停止的Pod数量（与replicas相比） maxSurge: 1 # 部署时最大允许创建的Pod数量（与replicas相比） template: # 用来指定Pod的模板，与Pod的定义类似 metadata: labels: # 根据模板创建的Pod会被贴上该标签，与上面的matchLabels对应 app: demo-web spec: containers: - name: web image: rainingnight/aspnetcore-web imagePullPolicy: Always # 默认是IfNotPresent，如果设置成Always，则每一次部署都会重新拉取容器映像（否则，如果本地存在指定的镜像版本，就不会再去拉取） ports: - containerPort: 80
保存为
demo-web-deployment.yaml，然后输入以下命令来创建Deployment：
kubectl create -f demo-web-deployment.yaml # 输出 # deployment.apps/demo-web-deployent created
现在我们再来查看以下Pod:
kubectl get pods # 输出 # NAME READY STATUS RESTARTS AGE # demo-web 1/1 Running 0 4h28m # demo-web-copy 1/1 Running 0 18m # demo-web-deployment-745f7997c4-d24bb 1/1 Running 0 16s # demo-web-deployment-745f7997c4-jk9jn 1/1 Running 0 16s
如上，我们有4个运行中的Pod，其中前二个是我们手动创建的，其他两个是使用Deployment创建的。
我们可以使用
kubectl delete pod <pod-name>删除一个Deployment创建的Pod，看看结果会怎样：
kubectl delete pod demo-web-deployment-745f7997c4-d24bb # 输出 # pod "demo-web-deployment-745f7997c4-d24bb" deleted
再次查看Pod列表：
kubectl get pods # 输出 # NAME READY STATUS RESTARTS AGE # demo-web 1/1 Running 0 31m # demo-web-copy 1/1 Running 0 22m # demo-web-deployment-745f7997c4-jk9jn 1/1 Running 0 3m39s # demo-web-deployment-745f7997c4-mrrw6 1/1 Running 0 11s
可以看到，又重新创建了一个Pod：
demo-web-deployment-745f7997c4-mrrw6，Deployment会监控我们的Pod数量，保持为我们预期的个数。
零停机时间部署(Zero-downtime)
现在我们尝试以下零停机部署，首先修改Deployment中的
image为：
rainingnight/aspnetcore-web:1.0.0，然后运行如下命令：
kubectl apply -f demo-web-deployment.yaml--record # 输出 # deployment.apps/demo-web-deployment configured
将kubectl的
--record设置为
true可以在
annotation中记录当前命令创建或者升级了该资源。这在未来会很有用，例如，查看在每个 Deployment revision 中执行了哪些命令。
除了修改yaml外，还可以直接运行
kubectl set image deployment demo-web-deployment web=rainingnight/aspnetcore-web:1.0.0 --record来达到同样的效果。
然后使用如下命令检查服务更新状态：
kubectl rollout status deployment demo-web-deployment # 输出 # Waiting for deployment "demo-web-deployment" rollout to finish: 1 old replicas are pending termination... # Waiting for deployment "demo-web-deployment" rollout to finish: 1 old replicas are pending termination... # Waiting for deployment "demo-web-deployment" rollout to finish: 1 old replicas are pending termination... # Waiting for deployment "demo-web-deployment" rollout to finish: 1 old replicas are pending termination... # Waiting for deployment "demo-web-deployment" rollout to finish: 1 of 2 updated replicas are available... # Waiting for deployment "demo-web-deployment" rollout to finish: 1 of 2 updated replicas are available... # deployment "demo-web-deployment" successfully rolled out
如上可以看到，新版本已经成功上线，并在这个过程中副本被逐个替换，也就意味着应用程序始终在线。
现在我们刷新一下浏览器，可以看到标题已经变成了
Home page - Web-v1:
回滚到前一个状态
如果突然发现新上线的版本有Bug，需要紧急回滚到上一个版本，那对Kubernetes来说也是非常简单的。
我们首先运行如下命令来查看历史版本：
kubectl rollout history deployment demo-web-deployment # 输出 # deployment.extensions/demo-web-deployment # REVISION CHANGE-CAUSE # 1 <none> # 2 kubectl apply --filename=demo-web-deployment.yaml --record=true
如上，可以看到有2条历史，那么为什么第1条的
CHANGE-CAUSE是
<none>呢，这就是因为我们第二次部署的时候使用了
--record=true参数。现在，我们想回滚到第一个版本，只需运行如下命令：
kubectl rollout undo deployment demo-web-deployment --to-revision=1 # 输出 # deployment.extensions/demo-web-deployment rolled back
再次刷新浏览器，标题又变回了
Home page - Web。
部署多个应用
现在我们再部署一个ASP.NET Core WebApi程序，并在刚才的Web应用中调用它，形成一个最简单的微服务模式。
部署WebApi
与前面的Web应用的部署类似，就不用过多介绍，定义如下YAML:
apiVersion: apps/v1 kind: Deployment metadata: name: demo-api-deployment labels: app: demo-api-deployment spec: replicas: 2 selector: matchLabels: app: demo-api minReadySeconds: 5 strategy: type: RollingUpdate rollingUpdate: maxUnavailable: 1 maxSurge: 1 template: metadata: labels: app: demo-api spec: containers: - name: api image: rainingnight/aspnetcore-api imagePullPolicy: Always ports: - containerPort: 80
然后创建Deployment：
kubectl create -f demo-api-deployment.yaml
查看部署情况：
kubectl get pods # 输出 # NAME READY STATUS RESTARTS AGE # demo-api-deployment-66575d644-9wk7g 1/1 Running 0 75s # demo-api-deployment-66575d644-fknpx 1/1 Running 0 75s # demo-web-deployment-745f7997c4-h7fr8 1/1 Running 0 9m23s # demo-web-deployment-745f7997c4-kvptm 1/1 Running 0 9m23s
前面手动创建的2个Pod已经被我删除了，因为用Deployment创建的Pod就好了。
现在我们为Api应用也创建一个Service，以便在Web应用中访问它：
apiVersion: v1 kind: Service metadata: name: demo-api-service spec: selector: app: demo-api ports: - protocol: TCP port: 80 targetPort: 80
因为我们的Api应用是不需要在集群外部访问的，因此服务类型（type）不需要设置，使用默认的
ClusterIP就可以了。
部署Servcie:
kubectl create -f demo-api-service.yaml
然后查看Servie:
kubectl get services # 输出 # NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE # demo-api-service ClusterIP 10.111.25.49 <none> 80/TCP 26s # demo-web-service NodePort 10.105.132.214 <none> 80:30000/TCP 58m
可以使用浏览器来访问：10.111.25.49/api/values 来验证一下是否部署成功。
调用服务
那么，还剩下最后一个问题，我们的Web应用中如何获取到Api应用的访问地址呢？
我们先看一下，在Web应用的代码中是怎么调用Api的：
// Startup.cs
public void ConfigureServices(IServiceCollection services)
{
services.AddHttpClient("api", _ => _.BaseAddress = new Uri(Configuration["ApiBaseUrl"]));
}
// FetchData.cshtml
public class FetchDataModel : PageModel
{
private static HttpClient _client;
public FetchDataModel(IHttpClientFactory httpClientFactory)
{
_client = httpClientFactory.CreateClient("api");
}
public IList<WeatherForecast> Forecasts { get; set; }
public async Task OnGetAsync()
{
var res = await _client.GetStringAsync("/api/SampleData/WeatherForecasts");
Forecasts = JsonConvert.DeserializeObject<IList<WeatherForecast>>(res);
}
}
如上，我们首先注册了一个
HttpClient，并从配置文件中读取
ApiBaseUrl做为
BaseAddress，然后在
FetchData页面中使用
HttpClient调用Api服务。
因为在Asp.Net Core中，默认情况下，环境变量中的配置是会覆盖
appsettings.json中的配置的，因此我们可以使用添加环境变量的方式来配置
ApiBaseUrl。
修改
demo-web-deployment.yaml，添加
env属性，如下：
containers: - name: web image: rainingnight/aspnetcore-web imagePullPolicy: Always ports: - containerPort: 80 env: - name: ApiBaseUrl value: "http://10.111.25.49"
然后在Kubernetes中应用该配置：
kubectl apply -f demo-web-deployment.yaml
等待滚动更新完成，刷新浏览器，点击
FetchData菜单：
如上，可以看到数据成功返回，但是直接使用集群IP
10.111.25.49，这也有点太低级了，其实我们可以直接使用域名：
http://demo-api-service，修改后如下：
env: - name: ApiBaseUrl value: "http://demo-api-service"
提交到Kubernetes，然后刷新浏览器，可以看到完美运行，这是因为CoreDNS(Kube-DNS)帮我们完成了域名解析。
在Kubernetes 1.11中，CoreDNS已经实现了基于DNS的服务发现的GA，可作为kube-dns插件的替代品。这意味着CoreDNS将作为各种安装工具未来发布版本中的一个选项来提供。事实上，kubeadm团队选择将其作为Kubernetes 1.11的默认选项。
CoreDNS是一个通用的、权威的DNS服务器，提供与Kubernetes后向兼容但可扩展的集成。它解决了kube-dns所遇到的问题，并提供了许多独特的功能，可以解决各种各样的用例。
DNS服务器监控kubernetes创建服务的API, 并为每个服务创建一组dns记录。如果在整个群集中启用了dns, 所有Pod都会使用它作为DNS服务器。比如我们的
demo-api-service服务，DNS服务器会创建一条"my-service.my-ns"也就是
10.111.25.49:demo-api-service.default的dns记录，因为我们的Web应用和Api应用在同一个命名空间(default)中，所以可以直接使用
demo-api-service来访问。
总结
本文带领大家一步一步部署了一个最简单的ASP.NET Core MVC + WebApi的微服务程序，介绍了Kubernetes中最基本的三个概念：Pod，Deployment，Service，相信大家对Kubernetes也有了一个全面的认识。
虽然Kubernetes整个体系是非常复杂的，但是不用担心，一开始我们不用去求甚解，最重要的是先跑起来，后续我会和大家一起逐步深入，由简到繁，愉快的掌握Kubernetes。
附本文所用示例代码：https://github.com/RainingNight/AspNetCoreDocker。
相关资料：
转载于:https://www.cnblogs.com/cxt618/p/10666549.html
- 点赞
- 收藏
- 分享
- 文章举报
ae6325
发布了0 篇原创文章 · 获赞 0 · 访问量 305
私信
关注
- Kubernetes初探[1]：部署你的第一个ASP.NET Core应用到k8s集群
- (视频)asp.net core系列之k8s集群部署视频
- ASP.NET Core on K8S深入学习（2）部署过程解析与Dashboard
- 张高兴的 Windows 10 IoT 开发笔记：部署 ASP.NET Core 2 应用
- 在 Docker 中部署 ASP.NET CORE 应用
- docker部署Asp.net core应用
- ASP.NET Core 应用发布与部署指南
- docker部署Asp.net core应用的完整步骤
- 10分钟学会在windows/Linux下设置ASP.Net Core开发环境并部署应用
- 10分钟学会在windows-Linux下设置ASP.Net Core开发环境并部署应用
- 实战Asp.Net Core：部署应用
- 使用 Visual Studio 部署 .NET Core 应用 ——ASP.NET Core 发布的具体操作
- Asp.net Core 使用Jenkins + Dockor 实现持续集成、自动化部署（三）：搭建jenkins集群环境
- Centos部署使用Jexus承载asp.net core2 web应用
- 张高兴的 Windows 10 IoT 开发笔记：部署 ASP.NET Core 2 应用
- ASP.NET Core on K8S深入学习（1）K8S基础知识与集群搭建
- ASP.NET Core 应用发布与部署指南
- ASP.NET Core on K8S学习初探（3）部署API到K8S
- ASP.NET Core on K8S学习初探（3）部署API到K8S
- windows/Linux下设置ASP.Net Core开发环境并部署应用