2019年，我作为IBM的员工参与了Kubernetes的推广和提案活动（与业界人士交流、进行海外出差、阅读英语和日语文档，发表演讲，撰写书籍和博客）。但是，我写下的感受并没有进行整理，成为了一个杂乱无章的文章。

注意：這是個人觀點，並不代表所屬公司的立場。

2019年 Kubernetes 的目前状况

Kubernetes是作为CNCF项目开始的，截至2019年12月已经过去了整整四年，参与的公司已经超过了500家，取得了令人瞩目的扩张。不仅是IT业的先进企业在使用上游的Kubernetes进行开发，云服务提供商如AWS、Azure、GCP、阿里巴巴、IBM Cloud等也提供与Kubernetes兼容的服务。此外，可以说到2019年底时，已经出现了以Kubernetes作为核心的产品，企业的信息系统用户可以放心地使用，并获得相应的支持。

目前，在Kubernetes上取得成果的日本企业主要是在互联网业务领域经营的公司，如电子商务网站、社交社区、内容提供和广告宣传等。它们的特点可以总结如下。

• ユーザーの多くがスマホやタブレットからアクセスするため同時アクセス数が大きい

 

• ラッシュ時、交通機関のトラブル時、悪天候時など、ピーク性が極めて高い

 

• 新規コンテンツ開始や既存コンテンツ更新が頻繁

 

• 一つのサイトの中に複数のサービスが混在

 

• サイトがアクセスできないと企業ブランドにキズがつくなど、企業価値を左右するため責任重大

 

• ユーザー同士のコミュニティとして、同報通知、チャット、音声通話など多彩なサービス提供

 

ユーザーの行動特性を分析しての広告宣伝配信などが、一つの収益源となっている

在这种企业中，通过利用容器操作平台，成功减轻了服务运营业务的负担，即使与基于虚拟服务器构建的传输基础设施相比。

• ハードウェアや仮想サーバーからアプリケーションを隔離して、可搬性やスケールの容易性を高める

 

• コンテナ化によりアプリケーションの安定性が向上し障害を減らせる

 

• メトリックス、ログなどのモニタリングや分析といった業務を集中管理することで管理工数を削減

 

• コンテナのオーケストレーターは、SDS,SDNなどと連携して、実行基盤構築を自動化

 

• CICDの仕組みと連携して、リリースの自動化や、ロールバックなどが容易になる

 

• サービスメッシュやゼロダウンスケールなどの機能が追加され、マイクロサービス化の敷居が低くなる

 

クラスタの仮想化により、平行開発用やテスト用で、本番と同じ条件の環境構築が容易になる

希望在接下来的阶段，2020年可以看到企业信息系统中Kubernetes的广泛应用。

当情报系统部门在使用Kubernetes作为生产环境时面临的挑战。

根据IDC的调查报告，与云计算和软件产品供应商的期望相反，在企业的信息系统中，Docker容器和Kubernetes的生产环境部署并没有像预期那样受到关注。 在考虑到IDC调查结果[1]的基础上，我们想思考导致这种生产环境部署不进展的原因和挑战。

调查结果概述

根据IDC的调查结果概述，总结出以下的三个主要要点。

• Dockerコンテナは導入構築やテスト/検証に時間を要し、本番運用になかなか移れていない状況

 

• 45.5%が、アップストリームKubernetesを使用し、次いで、19.8%が、RedHat OpenShift を使用

 

オンプレミスが45.5%、IaaSが31.4%、PaaS/CaaSが23.1%となり、IaaSとPaaS/CaaSを合わせると54.5%となり、クラウドサービスを利用する割合が半数。同社が2019年4月に国内の企業及び組織468社に対してアンケート形式で実施。

我感觉企业的信息系统无法迈出实际运作的一步，与我作为现场观察者的感觉相吻合。

调查结果 引入动机

在这个时期，让人感兴趣的是为什么企业的信息系统部门会选择引入Kubernetes。主要的引入动机似乎是在应用程序开发中引入容器，以及将服务运营也转移到Kubernetes上。从参与实践培训的参与者的反应来看，这个调查结果也是可同意的。

1. 提升基础设施的使用效率和降低成本

 

1. 提升应用程序开发者的生产力

 

1. 提高应用程序的可靠性/可用性

 

1. 提高应用程序运营的效率和降低成本

 

加快应用程序开发/发布速度

海外局势（个人理解）

