刚刚参加了F5/NGINX Community！的活动【报道】

1 年 ago
科, 颖
2 minutes

第一阶段的F5 / Nginx社区！

我参加了今天举行的以下活动！
https://f5-nginx.connpass.com/event/156307/
自从今年三月F5 Networks公司和Nginx公司合并以来，开过了一些活动，但这是我第一次参加类似meetup的活动，所以我决定去参加一下！
此外，活动概述中提到了以下内容，我认为参加可以帮助我解决目前工作中的问题和困扰。

基础设施和应用程序的开发方式已经发生了重大变化。传统的需求定义和耗时的基础设施和软件开发流程逐渐被以云端和API为前提，快速、小而精的开发、提供和改进方法所取代，成为主流。

此外，应用程序自身已经成为业务服务的主流，其重要性也日益增加。在这种背景下，我们听到了许多希望缩小应用程序开发与基础设施开发之间距离的声音。

该社区的目标是为了更快、更轻松地开发与商业相关的应用程序，将应用程序开发和基础设施开发的两个方面更加接近。

这是参加报告。

Kubernetes的Ingress是什么？

Ingress是Kubernetes的一个功能，它作为一个L7的负载均衡器，可以通过主机名和路径来路由从集群外部访问服务。ingress-nginx是通过使用Nginx来实现这些功能的。
如果在本地环境中构建Kubernetes，由于缺少创建Ingress的功能（即Ingress Controller），可以使用ingress-nginx来创建Ingress。

非常复杂，但ingress-nginx有两种类型

    • Kubernetesコミュニティの管理する kubernetes/ingress-nginx

Nginx社の管理する nginxinc/kubernetes-ingress

是的，我明白你的感受，两者都是基于Nginx，功能几乎相同，可能会感到厌烦。
大致功能是，在创建Ingress资源时，将Nginx的配置保存到Kubernetes的ConfigMap中，从而实现路由等功能。

ConfigMap 将配置文件、命令行参数、环境变量、端口号以及其他配置项与容器和系统组件绑定在一起。

ConfigMap 是什么东西？

请参阅此处的详细说明，了解关于细微差别的信息：kubernetes/ingress-nginx和nginxinc/kubernetes-ingress的区别。

由于这次的话题是Nginx的事件，我们将介绍nginxinc/kubernetes-ingress。
这个项目有两种类型，一种是开源版本（OSS），另一种是付费版本（Plus）。关于它们之间的区别，我希望你可以查看上面的链接来确认。
与kubernetes/ingress-nginx相比，最大的区别在于可以使用Nginx的Syntax。
由于本文是一篇报告，所以没有验证等内容，请大致理解即可。

启示录文件

Nginx Ingress在本地環境中的使用案例。

公司名称：株式会社カカクコム
演讲者：平台技术部门系统平台部 坂上涼先生
幻灯片：https://www.slideshare.net/RyoSakagami1/nginx-ingress-204839648

在本次会议上，株式会社カカクコム的代表向我们分享了从引入Kubernetes到使用Ingress Controller的经验。他们讲述了在株式会社カカクコム实施Kubernetes的部署和运维的案例。

通向Kubernetes之路

最初我使用了Docker，并意识到管理的重要性。然而，容器编排技术泛滥成灾，我对技术选择感到困惑。
在过去的一年里，我觉得Kubernetes已经成为事实上的标准，因此我迅速转向Kubernetes。

寻求人才网站的pub/sub队列系统项目
最初考虑在队列的一部分引入Kubernetes
使用Kafka作为消费者从队列中读取消息进行运营。
然而，这一部分既是短暂的又需要进行扩展。
随着逐渐扩大需要进行扩展等方面的要求，决定将整个队列系统转变为微服务化。

no_ingress_nginx.png
    • LB設定変更するために開発/インフラ間の調整コストがかかる

 

    • ポートアサインのコスト

 

    LBのプール設定

在处理LB的代理方面特别艰难。
需要一个可以良好处理代理功能的Ingress控制器呢…

ingress_nginx.png

不再需要在LB上进行代理设置，大大减轻了运营负担。

Ingress 和 Ingress 控制器

初创项目

    名前ベースのvirtualhost+L7LB

网络入口控制器

    • ルールに基づいてトラフィックをルーティングする実態

 

    • GKEやEKSといったクラウドプロバイダー

 

    オンプレミスの場合は自前で用意する必要がある。

我想在本地实施Ingress。

在引入Ingress Controller时，有以下三种产品比较可以考虑。

    • セルフホスト型では有名なkubernetes公式のkubernetes/ingress-nginx

https://github.com/kubernetes/ingress-nginx

nginxinc(OSS)

https://github.com/nginxinc/kubernetes-ingress

nginxinc(有償版)

经过比较和考虑，我们决定使用nginxinc（OSS）。
这个决定的原因如下所示。

    • 脆弱性への対応が早い

 

    ソース見て自分たちでカスタマイズできる

我们在Kubernetes的运维中按照以下步骤进行实施。

    • 公式のプレーンマニュフェストを利用する

kustomizeを利用してマニュフェストをカスタマイズ
algosyncを利用してCDを回す
Deploy

参考マニフェストファイル

# ホスト設定
server {
  server_name hoge.com;
}

# ルーティング設定
location / {
  return 302 /coffee;
}

# ホスト設定
spec:
  rules:
    - host: hoge.com

# ルーティング設定
annotations:
  nginx.org/rewrites:
serviceName=coffee-svc
rewrite=/coffee/"

由于引入了Ingress Controller所带来的好处

    通过Prometheus的原生支持，可以详细获取集群的指标数据。因此，现在可以轻松监视集群级别的流量。提高了可维护性。流程图的布线变得清晰易懂。使用虚拟主机进行基于名称的服务路由也成为可能。

