首页 文章 精选 留言 我的

精选列表

搜索[asp]，共1555篇文章
优秀的个人博客,低调大师

ASP.NET Core on K8S深入学习（11）K8S网络知多少

本篇已加入《.NET Core on K8S学习实践系列文章索引》，可以点击查看更多容器化技术相关系列文章。 一、Kubernetes网络模型 我们都知道Kubernetes作为容器编排引擎，它有一个强大又复杂的网络模型，也牵引出了Pod网络、Service网络、ClusterIP、NodePort、Ingress等多个概念。这里我们采用杨波老师（架构师杨波）模仿TCP/IP协议栈总结的一个K8S网络模型图来看看K8S的四个抽象层次，从而了解一下K8S的网络。本小节的文字主要引用自杨波老师关于K8S网络模型的文章及CloudMan的《每天5分钟玩转Kubernetes》一书。 根据上图模型中展示的四个层次，从0到3，除了第0层，每一层都是构建于前一层之上。 （1）第0层：节点主机互通互联 主要保证K8S节点(物理或虚拟机)之间能够正常IP寻址和互通的网络，这个一般由底层(公有云或数据中心)网络基础设施支持，这里我们无需过多关心。 （2）第1层：Pod虚拟机互联 在一个Pod中可以运行一个或多个容器，且Pod中所有容器使用同一个网络namespace，即相同的IP和端口空间，可以直接用localhost通信，而且还可以共享存储（本质是通过将Volume挂载到Pod中的每个容器）。 （3）第2层：服务发现和负载均衡 在K8S集群中，Pod的IP并不是固定的，可能会频繁地销毁和创建实例，为了解决此问题，Service提供了访问Pod的抽象层。即无论后端Pod如何变化，Service都作为稳定的前端对外提供服务。此外，Service还提供了高可用和负载均衡的功能，它负责将请求转发给正确的Pod。 （4）第3层：外部流量接入 K8s的Service网络只是一个集群内部网络，集群外部是无法直接访问的。为此，想要将应用暴露出去让公网能够访问，K8S提供了两种方式： ① NodePort：使Service通过Cluster节点的静态端口对外提供服务，外部可以通过 NodeIP:NodePort 来访问Service。 ② LoadBalancer：使Service利用Cloud Provider提供的Load Balancer对外提供服务，Cloud Provider负责将Load Balancer的流量导向Service。目前支持的Cloud Provider包括AWS、Azure、阿里云、腾讯云等。 More：关于K8S网络的更多基本原理与讲解，强力推荐阅读波波老师的以下文章： Kubernetes网络三部曲-Pod网络（From 杨波老师） Kubernetes网络三部曲-Service网络（From 杨波老师） Kubernetes网络三部曲-外部接入网络（From 杨波老师） 二、传说中的CNI规范 为了保证网络方案的标准化、扩展性和灵活性，K8S采用了CNI（Container Networking Interface）规范。CNI是一个Pod网络集成标准，简化了K8S和不同Pod网络实现技术的集成。CNI最大的优点就是支持多种容器runtime，而不仅仅是Docker。目前已经有多种支持K8S的网络方案，包括 Flannel、Calico、Canal等，它们都实现了CNI规范，因此无论我们选择哪种具体方案，它们的网络模型都是一致的。 More：关于CNI的更多基本原理与讲解，推荐阅读陈Sir的文章《K8S网络详解：CNI与CNI网络模型》 三、Network Policy 3.1 关于Network Policy Network Policy是K8S的一种资源，它使K8S可以通过Label选择Pod，并指定其他Pod或外界如何与这些Pod通信。换句话说，当Pod被定义了Network Policy时，只有Policy允许的流量才能访问Pod（默认情况下，任何来源的流量都可以访问Pod，是没有限制的）即帮助K8S实现更为精细的流量控制，实现租户隔离机制。 But，并不是所有K8S网络方案都支持Network Policy，比如Flannel就不支持，而Calico是支持的。 3.2 Network Policy实践 3.2.1 部署Canal 想要部署Canal，需要切换网络方案，这里我们使用最简单粗暴的方式：重建当前K8S集群 kubeadm reset # 在每个节点上执行一次 然后，重新对Master节点进行初始化： kubeadm init \ --apiserver-advertise-address=192.168.2.100 \ --image-repository registry.aliyuncs.com/google_containers \ --kubernetes-version v1.13.3 \ --service-cidr=10.1.0.0/16 \ --pod-network-cidr=10.244.0.0/16 在两个Node节点上执行以下命令重新加入集群：（注意这里的token请填写你的Master节点初始化后的输出结果） kubeadm join 192.168.2.100:6443 --token ekqxk2.iiu5wx5bbnbdtxsw --discovery-token-ca-cert-hash \ sha256:c50bb83d04f64f4a714b745f04682b27768c1298f331e697419451f3550f2d05 最后，通过以下命令部署Canal：（参考自K8S官方文档） kubectl apply -f https://docs.projectcalico.org/v3.8/manifests/canal.yaml 此时，再次令验证的集群结果如下： （1）集群节点状态 （2）Pod状态 3.2.2 部署测试应用 这里通过一个httpd应用来演示Network Policy，该应用的yaml定义如下： apiVersion: apps/v1 kind: Deployment metadata: name: httpd spec: replicas: 3 selector: matchLabels: name: networkpolicy-demo template: metadata: labels: name: networkpolicy-demo spec: containers: - name: httpd image: httpd:latest ports: - containerPort: 80 imagePullPolicy: IfNotPresent --- kind: Service apiVersion: v1 metadata: name: httpd-svc spec: type: NodePort ports: - protocol: TCP nodePort: 31000 port: 8080 targetPort: 80 selector: name: networkpolicy-demo 通过kubectl将其部署到K8S集群： kubectl apply -f httpd-demo.yaml 这时候三个httpd Pod已经成功Running： 由于定义的是NodePort方式暴露服务，这里我们在集群外部访问Service看看： 由于当前并没有创建任何Network Policy，这里我们可以通过创建一个Pod应用（我们熟悉的busybox）来验证一下是否可以在K8S集群内部随意访问该httpd应用： kubectl run busybox --rm -it --image=busybox /bin/sh 从上图可以知道，它可以正常访问到Service，也可以正常ping到Pod节点。 3.2.3 测试Network Policy有效性 现在我们创建一个Network Policy，其配置文件yaml如下： apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: access-httpd spec: podSelector: matchLabels: name: networkpolicy-demo ingress: - from: - podSelector: matchLabels: access: "true" ports: - protocol: TCP port: 80 该Network Policy定义了如下规则： （1）应用于所有 label 为 name : networkpolicy-demo 的Pod，这里即刚刚创建的三个httpd pod。 （2）ingress中定义了只有 label 为 access : "true" 的Pod才能访问应用。 （3）即使通过Policy也只能访问80端口 通过kubectl将其应用到K8S集群中： kubectl apply -f networkpolicy.yaml 下面再次在busybox pod中验证Network Policy的有效性： 从上图中可以看到，已经无法再成功访问Service，也无法再ping通三个Pod节点。 这个时候，集群外也无法再通过NodePort访问到Service： 如果想要让测试Pod（busybox）能访问到应用了Network Policy的httpd应用，我们可以对busybox pod加一个label就可以： kubectl run busybox --rm -it --image=busybox --labels="access=true" /bin/sh 运行后的验证结果如下，可以访问到Service，但Ping却被禁止： 但是，此时集群节点（k8s-master与两个node）与集群仍然无法访问到应用了Network Policy的httpd应用，如果想要让它们也访问到，则需要修改Network Policy做一个类似于开防火墙白名单的操作（注意下面的ipBlock配置）： apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: access-httpd spec: podSelector: matchLabels: name: networkpolicy-demo ingress: - from: - podSelector: matchLabels: access: "true" - ipBlock: cidr: 192.168.2.0/24 ports: - protocol: TCP port: 80 再次应用到K8S集群后，再来通过集群外部的访问者浏览器试试： 可以看到，已经可以正常访问啦！ 四、小结 本文简单介绍了Kubernetes的4层网络模型、CNI 容器网络接口规范 以及 Network Policy，并通过改造K8S集群的网络配置从Flannel到Canal来验证Network Policy的有效性。对于Kubernetes的网络模型的原理与介绍，强烈推荐阅读杨波老师的《Kubernetes网络三部曲》，它的传送门位于下方的参考资料列表中。最后，希望能够对初学者的你有所帮助！ 参考资料 （1）CloudMan，《每天5分钟玩转Kubernetes》 （2）李振良，《一天入门Kubernets教程》 （3）马哥（马永亮），《Kubernetes快速入门》 （4）Liang，《K8S CNI网络最强对比》 （5）杨波，《K8S网络三部曲》 （6）陈Sir，《K8S网络详解：CNI与CNI网络模型》
2019-12-16
优秀的个人博客,低调大师