在2019年5月巴塞罗那举办的KubeCon Europe 2019上，我碰巧与一个美国人交谈，他是一家知名的信用卡支付公司信息系统部门的员工。他说他在自己公司没有实际经验，但对Kubernetes非常熟悉，并且对这方面的知识很感兴趣。于是我不禁好奇地问道：“既然你对Kubernetes这么了解，为什么不引入它呢？”他回答说：“因为修改现有系统并不合适，我想要的是一次能够应用新系统构建的机会。现在我只是在进行信息收集。”虽然这个故事并不代表全部情况，但考虑到日本的背景，我认为很多用户企业都会像他一样对信息收集感兴趣。

就话题转换而言，我列举了CNCF在2018年为2400人对象所进行的调查报告[2]中的一些有趣点。

• 導入前のリリースサイクル 1〜2回／年であった。Kubernetes導入後は、毎週(20%)、毎月(18%)、毎日(15%)、随時(14%)に増えた。

 

• リリースの方法として、自動化されている(42%)、手作業(27%)、自動と手動のハイブリッド(25%)となっている。

 

• リリースのツールは、Jenkins (70%), Terraform(27%)

 

• Kubernetesクラスタのノード数 6〜20 (16%), 21〜50(14%),51-100(11%)

 

調査対象者が、どこでKubernetesを使っているか? パブリッククラウド(77%), オンプレミス(64%),プライベートクラウド(50%)

尽管这只是一些片段信息，但为了满足希望缩短和频繁进行发布周期的需求，Kubernetes被引入并使用CI工具进行自动化。这样，系统规模大约占据了节点数量为6至100的40%。

阻碍日本企业信息系统引入容器的原因。

我认为，通过与日本企业的信息系统人员分享了关于Kubernetes和容器化引入的问题，我们发现以下这些挑战存在。

• 企業情報システムでは、コンテナを適用するのに適切な新規アプリケーション開発が、たくさん有る訳ではない

 

• 既存システムのモダナイズでは、これまで積み重ねた実績のある運用を、コンテナに合わせて変更することが困難である。

 

• 既存システムのサーバー運用とコンテナ運用では、考え方が大きく異なるが、懸念事項を払拭できないために開始できない。

 

• コンテナの運用は、社内エンジニアがOSSを組み合わせて構築するなど、企業情報システムに馴染みのないカルチャーがある。

 

• 企業情報システムでは、アプリケーションごとに担当するベンダー決まっており、ベンダーの能力によってはコンテナ化が進まない。

 

アプリケーションの開発を外部委託する場合、CICDは予算内で要件を満たせるかの見積もりが難しいため、採用が難しい。

与互联网企业相比，企业的信息系统部门并没有意识到使用容器的必要性。并且，外部依赖的特性似乎使容器的使用无关紧要。然而，从海外案例可以看出，结合DevOps的实践引入容器可以减轻发布的负担，从而改善企业的敏捷性。

容器化推进研究失败案例

我想提到我在与一家大型企业信息系统负责人交流中了解到的关于Kubernetes和容器部署问题的”容器推广失败案例”。

云原生技术是基于对过去的反省而开发出来的一种技术，它是一种能够获得显著效果的技术。然而，它并不是万能的，也存在着未成熟的方面。因此，有必要仔细考虑应该选择哪种适合的应用程序作为目标。此外，若没有实践DevOps或CICD，就无法理解引入容器的好处。如果仍然沿用现有的传统应用开发和服务器运维方式，那只会增加运维的工作量，并无法取得成果。进一步地，应该关注提高应用开发生产率和减轻系统运营人员负担，而不应陷入竞争产品之间毫无意义的功能比较中。

将所列举的失败案例简洁地总结并以条目形式呈现。

• 複雑で依存関係が多いステートフルなワークロードを適用対象に選定する

 

• 十分なCI/CDやDevOpsの経験がないまま検討を進める

 

• クラウドネイティブの考え方を学ばず、現状の運用の考え方に当てはめようとする

 

アプリ開発者とシステム運用者が参画せず、ツールの機能比較で検討が進む

提议在企业信息系统中引入K8s的路线图。

我想从我对Kubernetes推广的经验中，提出一个关于企业信息系统部门如何推动容器化并在Kubernetes上进行生产运营的普遍共通的路线图。

我认为，尽管Kubernetes是一种划时代的工具，但众所周知，在实际应用中学习成本很高。因此，我认为逐步深入相关人员的理解是非常重要的。