请留意

    1. 服务OK / Ingress NG的情况

 

    1. 是由于Kubernetes组件故障导致的

 

    1. 需要进行监控的改进

 

    1. 需要更精细地进行监控

 

    1. 控制器的竞争

 

    1. 如果存在多个控制器，则默认情况下会出现重复运行

 

    需要在启动选项和注释之间进行类匹配

使用NGINX Ingress的体验谈

公司名称：Broadleaf株式会社
演讲者：田端先生
幻灯片：https://www.slideshare.net/KazuyaTabata/201912111f5nginx-community

我听说过Broadleaf公司在使用GKE时尝试验证了使用NGINX作为Ingress的故事。根据田端先生的同事所写的文章。

Ingress是什么东西？

为了将Kubernetes服务公开到外部的入口

让我们来创建一个NGINX Ingress吧

使用Terraform在GKE上创建集群/节点。

在kind中，通过指定Service、Pod和Ingress来描述宣言。

apiVersion: v1
kind: Service
metadata:
  name: hoge-api
  namespace: hoge-namespace
  labels:
    app: hoge-api
spec:
  type: (LoadBalancer->) NodePort
  ports:
  - port: (80->)8080 
    targetPort: 8080
    protocol: TCP
  selector:
    app: hoge-api

apiVersion: v1
kind: Pod
metadata:
  name: "hoge"
  labels:
    name: hoge-fuga
    role: web
spec:
  containers:
    - image: hoge/hoge-image:latest
      name: hoge-fuga
      ports:
        - containerPort: 8080
      env:
        - name: MESSAGE
          value: hogehoge

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: hoge-ingress
  namespace: hoge-namespace
  annotations:
    kubernetes.io/ingress.global-static-ip-name: hoge-ipaddress
spec:
  rules:
  - host: hoge.example.com
    http:
      paths:
      - backend:
          serviceName: hoge-api
          servicePort: 8080

使用Helm进行部署
类似于helm install –name NGINX-ingress的方式

让我们尝试设置ExternalName

只使用中文进行描述，只需要一个选项：GKE的Ingress无法进行设置。可以使用服务的CNAME（也可以使用IP）进行设置，就像DNS的名称解析一样，为服务提供一个接口。

GKE等供应商的解决方法在一定程度上是模板化的，容易上手，但无法进行细致的配置。
而使用NGINX Ingress可以进行相当精细的配置，可以满足特定需求。
我认为在运维进入一定阶段后会变得必要。

将Kubernetes和Nginx结合起来实现高效的自动扩展。

公司名称：想要公司
演讲者：基础设施小组田中篤志先生
幻灯片：https://speakerdeck.com/bgpat/kubernetes-and-nginx下的自动扩展

据说在Wantedly株式会社，他们在没有提供者提供的托管服务（如GKE或EKS）的时代就已经开始使用Kubernetes，并且我们也有机会听到从那个时期到现在的运营和发展过程的故事。

在Wantedly平台上的服务开发

依然是微服务

    • いろんな言語

もともとRubyだった

1クラスターKubernetesクラスタに複数のサービス

リソースが足りないため、複数クラスターの管理は向かないと判断している

約100個のマイクロサービス

上記のクラスターにすべて載っている

各エンジニアが開発からデプロイまで行う

リリースサイクルにインフラエンジニアが絡んでくることはない

使用Nginx实现自动扩展

為了符合負載要求，首先通過Kubernetes的標準功能實現了自動擴展，希望增加伺服器。

    • Horizontal Pod Autoscaler(HPA)

 

    • CPU負荷が高い -> pd(サーバー)を増やす

 

    • 本当にヤバいときは有効

 

    少しリクエストが多いくらいだと何も起きない

寻求更有效率的方法

更为高效的自动扩展

    • Custom Metrics + HPA

CPU & Memory 標準

アプリケーションのメトリクスが使える
Nginxのメトリクスが使えるのでは？

リバプロとしてNginxがすでにPodに入っていた
stub_statusのwritingを処理中のコネクションとしてメトリクス監視している

考虑到上述情况，我们在自动缩放平台上进行了以下操作。

    • 既存のマイクロサービス作成フローに組み込んだ

 

    • エンジニアが必ず使うツールの中を大改修

 

    必ずNginxを入れるようにテンプレート修正

最近情况

    • パフォーマンス改善とコスト削減に貢献

クラウド上で動いているので、リソースの最適化がKubernetes側でよきにしてくれている

ほぼ全てのマイクロサービスに導入された

上述したとおり、約100のマイクロサービスがクラスターにまとまって運用している

なかなか手放せない基盤になっている

元々は限られたサービスで実施しようと思っていたが、多くのマイクロサービスで同様のスケーリングを求められるため結果的に多くのサービスが載っている

困难的事情

    • 他の基盤(GKE/EKSなど)とかに移れない

 

    • そろそろメンテナンスが必要

Kubernetesのアップデートつらい…

其他可供参考的是，据说他们正在使用kops作为配置工具来管理Kubernetes集群。
https://aws.amazon.com/jp/blogs/news/configure-kubernetes-cluster-on-aws-by-kops/

个中感受

在容器运营方面，普及已经比较常见，但是对于Kubernetes来说，似乎还不太普遍。不过，听到此次登台发言的各家企业都有长时间的运营经验，感觉他们已经积累了很多见解。
虽然感觉不太可能以小规模起步，但扩大运营范围可能会享受到更多的优势，我这样想。
对于我们公司来说，仍处在PoC阶段，所以我希望能够继续跟进并在有机会的时候进行尝试。

✖
广告
将在 10 秒后关闭
bannerAds