Ubuntu & GitLab CI & Docker & ASP.NET Core 2.0 自动化发布和部署（2）

实现上面目的，大概有三种实现方式： GitLab Runner 不运行在 Docker 容器中：Executor 选择shell（本地运行），然后在本服务器上安装 .NET Core 和 Docker 环境，.gitlab-ci.yml中执行dotnet编译发布和docker构建发布脚本，将构建的镜像推送到 Docker 私有仓库，然后 SSH 连接到服务器，拉取镜像并创建相应容器，最后启动容器，完成发布和部署。 GitLab Runner 运行在 Docker 容器中：Executor 选择shell（GitLab Runner 容器中运行），然后进入 GitLab Runner 容器，在上面安装 .NET Core 和 Docker 环境，.gitlab-ci.yml中执行dotnet编译发布和docker构建发布脚本，后面同上操作。 GitLab Runner 运行在 Docker 容器中：Executor 选择docker（指定镜像容器中运行），需要自定义构建一个包含 .NET Core 和 Docker 环境的镜像，构建脚本执行在自定义镜像容器中，.gitlab-ci.yml中执行dotnet编译发布和docker构建发布脚本，后面同上操作。 上面三种方式，最简单的是第一种，第二种和第三种比较类似，实现稍微复杂点，我也没有配置成功，下面分别说下。 1. GitLab Runner 运行在 Docker 容器中 第二种和第三种实现方式，放在一块说，如果 Executor 选择shell，然后我们需要在 GitLab Runner 容器中配置编译环境，但这样会产生一个问题，就是如果我们是升级 GitLab Runner 的时候，需要重新配置编译环境，实际情况是，我进入容器docker exec -it gitlab-runner bash，并没有安装成功 .NET Core 和 Docker 环境（各种服务器中没出现的问题，而且速度非常慢），其实，还有一种方式，就是在.gitlab-ci.yml中执行安装 .NET Core 和 Docker 环境的脚本（检查是否安装），不过，编写是有些问题，这个我没进行尝试。 如果 Executor 选择docker，其实，这样会嵌套很多容器，首先服务器上运行 GitLab Runner 容器，然后在此容器内，运行另外一个构建容器，然后在此容器内，执行构建和发布操作，因为 GitLab Runner 在每次构建的时候，会创建和运行一个新的构建容器，所以，我们不能直接在这个容器中，配置 .NET Core 和 Docker 环境，也不能在.gitlab-ci.yml中执行安装，因为每次都会覆盖之前的操作，唯一的解决方式，就是自定义构建一个包含 .NET Core 和 Docker 环境的镜像文件，然后每次构建使用它进行创建对应容器，执行构建和发布脚本即可。 这里说下，自定义构建一个包含 .NET Core 和 Docker 环境的镜像文件，两种方式： docker build -t 139.219.65.81:5000/xishuai-gitlab-ci-build .：在Dockerfile文件编写安装环境脚本。 docker commit microsoft-aspnetcore 139.219.65.81:5000/xishuai-gitlab-ci-build：使用一个容器，然后在容器中安装环境，最后基于这个容器，创建一个自定义镜像文件 第一种方式，我没有进行尝试，第二种方式尝试了下，我使用microsoft/aspnetcore镜像作为基础镜像（800M 左右），然后在其创建的容器中安装 Docker 环境，速度非常慢，而且有时候报各种奇怪的错误，如果安装成功了，左右构建的自定义镜像文件，也非常的大。 这两种方式，我最后都没有采用，最后使用的是下面最简单的方式。 2. GitLab Runner 不运行在 Docker 容器中（Executor 选择 Shell） 如果我们不使用 Docker 安装和运行 GitLab Runner，就得手动进行安装和配置下 GitLab Runner。 安装命令： $ sudo wget -O /usr/local/bin/gitlab-runner https://gitlab-ci-multi-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-ci-multi-runner-linux-amd64 然后进行给予其权限： $ sudo chmod +x /usr/local/bin/gitlab-runner 接着就可以进行注册 GitLab Runner 了，命令： $ sudo gitlab-runner register 示例配置： 配置好之后，我们需要添加一个用于跑 GitLab Runner 的gitlab-runner用户，命令： $ sudo useradd --comment 'GitLab Runner' --create-home gitlab-runner --shell /bin/bash 然后指定 GitLab Runner 执行的用户和工作目录，命令： $ sudo gitlab-runner install --user=gitlab-runner --working-directory=/home/gitlab-runner 配置好之后，我们可以从配置文件中，查看相关配置信息： $ cat /etc/systemd/system/gitlab-runner.service [Unit] Description=GitLab Runner After=syslog.target network.target ConditionFileIsExecutable=/usr/bin/gitlab-ci-multi-runner [Service] StartLimitInterval=5 StartLimitBurst=10 ExecStart=/usr/bin/gitlab-ci-multi-runner "run" "--working-directory" "/home/gitlab-runner" "--config" "/etc/gitlab-runner/config.toml" "--service" "gitlab-runner" "--syslog" "--user" "gitlab-runner" Restart=always RestartSec=120 [Install] WantedBy=multi-user.target 上面工作完成之后，就可以启动 GitLab Runner 了，命令： $ sudo gitlab-runner start 然后，我们就可以在项目中看到 GitLab Runner 了，示例： 另外，我们还需要做一些其他工作，来保证 GitLab Runner 可以正常运行。 两台服务器需要配置的环境： GitLab Runner 服务器：.NET Core 2.0、Docker、Docker 私有仓库（或者其他服务器）、SSH 测试服务器：Docker 首先，我们需要创建一个 Docker 私有仓库，用于存放程序生成的镜像，这个最好是配置在一个单独的服务器，配置详见：Ubuntu Docker Registry 搭建私有仓库 通过下面两个连接，查看 Docker 私有仓库中的镜像： http://139.219.69.172:5000/v2/_catalog http://139.219.69.172:5000/v2/hwapp/tags/list 然后，我们需要把 GitLab Runner 服务器中的gitlab-runner账户，添加到docker用户组中，命令： $ sudo usermod -aG docker gitlab-runner 否则会报如下错误： 然后，我们在 GitLab Runner 服务器中，切换到gitlab-runner用户下，配置 SSH，命令： $ su gitlab-runner $ ssh-keygen -t rsa -P '' $ ssh-copy-id root@139.219.69.172 139.219.69.172是测试服务器的 IP 地址，如果不进行这样配置，SSH 连接的时候，会报如下错误： 原因是，GitLab Runner 在执行脚本的时候，会切换到gitlab-runner用户下，我们在root账户下配置 SSH，是无效的。 以上工作完成之后，GitLab Runner 执行编译脚本，基本上执行是没有问题了，我们在示例项目中添加.gitlab-ci.yml配置文件，示例： stages: - build - deploy_dev build_job: stage: build only: - master script: - dotnet restore - dotnet build deploy_dev_job: stage: deploy_dev environment: name: development only: - master script: # 发布程序并部署运行 - dotnet publish -c Release --output bin/publish - docker build -t $GITLAB_SERVER:5000/hwapp . - docker push $GITLAB_SERVER:5000/hwapp - ssh root@$DEPLOY_SERVER_DEV "docker pull $GITLAB_SERVER:5000/hwapp && docker run -d -p 5001:5001 $GITLAB_SERVER:5000/hwapp" build_job执行效果： deploy_dev_job执行效果： 然后，我们在测试服务器上，就可以看到创建和运行的容器了： 浏览器打开http://139.219.110.30:5001/api/values，查看效果： 本文转自田园里的蟋蟀博客园博客，原文链接：http://www.cnblogs.com/xishuai/p/ubuntu-gitlab-ci-docker-aspnet-core-part-2.html，如需转载请自行联系原作者
2016-01-22
优秀的个人博客,低调大师