在企业内学习并掌握有关容器开发和运维的技术技能。

考虑Docker容器和Kubernetes的价值，获取学习动机的第一步是具体了解。接下来列举应该首先学习的关键技术关键词。

• Dockerコンテナ

 

• Kubernetes

 

• GitHubなどのGitリポジトリ

 

DockerとKubernetesの間をつなぐ、コンテナレジストリ

在第二阶段中，通过利用被称为DevOps和CICD的词语来表达，积累了在应用程序开发方面利用工具进行开发经验。

认为应用程序开发人员能够理解并始终保持积极性对于成功引入Kubernetes至关重要。对开发人员来说，引入Kubernetes的价值在于为执行CICD工具提供基础。具体而言，重要的是能够自动化从编辑代码、提交和推送到Git仓库，再到部署到测试环境的过程。

通过利用代码仓库作为起点，推进应用开发的日常工作自动化，可以具体理解容器的方便性和适当使用方法。

1. 应用程序的源代码在代码仓库如GitHub或GitLab中进行管理。

 

1. 开发团队成员利用代码仓库进行任务跟踪、代码修复请求和利用分支进行修复代码的质量检查。

 

1. 将代码仓库与集成工具（如Jenkins）进行协作，进行代码修复后的代码规范检查、自动构建和简单测试。

 

1. 扩展集成工具的应用范围，自动化容器构建和代码仓库注册。

 

1. 在集成工具的构建过程中，扩展软件模块的漏洞检查等检查。

 

1. 在容器仓库中进行漏洞检查。

 

自动部署和测试执行到测试环境。

推动容器化应用的运营基础技能提升阶段-3。

在快速掌握所需技能方面，云计算也是一种便利工具。举例来说，即使条件是必须在本地进行运营，我们也推荐利用云计算来搭建企业系统运营的学习环境。不论是本地运营还是云计算，在构建生产环境并运营系统时，按照指标、日志分析和事件通知的顺序提升所需本地运营技能是明智的。

1. 度量衡监控：管理CPU和内存的使用率，网络数据包的接收和发送量，以及流量中错误的发生率等。

 

1. 日志分析：集中管理应用程序、中间件和基础设施输出的消息和日志文件，并获得日志分析工具的技能。

 

事件通知：将度量衡管理和日志分析工具与事件通知系统以及事故跟踪工具等进行协调。

如果要将传统的Web应用程序容器化并运行，有时候不能取消传统负载均衡器使用Cookie进行会话固定化的功能。在这种情况下，可能需要考虑同时使用Ingress控制器。

1. 在本地部署方案中，可以与HA-Proxy和NGINX Ingress控制器进行协作。

 

1. 在云服务中，可以使用云服务的负载均衡器、应用程序负载均衡器等。

 

作为对无状态的对比，可以使用云的缓存服务或在Kubernetes上构建Redis集群的方法。

Kubernetes的一个重要功能之一是能够在一个集群上以虚拟化的方式共存多个应用程序的执行环境，从而避免浪费硬件和虚拟服务器的计算资源。然而，在积累足够的技术知识之前，不建议进行共存利用。为了在一个Kubernetes集群上构建多个环境，需要具备以下理解。

1. 将配置信息和保密性信息保存在命名空间中的概念。

 

1. 命名空间(Name Space)和资源使用的默认值、上限值的设置方法。

 

1. 针对每个命名空间的服务帐户、角色基准的访问控制(RBAC)与用户帐户的对应关系。

 

通过群集网络和命名空间进行访问控制。（例如，在命名空间A和B之间的访问禁止和允许等技能）

在将Kubernetes集群应用于企业信息系统时，无法避免数据库服务器的问题。在云环境中，通过使用云服务的数据库可以摆脱数据库运维的负担。然而，在本地环境中使用Kubernetes集群时，无法回避这个问题。

然而，在另一方面，可以在Kubernetes上简单地将SQL数据库容器作为高可用配置运行，但在此过程中需考虑以下因素。

• Kubernetesのコンテナは、一般に随時停止できる一時的な存在として扱われるが、SQLデータベースのソフトウェアは、データを保持するステートフルなコンテナであるため、特別な注意を払って運用する必要がある。

 

• 一般的なSQLデータベースでは、ACID特性を維持するために、アクティブ・スタンバイのHA構成が必要とされ、Kubernetesクラスタ外部に、データ保全性が担保されたストレージ装置と連携させる必要がある。

 

