コンテナアプリケーションを使用している場合、あなたはまだこれらのベストプラクティスに従ってください？
Kubernetesを使用すると、最小限またはゼロダウンタイムのために、ITコストを最適化する、ビジネスを展開し、システムの信頼性を高めるために、自動化と需要ことができます。
実行中のアプリケーションのKubernetesの場合、コンテナは、その中核です。あなたは（つまり、スケジューリング、拡張のために使用され、ルールアプリケーションのアップグレードされた）Kubernetesのワークロードを作成するときは、実行中のコンテナミラーリングサービスやKubernetesのワークロードを開始します。試験群とアプリケーションの統合のコード画像の残りの後、それは通常、コンテナストアにプッシュされます。あなたがサービスと時間のそのコンテナを書くときしかし、このポイントの前に、心に留めておくために多くのベストプラクティスがあります。
1、最新のKubernets型に追いつくために
新機能のKubernetsの継続的なリリースでは、Kubernetesの使用パターンが変更されることがあります。クラスタが最近設立Kubernetesの使用パターンに従っていることを確実にするために、我々はあなたがそれを公式のKubernetesの文書に従い、定期的な読書することをお勧めします。各Kubernetesリリースにおける変更の導入についてだけではなく、心配し、これらの変更をで、リリースノート（リリースノート）に反映。
時間保存ベースイメージを使用して2、
アプリケーションコンテナKubernetesを作成するクラスタドッカー基本イメージを構築することを含む、基部またはコンテナアプリケーションのすべてに基づいて、画像構築します。多くのアプリケーション共有の依存関係、ライブラリと設定するので、再利用が可能な構成をミラーリングすること、ベースイメージを使用してください。
ドッカーハブとGoogleコンテナレジストリをダウンロードするために使用されているベースイメージを取り、数千を持っています。あなたの事前構成されたベース画像にこれらのアプリケーションを使用することによって、あなたは多くの時間を節約することができます。
図1は、ベース画像とアプリケーションとの関係を示す図に示すように。
ベース画像との間の関係のアプリケーション。1つのUbuntu
3、ランダムに選ばれたベースイメージを信用していない、常に脆弱性スキャンを使用
事前に構築された画像の使用は非常に簡単ですが、しかし、安全性を確保するだけでなく、確認するために、あなたが実行されたすべての最初のいくつかの脆弱性スキャンです。
一部の開発者は、一目見ただけで、このパッケージは、彼らが必要とする基本イメージを持っているので、他の人は、ドッカーハブからベースイメージを作成するために取得します。その後、彼らは、本番環境にプッシュランダムに選択されたコンテナを置きます。
これは間違っています。使用しているコードのバージョンは、悪用される可能な脆弱性を有していてもよく、さらに悪いことに欠陥がある可能性があり、それは悪意のあるソフトウェアの目的を縛られた可能性があります。そして、あなたはそれを知らないかもしれないけれども。
リスクを軽減するには、静的解析ツール（例えばSnykまたはツイストロック）を使用すると、脆弱性のためのすべてのコンテナをスキャンするために継続的な統合と継続的デリバリパイプラインに統合することができます。
以下は、一般的なルールです：あなたはベースイメージで抜け穴を見つけない場合は、だけでなく、そのパッチのために、それを再構築する必要があります。コンテナは不変でなければなりません。そのため、実際には、パッチを使用することです最高のミラーを再構築するために含まれ、その後、再展開イメージされています。
図4に示すように、ベース画像の最適化
ほとんどの合理化、可能な最小のベースイメージスタートから、それの上にあなたのパッケージをビルド。このように、あなたは正確に知っている、内部のあなたのコンテナ内の何かがあります。
小さいベースイメージもオーバーヘッドを削減するのに役立ちます。あなたが直接（例えばNode.jsのような）既製の画像に上記に追加だけでなく、ライブラリ全体が含まれている場合、アプリケーションは唯一の5メガバイト、しかし、その後、あなたは追加のライブラリを必要としないのget 600メガバイトを終わる可能性があります。
小さなミラーの他の利点は含まれます：
より速く構築する小さなメモリ使用ミラーを引っ張るために、より速くを小さく攻撃面であってもよいです
5、唯一のプロセスでコンテナ内で実行
小型基地画像を維持することに関連する容器で実行唯一のプロセスです。コンテナとそのホストされたアプリケーションは、同じライフサイクルを持っています。これは、各容器は、単一の親プロセス（図2に示す良い例）でなければならないことを意味します。
図2のプロセスモデルの例示的なコンテナ。
Googleクラウドドキュメント（https://cloud.google.com/solutions/best-practices-for-building-containers#package_a_single_app_per_container）によると、仮想マシンなどの容器は、（同時に複数のプロセスを実行することができます）よくある間違いです。それは、このように容器に使用することができるが、それはKubernetes（自己修復性）の治癒特性を使用していませんでしたが。
请记住，容器和应用这二者应该在同一时刻启动；相应的，当应用停止运行的时候，容器也应该停止运行。如果在一个容器中有多个进程，那么你可能会遇到这样的情况：应用的状态是不一样的，这会导致Kubernetes无法判断容器是否是健康的。
6、正确的处理Linux信号
Linux信号用于控制容器内进程的生命周期。为了把应用和容器的生命周期链接在一起，你需要确保应用正确的处理了Linux信号。
Linux信号，例如SIGTERM、SIGKILL和SIGINIT，用于在内核中终止进程。但是，容器中的Linux以不同的方式执行这些常见的信号。默认情况下，它们不能按预期工作，这导致错误和中断写入。
解决这种问题的方法之一是，使用一种特殊化的init系统，例如适用于容器的Linux Tini。Linux Tini这个工具会正确的注册信号处理器（例如PID），这样一来，对于容器化的应用来说，Linux信号也可以正常工作了，而且能够优雅的关闭孤立进程和僵尸进程以回收内存。
7、利用Docker构建缓存顺序
容器镜像是使用模板或者Dockerfile中的指令以一系列层的方式构建的。层以及层构建的顺序通常被缓存在容器平台上。例如，Docker就有一个构建缓存，它用于层的复用。这种缓存使你构建更快，但是只有在这种情况下你才能够使用到它：以前构建中用到的所有前置层都是存在的。
例如，你有个构建文件，其中有步骤X、步骤Y和步骤Z。你对步骤Z做了变更。在这种情况下，构建文件会复用缓存中的步骤X和步骤Y，因为在你修改的层（步骤Z）之前的那些层（步骤X和步骤Y）都是存在的。这就加速了构建，节省了一些时间。但是，如果你仅仅改变了步骤X，那么缓存将不会包含其后的任何步骤和层。
虽然这很方便而且节省了时间，但是你必须确保所有的层都是最新的以及它们不是从更老的过时的缓存中拉取出来的。
8、使用类似Helm的包管理器
作为Kubernetes非官方的包管理器，Helm是获取和更新运行在集群上的常见工作负载和容器的另一个可选方案。Helm使用chart来声明依赖项，并提供了滚动升级和回滚的工具。
对于你希望在Kubernetes集群中提供的通用服务来说，你可以利用已存在的基础镜像。这些通用服务的例子包括数据库和Web服务器。对于你的内部应用来说，你可以创建定制化的基础镜像。创建你自己的chart会简化部署，减少开销，减少开发团队的重复工作。
可以参考文章“Managing Helm Releases the GitOps Way”（https://www.weave.works/blog/managing-helm-releases-the-gitops-way）来学习Helm是如何工作的。
9、使用标签（tag）和语义版本
请记住，你不应该使用:latest标签。对大部分开发者来说，这是显而易见的事情。但是，如果你没有为容器添加一个定制的标签，那么将永远会尝试从仓库中拉取最新的一个。那个最新的容器可能会也可能不会包含有你认为应该有的变更。
在创建定制化的镜像时，使用镜像标签和语义版本化来追踪对Docker容器的变更。当它们运行在Kubernetes里面时，镜像标签用于表达出你希望运行在Kubernetes集群中的镜像版本是什么。为了最优化的使用Kubernetes，在选择Docker镜像版本化方案时，要同时考虑生产工作负载和开发流程。
10、聪明的管理秘钥
在很多构建Docker镜像的案例中，你需要授权运行在容器中的应用访问敏感数据。那些敏感数据包括API令牌、私钥和数据库连接字符串。
把那些秘钥嵌入到容器中不是一个安全的解决方案，即使在你保持镜像处于私有状态的情况下。把未加密的秘钥作为Docker镜像的一部分推送出去让你暴露在各种额外的安全风险之下，例如网络和镜像仓库的安全等。Docker架构本身并没有为容器中存放未加密敏感数据而做优化。
相反，最容易的安全的在容器外存储秘钥的方式是使用Kubernetes秘钥对象（https://kubernetes.io/docs/concepts/configuration/secret/）。
Kubernetes提供了Secrets抽象来让你在Docker镜像外或者pod定义之外存储秘钥。你可以以在容器内挂载卷的方式来使用Kubernetes秘钥，或者以环境变量的方式来使用它。当你更新Kubernetes Secrets中的秘钥值的时候，只要滚动服务的pods即可开始使用新的凭据。也有一些其他的存储秘钥的选项存在，例如Hashicorp Vault和 Bitnami密封秘钥（https://www.weave.works/blog/storing-secure-sealed-secrets-using-gitops）。
原文链接：https://dzone.com/articles/10-tips-for-building-and-managing-containers