2.2Bind建立配置文件和实体的映射「深入浅出ASP.NET Core系列」

希望给你3-5分钟的碎片化学习，可能是坐地铁、等公交，积少成多，水滴石穿，谢谢关注。 新建MVC项目 这次我们没有使用控制台项目，而是使用mvc来测试。 如下图所示，选择空的项目，建完后，记得把项目设置为启动项 新建配置文件appsettings.json和映射的实体类 这里有个坑，就是json和实体类必须要一一对应，假如json里命名为student，实体类为students，内部自动映射过程会报错，错误如下： Startup启动时注入配置类Configuration 这里就不贴上代码，代码在手机上的观感比较乱，不如图片来得整洁，具体代码可以查看github地址：https://github.com/oncefly/aspnetcore 使用Bind绑定并打印结果 ok，查看结果如下： 注意：mvc项目运行的时候，我们选择的不是IIS Express，目的是为了打印错误，方便排查，推荐使用控制台模式。 我是.NET架构师张飞洪，入行10年有余，人不堪其忧，吾不改其乐，谢谢您关注我的头条号。
2018-11-02

资源下载

更多资源
Spring

Spring

Spring框架（Spring Framework）是由Rod Johnson于2002年提出的开源Java企业级应用框架，旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念，提供核心容器、应用上下文、数据访问集成等模块，支持整合Hibernate、Struts等第三方框架，其适用范围不仅限于服务器端开发，绝大多数Java应用均可从中受益。