• コンテナとストレージ装置の接続プロトコルの理由により、I/O性能は、物理サーバーほど高く出来ないないため、高いTPSを要求される用途には向かない。物理サーバー同等のトランザクション性能は出ないことを念頭におく必要がある。

 

Kubenetesのコントローラーの一つ Statefulsetが適しているが、制約もあるので、Deploymentの適用も考慮する。

阶段-4 在将微服务应用于企业信息系统时需考虑的因素

微服务是将系统按照预算结算的组织单位进行细分，以提高其自治性，从而减少预算限制和系统间协作的限制，加快服务功能的改进效果。此外，通过使用多个隔离的微服务来构建服务，可以提高系统的可用性。换句话说，由于部分故障不会波及到其他系统，因此可以避免整个系统停止运行。庞大的企业系统因其规模庞大且具有多种接口而复杂且难以理解。因此，雇佣新人并使其在第一线发挥作用可能需要数年时间。相比之下，小而细分的微服务可以更早地使人才变为战斗力。

具备这种特性的微服务对于提供互联网门户网站等服务的企业来说具有巨大的优势，但对于将大型企业的核心系统进行微服务化来说，也存在很多障碍。我想通过我的经验来举个例子。

• 製造業や金融業など、大企業の基幹システムをマイクロサービス化は、高いスキルの人材、長いプロジェクト期間、膨大なコストが必要なことが予想され推進を賛成するものは少ない。

 

• 情報システム依存度が高いとされる航空業界の基幹システムは、重要なサブシステムごとに分割され、相互にメッセージングで疎結合化されているため、全体障害を回避すると共に、部分的な移行が可能となっていることから、基幹システムを改めてマイクロサービス化する必要性は無いかもしれない。

 

ECサイトの普及によって、取り扱い量が年々増える宅配便サービスは、膨大な量の荷物を処理する物流の自動化装置からのトラッキング情報、貨物の配送経路処理など、強力なトランザクション性能を主とするワークロードであることから、コンテナに適さない。

然而，列出的核心系统都通过与智能手机应用程序的连接，使我们的生活更加便利和舒适，包括网上银行、机票预订、办理手续、快递收发等。因此，在基础系统周围，通过智能手机向普通消费者提供服务，我认为采用微服务架构进行系统设计，以快速提高便利性是可取的。

第五阶段 实践

如果能在情报系统部门内讨论关于阶段-4的考虑点，就能够以适当的方法应用Kubernetes。接下来只需要具体实施并积累经验即可。

关于OpenShift的概述和特点

由于IBM收购了Redhat公司，它从积极推荐OpenShift的立场上发生了改变。因此，我们需要总结一下使用OpenShift的原因。

CNCF的Kubernetes每年发布三个次要版本，并支持前两代，因此可以持续支持约8个月。之后，只有在发现错误或漏洞时，才会应用于后续的发布版本。换句话说，用户必须每8个月进行版本升级。这些由CNCF分发的源代码和二进制代码称为上游Kubernetes，意味着在供应商开始产品化之前，就是这么被称呼。目前处于快速发展阶段，不应该阻碍其发展势头。这也是很多人的观点。因此，不存在LTS（长期支持）版本这样的东西。

如果在企业的信息系统中应用Kubernetes，每8个月进行一次版本升级将会成为一项艰巨的负担。能够解决这种问题的是Red Hat提供的OpenShift。Red Hat的员工作为Kubernetes的开发者积极参与其中，可以通过参考他们的Git存储库来了解更多信息。OpenShift不仅被Red Hat使用，而且在促进Kubernetes的发展方面做出了许多贡献。因此，可以期待Kubernetes的先进功能会更早地实现产品化。

OpenShift是由红帽公司自主扩展并应用于易用性和长期支持的Kubernetes，也被称为下游的Kubernetes。

此外，OpenShift的企業解決方案不僅止於此。

前面提到了通过利用Kubernetes的特性来进行部署时，DevOps的重要性，但是DevOps的工具大多是开源软件。对于平时不使用开源软件的软件技术人员来说，使用这些开源软件组合的门槛相对较高。为了解决这个问题，OpenShift为我们提供了解决方案。也就是说，即使在信息系统部门，通过OpenShift内置的工具，降低了技术门槛，让我们更容易地在Kubernetes环境中开始使用DevOps。进一步地，我们也可以预期与Jenkins的结合，实现更全面的应用。

企业信息系统面临的重要问题始终是安全性。对于以Linux为中心并使用开源软件的人来说，必须要重视漏洞修复。Red Hat公司的Linux是企业级Linux，在漏洞修复方面非常重视，并与美国的信息安全机构合作，提供及时的漏洞修复补丁而闻名。通过使用Red Hat Enterprise Linux作为容器的基础镜像，可以获得比通常使用的容器基础镜像更高级的漏洞支持。

如果企业在其信息系统中选择使用Kubernetes，那么可以说OpenShift是非常重要的工具。

• CICDツール+レジストリサービスと統合されたKubenetes+DevOps環境

 

• 長期間のサポートが受けられるKubernetesプラットフォーム

 

RHELの脆弱性サポートを受け継ぐ、企業向けセキュリティサポート

关于 IBM 正在进行的 IBM Cloud Paks 领域的努力。

在收购 Red Hat 公司之前，IBM 就已经提供了一款名为 IBM Cloud Private 的产品，该产品在客户端使用 Kubernetes，并添加了附加功能，可以安装在 Ubuntu Linux 或 RHEL 上。在这个平台上，可以使用 IBM 的传统中间件（如 WebShphere Liberty 和 Message Broker）等容器。

然而，就企業信息系統產品而言，這個產品並不完善。換句話說，它的核心是使用上游的Kubernetes，需要解決前述的問題。

通过收购 Red Hat，OpenShift 和 IBM 的中间件产品结合在一起，IBM Cloud Paks 成为了一款适用于企业信息系统的产品。这样一来，我们得到了一个更全面的企业信息系统解决方案，包含 Kubernetes 和中间件的组合。

IBM Cloud Paks具有多个软件包，它们都在同一个OpenShift平台上运行，因此可以期望减少运维管理的工作量。通过OpenShift，可以提供对Kubernetes的长期支持，并在其上运行中间件和其他软件产品，这些产品都是通过容器提供的。因此，版本升级、监控和日志分析等工作可以被共享。此外，作为Kubernetes的工作节点，可以重复使用，避免了对企业信息系统的投资浪费。

1. 应用开发和运营环境

 

1. 数据的收集、整理、分析的整合和简化

 

1. API管理、消息和事件、快速传输的集成

 

1. 业务流程的自动化

 

1. 多云管理、边缘管理

 

安全工具的整合

作为IBM的新举措，IBM Cloud Paks Applications将包含开发中的开源软件（OSS）DevOps工具Kabanero。该特点在于开发人员可以自由选择开发环境，也就是说，可以通过Eclipse、Visual Studio Code和命令行进行使用。此外，它还能生成在Kubernetes环境中执行所需的脚手架（Scaffold）代码。

在Kubernetes的执行环境中，容器应该包含功能要求。让开发者亲自查找这些功能并确保代码正确实现，无疑会对生产力造成负面影响。为了解决这样的问题，名为Kabanero的开源工具可以根据开发者的开发语言和框架选择生成适合的代码模板。

例如，在Java中，我们可以利用Microprofile和Spring框架来生成脚手架代码。这些脚手架代码包含了构建容器所需的Dockerfile和Kubernetes Operator的YAML等内容，即使是对Kubernetes经验较少的开发者也能高效地开发基于Kubernetes运行的容器化应用程序。此外，开发还推动了与CI工具的集成，不仅脚手架代码，连同CICD流水线的生成也有望自动化。

Java作为企业信息系统的开发语言，是一个核心存在，可以有效利用这些信息系统资产，以适应下一代的需求。这个开源软件不仅支持Java，还在不断推进对Python、Node.js、Rust等编程语言和框架的支持。

OpenShift 是一个适用于企业的 Kubernetes 强大的容器运行环境，可以被视为未来的操作系统。而 IBM Cloud Paks 则是在其基础上构建的综合环境，用于支持企业信息系统的开发和运营。

请提供的参考网址。

• [1] DockerコンテナとKubernetesの導入率は微増 – IDCの調査, https://news.mynavi.jp/article/20190704-853537/

[2] CNCF Survey: Use of Cloud Native Technologies in Production Has Grown Over 200%, https://www.cncf.io/blog/2018/08/29/cncf-survey-use-of-cloud-native-technologies-in-production-has-grown-over-200-percent/