时间: 2026-08-21 大小: 5MB 下载: 2次
Rocky Linux

Rocky Linux

Rocky Linux（中文名：洛基）是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版，作为CentOS稳定版停止维护后与RHEL（Red Hat Enterprise Linux）完全兼容的开源替代方案，由社区拥有并管理，支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性，采用模块化包装和SELinux安全架构，默认包含GNOME桌面环境及XFS文件系统，支持十年生命周期更新。

时间: 2026-08-21 大小: 1.42GB 下载: 6次
Sublime Text

Sublime Text

Sublime Text具有漂亮的用户界面和强大的功能，例如代码缩略图，Python的插件，代码段等。还可自定义键绑定，菜单和工具栏。Sublime Text 的主要功能包括：拼写检查，书签，完整的 Python API ， Goto 功能，即时项目切换，多选择，多窗口等等。Sublime Text 是一个跨平台的编辑器，同时支持Windows、Linux、Mac OS X等操作系统。

时间: 2026-08-21 大小: 9.84MB 下载: 40次
WebStorm

WebStorm

WebStorm 是jetbrains公司旗下一款JavaScript 开发工具。目前已经被广大中国JS开发者誉为“Web前端开发神器”、“最强大的HTML5编辑器”、“最智能的JavaScript IDE”等。与IntelliJ IDEA同源，继承了IntelliJ IDEA强大的JS部分的功能。

时间: 2025-12-13 大小: 249.54MB 下载: 22次
热门标签
DeepSeek Jdk25 OpenAi HarmonyOS6 Nacos3 SpringBoot4 SpringCloud Docker Kubernetes Service Mesh Redis Gemini3 Rocky

欢迎您来访！

登录后，您将获得更多功能！
热门文章
联系我们

有任何问题或合作意向欢迎联系我们

Email: 99873273@qq.com

QQ: 99873273

用户登录
用户注册