一. 介绍

每个依赖管理解决方案都必须解决选择依赖项版本的问题。当前存在的许多版本选择算法都试图识别任何依赖项的“最新最大(latest greatest)”版本。如果您认为语义版本控制(sematic versioning)将被正确应用并且这种社会契约得到遵守，那么这是有道理的。在这样的情况下，依赖项的“最新最大”版本应该是最稳定和安全的版本，并且应与较早版本具有向后兼容性。至少在相同的主版本(major verion)依赖树中是如此。

Go决定采用其他方法，Russ Cox花费了大量时间和精力撰写文章和演讲探讨Go团队的版本选择方法，即最小版本选择或MVS(Minimal Version Selection)。从本质上讲，Go团队相信MVS为Go程序实现痴线持久的和可重复的构建提供了最佳的方案。我建议大家阅读这篇文章以了解Go团队为什么相信这一点。

在本文中，我将尽最大努力解释MVS语义，展示一个实际的Go语言示例，并实际使用MVS算法。

二. MVS语义

将Go的依赖项版本选择算法命名为“最小版本选择”是有点用词不当，但是一旦您了解了它的工作原理，您会发现这个名称真的很贴切。如我之前所述，许多选择算法会选择依赖项的“最新最大”版本。我喜欢将MVS视为选择“最新非最大(latest non-greatest)”版本的算法。并不是说MVS不能选择“最新最大”，而是只要项目中的任何依赖项都不需要“最新最大”，那么就不需要该版本。

为了更好地理解这一点，让我们创建一种情况，其中几个module（A，B和C）依赖于同一module（D），但是每个module都需要不同的版本。

上图显示了module A，B和C如何分别独立地需要module D和各自需要D的不同版本。

如果我启动一个需要module A的项目，那么为了构建代码，我还需要module D。module D可能有很多版本可供选择。例如，假设module D代表sirupsen的logrus module。我可以要求Go向我提供module D所有已存在（打tag)的版本列表。

清单1：

$ go list -m -versions github.com/sirupsen/logrus

github.com/sirupsen/logrus v0.1.0 v0.1.1 v0.2.0
v0.3.0 v0.4.0 v0.4.1 v0.5.0 v0.5.1 v0.6.0 v0.6.1
v0.6.2 v0.6.3 v0.6.4 v0.6.5 v0.6.6 v0.7.0 v0.7.1
v0.7.2 v0.7.3 v0.8.0 v0.8.1 v0.8.2 v0.8.3 v0.8.4
v0.8.5 v0.8.6 v0.8.7 v0.9.0 v0.10.0 v0.11.0 v0.11.1
v0.11.2 v0.11.3 v0.11.4 v0.11.5 v1.0.0 v1.0.1 v1.0.3
v1.0.4 v1.0.5 v1.0.6 v1.1.0 v1.1.1 v1.2.0 v1.3.0
v1.4.0 v1.4.1 v1.4.2

清单2显示了module D存在的所有版本，我们看到其中显示的“最新最大”版本为1.4.2。

该项目应选择哪个版本的module D呢？确实有两种选择。首选是选择“最新的”版本（在主要版本为1的这一行中），即v1.4.2。第二个选择是选择module A所需的版本v1.0.6。

像dep这样的依赖工具将选择v1.4.2版，并在语义版本化和遵守社会契约的前提下可以正常工作。但是，考虑到Russ Cox在这里阐述的一些原因，Go会尊重module A的要求并选择版本1.0.6。在需要module的项目的所有依赖项的当前所需版本集合中，Go会选择“最小”版本。换句话说，现在只有module A需要module D，而module A已指定它要求的版本为v1.0.6，所需版本集合中只有v1.0.6，因此Go选择的module D的版本即是它。

如果我引入要求项目导入module B的新代码时会怎样？将module B导入项目后，Go会将项目的module D版本从v1.0.6升级到v1.2.0。Go再次在项目依赖项module A和B的当前所需版本集合(v1.0.6和v1.2.0)中选择了module D的“最小”版本。

如果我再次引入需要项目导入module C的新代码时会怎样？Go将从当前所需版本集合（v1.0.6，v1.2.0，v1.3.2）中选择最新版本（v1.3.2）。请注意，版本v1.3.2仍然是module D（v1.4.2）的“最小”版本，而不是“最新最大”版本。

最后，如果删除刚刚添加的依赖module C的代码会怎样？Go会将项目锁定到module D的版本v1.3.2上。降级到版本v1.2.0将是一个更大的更改，而Go知道版本v1.3.2可以正常并稳定运行，因此版本v1.3.2仍然是module D的“最新但非最大(latest non-greatest)“版本。另外，module文件(go.mod)仅维护快照，而不是日志。没有有关历史撤消或降级的信息。

这就是为什么我喜欢将MVS视为选择“最新非最大(latest non-greatest)”module 版本的算法的原因。希望您现在可以理解为什么Russ Cox在命名算法时选择名称“minimal”。

三. 示例项目

有了上述基础，我将用一个示例项目让你看到Go和MVS算法实际是如何工作的。在此项目中，module D将用logrus module代表，而该项目将直接依赖于rethinkdb-go（moduleA）和golib（moduleB）module。rethinkdb-go和golib module直接依赖logrus module，并且每个module都需要一个不同的logrus版本，并且这些版本都不是logrus的“最新”版本。

上图显示了三个module之间的独立关系。首先，我将创建项目，初始化module，然后加载VS Code。

清单2：

$ cd $HOME
$ mkdir app
$ mkdir app/cmd
$ mkdir app/cmd/db
$ touch app/cmd/db/main.go
$ cd app
$ go mod init app
$ code .

清单2显示了所有要运行的命令。运行这些命令后，以下代码应出现在VS Code中。

上图显示了项目结构和module文件应包含的内容。有了这个，现在该添加使用rethinkdb-go module的代码了。

清单3：

https://play.golang.org/p/bc5I0Afxhvc

01 package main
02
03 import (
04     "context"
05     "log"
06
07     db "gopkg.in/rethinkdb/rethinkdb-go.v5"
08 )
09
10 func main() {
11     c, err := db.NewCluster([]db.Host{{Name: "localhost", Port: 3000}}, nil)
12     if err != nil {
13         log.Fatalln(err)
14     }
15
16     if _, err = c.Query(context.Background(), db.Query{}); err != nil {
17         log.Fatalln(err)
18     }
19 }

清单3引入了rethinkdb-go module的major版本v5。添加并保存此代码后，Go会查找、下载和提取module，并更新go.mod和go.sum文件。

清单4：

01 module app
02
03 go 1.13
04
05 require gopkg.in/rethinkdb/rethinkdb-go.v5 v5.0.1

清单4显示了go.mod需要rethinkdb-go module作为直接依赖项，并选择了v5.0.1版本，该版本是该module的“最新最大版本”。

清单5：

...
github.com/sirupsen/logrus v1.0.6 h1:hcP1GmhGigz/O7h1WVUM5KklBp1JoNS9FggWKdj/j3s=
github.com/sirupsen/logrus v1.0.6/go.mod h1:pMByvHTf9Beacp5x1UXfOR9xyW/9antXMhjMPG0dEzc=
...

清单5显示了go.sum文件中引入logrus module v1.0.6版本的两行。在这一点上，您可以看到MVS算法已经选择了满足rethinkdb-go module指定要求所需的logrus module的“最小”版本。记住logrus module的“最新最大”版本是1.4.2。

注意：go.sum文件不应用于理解依赖关系。我在上面所做的版本确定的操作是错误的，稍后我将向您展示确定项目所使用的版本的正确方法。

上图显示了Go将使用哪个版本的logrus module来构建项目。

接下来，我将添加引入对golib module有依赖关系的代码。

清单6：

https://play.golang.org/p/h23opcp5qd0

01 package main
02
03 import (
04     "context"
05     "log"
06
07     "github.com/Bhinneka/golib"
08     db "gopkg.in/rethinkdb/rethinkdb-go.v5"
09 )
10
11 func main() {
12     c, err := db.NewCluster([]db.Host{{Name: "localhost", Port: 3000}}, nil)
13     if err != nil {
14         log.Fatalln(err)
15     }
16
17     if _, err = c.Query(context.Background(), db.Query{}); err != nil {
18         log.Fatalln(err)
19     }
20
21     golib.CreateDBConnection("")
22 }

清单6向该程序添加了07和21行行代码。Go查找、下载并解压缩golib module后，以下更改将显示在go.mod文件中。

清单7：

01 module app
02
03 go 1.13
04
05 require (
06     github.com/Bhinneka/golib v0.0.0-20191209103129-1dc569916cba
07     gopkg.in/rethinkdb/rethinkdb-go.v5 v5.0.1
08 )

清单7显示go.mod文件已被修改为包括golib module的“最新最大”版本依赖关系，该版本恰好没有语义版本标签。

清单8：

...
github.com/sirupsen/logrus v1.0.6 h1:hcP1GmhGigz/O7h1WVUM5KklBp1JoNS9FggWKdj/j3s=
github.com/sirupsen/logrus v1.0.6/go.mod h1:pMByvHTf9Beacp5x1UXfOR9xyW/9antXMhjMPG0dEzc=
github.com/sirupsen/logrus v1.2.0 h1:juTguoYk5qI21pwyTXY3B3Y5cOTH3ZUyZCg1v/mihuo=
github.com/sirupsen/logrus v1.2.0/go.mod h1:LxeOpSwHxABJmUn/MG1IvRgCAasNZTLOkJPxbbu5VWo=
...

清单8显示了go.sum文件中的四行，现在包括logrus module的v1.0.6和v1.2.0版本。查看go.sum文件中列出的两个版本会带来两个问题：

• 为什么在go.sum文件中列出了两个版本？
• Go执行构建时将使用哪个版本？

Go团队的Bryan Mills很好地回答了go.sum文件中列出两个版本的原因。

“go.sum文件仍包含旧版本（1.0.6），因为其传递依赖的要求可能会影响其他module的选定版本。我们真的只需要为go.mod文件提供校验和，因为go.mod中声明了这些传递要求的内容，但是由于go mod tidy不够精确，最终我们也保留了源代码的校验和。” golang.org/issue/33008

现在仍然存在在构建项目时将使用哪个版本的logrus module的问题。要正确确定将使用哪些module及其版本，请不要查看该go.sum文件，而应使用go list命令。

清单9：

$ go list -m all | grep logrus

github.com/sirupsen/logrus v1.2.0

清单9显示了在构建项目时将使用logrus module的v1.2.0版本。该-m标志指示go list列出module而不是package。

查看module图可以更深入地了解项目对logrus module的要求。

清单10：

$ go mod graph | grep logrus

github.com/sirupsen/logrus@v1.2.0 github.com/pmezard/go-difflib@v1.0.0
github.com/sirupsen/logrus@v1.2.0 github.com/stretchr/objx@v0.1.1
github.com/sirupsen/logrus@v1.2.0 github.com/stretchr/testify@v1.2.2
github.com/sirupsen/logrus@v1.2.0 golang.org/x/crypto@v0.0.0-20180904163835-0709b304e793
github.com/sirupsen/logrus@v1.2.0 golang.org/x/sys@v0.0.0-20180905080454-ebe1bf3edb33
gopkg.in/rethinkdb/rethinkdb-go.v5@v5.0.1 github.com/sirupsen/logrus@v1.0.6
github.com/sirupsen/logrus@v1.2.0 github.com/konsorten/go-windows-terminal-sequences@v1.0.1
github.com/sirupsen/logrus@v1.2.0 github.com/davecgh/go-spew@v1.1.1
github.com/Bhinneka/golib@v0.0.0-20191209103129-1dc569916cba github.com/sirupsen/logrus@v1.2.0
github.com/prometheus/common@v0.2.0 github.com/sirupsen/logrus@v1.2.0

清单10显示了logrus module在项目中的关系。我将直接提取显示对logrus的依赖要求的行。

清单11：

gopkg.in/rethinkdb/rethinkdb-go.v5@v5.0.1 github.com/sirupsen/logrus@v1.0.6
github.com/Bhinneka/golib@v0.0.0-20191209103129-1dc569916cba github.com/sirupsen/logrus@v1.2.0
github.com/prometheus/common@v0.2.0 github.com/sirupsen/logrus@v1.2.0

在清单11中，这些行显示三个module（rethinkdb-go，golib和common）都需要logrus module。由于有了go list命令，我知道所需的最低版本为v1.2.0。

上图展示了Go现在将使用哪个版本的logrus module来构建项目中的代码。

四. Go Mod Tidy

在将代码提交/推回存储库之前，请运行go mod tidy以确保module文件是最新且准确的。您在本地构建，运行或测试的代码将随时影响Go对module文件中内容的更新。运行go mod tidy将确保项目具有所需内容的准确和完整的快照，这将帮助您团队中的其他人和您的CI/CD环境。

清单12：

$ go mod tidy

go: finding github.com/Bhinneka/golib latest
go: finding github.com/bitly/go-hostpool latest
go: finding github.com/bmizerany/assert latest

清单12显示了运行go mod tidy后的输出结果。您会在输出中看到两个新的依赖项。这将更改module文件。

清单13：

01 module app
02
03 go 1.13
04
05 require (
06     github.com/Bhinneka/golib v0.0.0-20191209103129-1dc569916cba
07     github.com/bitly/go-hostpool v0.0.0-20171023180738-a3a6125de932 // indirect
08     github.com/bmizerany/assert v0.0.0-20160611221934-b7ed37b82869 // indirect
09     gopkg.in/rethinkdb/rethinkdb-go.v5 v5.0.1
10 )

清单13显示了go-hostpool和assert module被列为构建项目所需的间接module。之所以在此处列出它们，是因为这些项目当前与module机制不兼容。换句话说，这些项目的任何tag版本或master中“最新的”版本都不存在go.mod文件。

为什么运行go mod tidy后包含了这些module？我可以使用go mod why命令找出答案。

清单14：

$ go mod why github.com/hailocab/go-hostpool

# github.com/hailocab/go-hostpool
app/cmd/db
gopkg.in/rethinkdb/rethinkdb-go.v5
github.com/hailocab/go-hostpool

------------------------------------------------

$ go mod why github.com/bmizerany/assert

# github.com/bmizerany/assert
app/cmd/db
gopkg.in/rethinkdb/rethinkdb-go.v5
github.com/hailocab/go-hostpool
github.com/hailocab/go-hostpool.test
github.com/bmizerany/assert

清单14显示了为什么项目间接需要这些module。rethinkdb-go module需要go-hostpool module，而go-hostpool module需要assert module。

五. 升级依赖关系

该项目具有三个依赖项，每个依赖项都需要logrus module，其中当前正在选择logrus module的v1.2.0版本。在项目生命周期的某个时刻，升级直接和间接依赖关系以确保项目所需的代码是最新的并且可以利用新功能、错误修复和升级安全补丁将变得很重要。要进行升级，Go提供了go get命令。

在运行go get升级项目的依赖项之前，需要考虑几个选项。

使用MVS仅升级必需的直接和间接依赖项

我建议从这种升级开始，直到您了解更多有关项目和module的信息。这是的最保守的形式go get。

清单15：

$ go get -t -d -v ./...

清单15显示了如何使用MVS算法对那些必需依赖项的升级。下面是命令中一些命令行选型的定义。

• -t flag：考虑构建测试所需的module。
• -d flag：下载每个module的源代码，但不要构建或安装它们。
• -v flag：提供详细输出。
• ./… ：在整个源代码树中执行这些操作，并且仅更新所需的依赖项。

对当前项目运行此命令不会导致任何更改，因为该项目已经是最新版本，并且具有构建和测试该项目所需的最低版本。那是因为我刚运行了go mod tidy，项目是新的。

使用最新最大版本仅升级必需的直接和间接依赖项

这种升级会将整个项目的依赖性从“最小”提高到“最新最大”。所需要做的只是将-u标志添加到命令行。

清单16：

$ go get -u -t -d -v ./...

go: finding golang.org/x/net latest
go: finding golang.org/x/sys latest
go: finding github.com/hailocab/go-hostpool latest
go: finding golang.org/x/crypto latest
go: finding github.com/google/jsonapi latest
go: finding gopkg.in/bsm/ratelimit.v1 latest
go: finding github.com/Bhinneka/golib latest

清单16显示了运行带有-u标志的go get命令的输出。此输出无法说明真实情况。如果我问go list命令现在使用哪个版本的logrus module来构建项目，会发生什么情况呢？

清单17：

$ go list -m all | grep logrus

github.com/sirupsen/logrus v1.4.2

清单17显示了如何选择“最新”的logrus。为了使这一选择更加明确，对go.mod文件进行了更改。

清单18：

01 module app
02
03 go 1.13
04
05 require (
06     github.com/Bhinneka/golib v0.0.0-20191209103129-1dc569916cba
07     github.com/bitly/go-hostpool v0.0.0-20171023180738-a3a6125de932 // indirect
08     github.com/bmizerany/assert v0.0.0-20160611221934-b7ed37b82869 // indirect
09     github.com/cenkalti/backoff v2.2.1+incompatible // indirect
10     github.com/golang/protobuf v1.3.2 // indirect
11     github.com/jinzhu/gorm v1.9.11 // indirect
12     github.com/konsorten/go-windows-terminal-sequences v1.0.2 // indirect
13     github.com/sirupsen/logrus v1.4.2 // indirect
14     golang.org/x/crypto v0.0.0-20191206172530-e9b2fee46413 // indirect
15     golang.org/x/net v0.0.0-20191209160850-c0dbc17a3553 // indirect
16     golang.org/x/sys v0.0.0-20191210023423-ac6580df4449 // indirect
17     gopkg.in/rethinkdb/rethinkdb-go.v5 v5.0.1
18 )

清单18在第13行显示版本v1.4.2现在是项目中logrus module的选定版本。构建项目时，Go会注意module文件中的这一行。即使删除了对logrus module的依赖关系更改的代码，该项目的v1.4.2版现在也已被锁定。请记住，降级将是一个更大的变化，而v1.4.2版将不受影响。

go.sum文件中可以看到哪些更改？

清单19：

github.com/sirupsen/logrus v1.0.6/go.mod h1:pMByvHTf9Beacp5x1UXfOR9xyW/9antXMhjMPG0dEzc=
github.com/sirupsen/logrus v1.2.0 h1:juTguoYk5qI21pwyTXY3B3Y5cOTH3ZUyZCg1v/mihuo=
github.com/sirupsen/logrus v1.2.0/go.mod h1:LxeOpSwHxABJmUn/MG1IvRgCAasNZTLOkJPxbbu5VWo=
github.com/sirupsen/logrus v1.4.2 h1:SPIRibHv4MatM3XXNO2BJeFLZwZ2LvZgfQ5+UNI2im4=
github.com/sirupsen/logrus v1.4.2/go.mod h1:tLMulIdttU9McNUspp0xgXVQah82FyeX6MwdIuYE2rE=

清单19显示了go.sum文件中表示logrus的所有三个版本。正如上面的Bryan所解释的，这是因为传递要求可能会影响其他module的选定版本。

上图展示了Go现在将使用哪个版本的logrus module来构建项目中的代码。

使用最新最大版本升级所有直接和间接依赖项

您可以将./…选项替换为all来升级所有直接和间接依赖项，包括构建项目时也并不需要的依赖项。

清单20：

$ go get -u -t -d -v all

go: downloading github.com/mattn/go-sqlite3 v1.11.0
go: extracting github.com/mattn/go-sqlite3 v1.11.0
go: finding github.com/bitly/go-hostpool latest
go: finding github.com/denisenkom/go-mssqldb latest
go: finding github.com/hailocab/go-hostpool latest
go: finding gopkg.in/bsm/ratelimit.v1 latest
go: finding github.com/google/jsonapi latest
go: finding golang.org/x/net latest
go: finding github.com/Bhinneka/golib latest
go: finding golang.org/x/crypto latest
go: finding gopkg.in/tomb.v1 latest
go: finding github.com/bmizerany/assert latest
go: finding github.com/erikstmartin/go-testdb latest
go: finding gopkg.in/check.v1 latest
go: finding golang.org/x/sys latest
go: finding github.com/golang-sql/civil latest

清单20显示了现在为该项目找到、下载和提取了多少个依赖项。

清单21：

Added to Module File
   cloud.google.com/go v0.49.0 // indirect
   github.com/denisenkom/go-mssqldb v0.0.0-20191128021309-1d7a30a10f73 // indirect
   github.com/google/go-cmp v0.3.1 // indirect
   github.com/jinzhu/now v1.1.1 // indirect
   github.com/lib/pq v1.2.0 // indirect
   github.com/mattn/go-sqlite3 v2.0.1+incompatible // indirect
   github.com/onsi/ginkgo v1.10.3 // indirect
   github.com/onsi/gomega v1.7.1 // indirect
   github.com/stretchr/objx v0.2.0 // indirect
   google.golang.org/appengine v1.6.5 // indirect
   gopkg.in/check.v1 v1.0.0-20190902080502-41f04d3bba15 // indirect
   gopkg.in/yaml.v2 v2.2.7 // indirect

Removed from Module File
   github.com/golang/protobuf v1.3.2 // indirect

清单21显示了对该go.mod文件的更改。添加了更多module，并删除了一个module。

注意：如果你使用vendor，则go mod vendor命令将从vendor文件夹中剥离test文件。

通常，通过go get升级项目的依赖项时不要使用all或-u选项。坚持只升级需要的module，并使用MVS算法选择这些module及其版本。必要时手动更改为特定的module版本。手动更改可以通过手动编辑go.mod文件来完成，我将在以后的文章中向您展示。

五. 重置依赖关系

如果您在任何时候都不满意所选的module和版本，则你始终可以通过删除module文件并再次运行go mod tidy来重置选择。当项目还很年轻并且情况不稳定时，这更是一种选择。项目稳定并发布后，我会犹豫重新设置依赖关系。正如我上面提到的，随着时间的推移，可能会设置module版本，并且您需要长期持久且可重复的构建。

清单22：

$ rm go.*
$ go mod init <module name>
$ go mod tidy

清单22显示了允许MVS从头开始再次执行所有选择的命令。在撰写本文的整个过程中，我一直在进行此操作以重置项目并提供本文的代码清单。

六. 结论

在这篇文章中，我解释了MVS语义，并展示了Go和MVS算法实际应用的真实示例。我还展示了一些Go命令，这些命令可以在您遇到未知问题时为您提供信息。在为项目添加越来越多的依赖项时，可能会遇到一些极端情况。这是因为Go生态系统已有10年的历史，所有现有项目都需要更多时间才能符合module要求。

在以后的文章中，我将讨论在同一项目中使用不同主要版本的依赖关系，以及如何手动检索和锁定依赖关系的特定版本。现在，我希望您对module和Go工具有更多的信任，并且对MVS如何随着时间的推移选择版本有了更清晰的了解。如果您遇到任何问题，可以在#module组的Gopher Slack上找到一群愿意提供帮助的人。

本文翻译自《Modules Part 03: Minimal Version Selection》。

我的网课“Kubernetes实战：高可用集群搭建、配置、运维与应用”在慕课网上线了，感谢小伙伴们学习支持！

我爱发短信：企业级短信平台定制开发专家 https://tonybai.com/
smspush : 可部署在企业内部的定制化短信平台，三网覆盖，不惧大并发接入，可定制扩展； 短信内容你来定，不再受约束, 接口丰富，支持长短信，签名可选。

著名云主机服务厂商DigitalOcean发布最新的主机计划，入门级Droplet配置升级为：1 core CPU、1G内存、25G高速SSD，价格5$/月。有使用DigitalOcean需求的朋友，可以打开这个链接地址：https://m.do.co/c/bff6eed92687 开启你的DO主机之路。

Gopher Daily(Gopher每日新闻)归档仓库 – https://github.com/bigwhite/gopherdaily

我的联系方式：

微博：https://weibo.com/bigwhite20xx
微信公众号：iamtonybai
博客：tonybai.com
github: https://github.com/bigwhite

微信赞赏：

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。

下面是一个示意图，可帮助你调试Kubernetes Deployment（你可以在此处下载它的PDF版本）。

当你希望在Kubernetes中部署应用程序时，你通常会定义三个组件：

• 一个Deployment – 这是一份用于创建你的应用程序的Pod副本的”食谱”；
• 一个Service – 一个内部负载均衡器，用于将流量路由到内部的Pod上；
• 一个Ingress – 描述如何流量应该如何从集群外部流入到集群内部的你的服务上。

下面让我们用示意图快速总结一下要点。

假设你要部署一个简单的”HelloWorld”应用，该应用的YAML文件的内容应该类似下面这样：

// hello-world.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-deployment
  labels:
    track: canary
spec:
  selector:
    matchLabels:
      any-name: my-app
  template:
    metadata:
      labels:
        any-name: my-app
    spec:
      containers:
      - name: cont1
        image: learnk8s/app:1.0.0
        ports:
        - containerPort: 8080
---
apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  ports:
  - port: 80
    targetPort: 8080
  selector:
    name: app
---
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: my-ingress
spec:
  rules:
  - http:
    paths:
    - backend:
        serviceName: app
        servicePort: 80
      path: /

这个定义很长，组件之间的相互关系并不容易看出来。

例如：

• 什么时候应使用端口80，又是何时应使用端口8080？
• 你是否应该为每个服务创建一个新端口以免它们相互冲突？
• 标签(label)名重要吗？它们是否在每一处都应该是一样的？

在进行调试之前，让我们回顾一下这三个组件是如何相互关联的。

让我们从Deployment和Service开始。

一. 连接Deployment和Service

令人惊讶的消息是，Service和Deployment之间根本没有连接。

事实是：Service直接指向Pod，并完全跳过了Deployment。

因此，你应该注意的是Pod和Service之间的相互关系。

你应该记住三件事：

• Service selector应至少与Pod的一个标签匹配；
• Service的targetPort应与Pod中容器的containerPort匹配；
• Service的port可以是任何数字。多个Service可以使用同一端口号，因为它们被分配了不同的IP地址。

下面的图总结了如何连接端口：

再来看看YAML，标签和ports/targetPort应该匹配：

// hello-world.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-deployment
  labels:
    track: canary
spec:
  selector:
    matchLabels:
      any-name: my-app
  template:
    metadata:
      labels:
        any-name: my-app
    spec:
      containers:
      - name: cont1
        image: learnk8s/app:1.0.0
        ports:
        - containerPort: 8080
---
apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  ports:
  - port: 80
    targetPort: 8080
  selector:
    any-name: my-app

那deployment顶部的track: canary标签呢?

它也应该匹配吗？

该标签属于deployment，service的选择器未使用它来路由流量。

换句话说，你可以安全地删除它或为其分配其他值。

那matchLabels选择器呢？

它必须始终与Pod的标签匹配，并且被Deployment用来跟踪Pod。

假设你已经进行了所有正确的设置，该如何测试它呢？

你可以使用以下命令检查Pod是否具有正确的标签：

$ kubectl get pods --show-labels

或者，如果你拥有属于多个应用程序的Pod：

$ kubectl get pods --selector any-name=my-app --show-labels

any-name=my-app就是标签：any-name: my-app。

还有问题吗？

你也可以连接到Pod！

你可以使用kubectl中的port-forward命令连接到service并测试连接。

$ kubectl port-forward service/<service name> 3000:80

• service/ 是服务的名称- 在上面的YAML中是“my-service”
• 3000是你希望在计算机上打开的端口
• 80是service通过port字段暴露的端口

如果可以连接，则说明设置正确。

如果不行，则很可能是你填写了错误的标签或端口不匹配。

二. 连接Service和Ingress

接下来是配置Ingress以将你的应用暴露到集群外部。

Ingress必须知道如何检索服务，然后检索Pod并将流量路由给它们。

Ingress按名字和暴露的端口检索正确的服务。

在Ingress和Service中应该匹配两件事：

• Ingress的servicePort应该匹配service的port；
• Ingress的serviceName应该匹配服务的name。

下面的图总结了如何连接端口：

实践中，你应该查看以下几行(下面代码中的my-service和80)：

// hello-world.yaml

apiVersion: v1
kind: Service
metadata:
  name: my-service   --- 需关注
spec:
  ports:
  - port: 80       --- 需关注
    targetPort: 8080
  selector:
    any-name: my-app
---
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: my-ingress
spec:
  rules:
  - http:
    paths:
    - backend:
        serviceName: my-service --- 需关注
        servicePort: 80 --- 需关注
      path: /

你如何测试Ingress是否正常工作呢？

你可以使用与以前相同的策略kubectl port-forward，但是这次你应该连接到Ingress控制器，而不是连接到Service。

首先，使用以下命令检索Ingress控制器的Pod名称：

$ kubectl get pods --all-namespaces
NAMESPACE   NAME                              READY STATUS
kube-system coredns-5644d7b6d9-jn7cq          1/1   Running
kube-system etcd-minikube                     1/1   Running
kube-system kube-apiserver-minikube           1/1   Running
kube-system kube-controller-manager-minikube  1/1   Running
kube-system kube-proxy-zvf2h                  1/1   Running
kube-system kube-scheduler-minikube           1/1   Running
kube-system nginx-ingress-controller-6fc5bcc  1/1   Running

标识Ingress Pod（可能在其他命名空间中）并描述它以检索端口：

$ kubectl describe pod nginx-ingress-controller-6fc5bcc \
 --namespace kube-system \
 | grep Ports
Ports:         80/TCP, 443/TCP, 18080/TCP

最后，连接到Pod：

$ kubectl port-forward nginx-ingress-controller-6fc5bcc 3000:80 --namespace kube-system

此时，每次你访问计算机上的端口3000时，请求都会转发到Ingress控制器Pod上的端口80。

如果访问http://localhost:3000，则应找到提供网页服务的应用程序。

回顾Port

快速回顾一下哪些端口和标签应该匹配：

• service selector应与Pod的标签匹配
• service的targetPort应与Pod中容器的containerPort匹配
• service的端口可以是任何数字。多个服务可以使用同一端口，因为它们分配了不同的IP地址。
• ingress的servicePort应该匹配service的port
• serivce的名称应与ingress中的serviceName字段匹配

知道如何构造YAML定义只是故事的一部分。

出了问题后该怎么办？

Pod可能无法启动，或者正在崩溃。

三. kubernetes deployment故障排除的3个步骤

在深入研究失败的deployment之前，我们必须对Kubernetes的工作原理有一个明确定义的思维模型。

由于每个deployment中都有三个组件，因此你应该自下而上依次调试所有组件。

• 你应该先确保Pods正在运行
• 然后，专注于让service将流量路由到到正确的Pod
• 然后，检查是否正确配置了Ingress

1. Pod故障排除

在大多数情况下，问题出在Pod本身。

你应该确保Pod正在运行并准备就绪。

该如何检查呢？

$ kubectl get pods
NAME                    READY STATUS            RESTARTS  AGE
app1                    0/1   ImagePullBackOff  0         47h
app2                    0/1   Error             0         47h
app3-76f9fcd46b-xbv4k   1/1   Running           1         47h

在上述会话中，最后一个Pod处于就绪并正常运行的状态；但是，前两个Pod既不处于Running也不是Ready。

你如何调查出了什么问题？

有四个有用的命令可以对Pod进行故障排除：

• kubectl logs 有助于检索Pod容器的日志
• kubectl describe pod 检索与Pod相关的事件列表很有用
• kubectl get pod 用于提取存储在Kubernetes中的Pod的YAML定义
• kubectl exec -ti bash 在Pod的一个容器中运行交互式命令很有用

应该使用哪一个呢？

没有一种万能的。

相反，我们应该结合着使用它们。

常见Pod错误

Pod可能会出现启动和运行时错误。

启动错误包括：

• ImagePullBackoff
• ImageInspectError
• ErrImagePull
• ErrImageNeverPull
• RegistryUnavailable
• InvalidImageName

运行时错误包括：

• CrashLoopBackOff
• RunContainerError
• KillContainerError
• VerifyNonRootError
• RunInitContainerError
• CreatePodSandboxError
• ConfigPodSandboxError
• KillPodSandboxError
• SetupNetworkError
• TeardownNetworkError

有些错误比其他错误更常见。

以下是最常见的错误列表以及如何修复它们的方法。

ImagePullBackOff

当Kubernetes无法获取到Pod中某个容器的镜像时，将出现此错误。

共有三个可能的原因：

• 镜像名称无效-例如，你拼错了名称，或者image不存在
• 你为image指定了不存在的标签
• 你尝试检索的image属于一个私有registry，而Kubernetes没有凭据可以访问它

前两种情况可以通过更正image名称和标记来解决。

针对第三种情况，你应该将私有registry的访问凭证通过Secret添加到k8s中并在Pod中引用它。

官方文档中有一个有关如何实现此目标的示例。

CrashLoopBackOff

如果容器无法启动，则Kubernetes将显示错误状态为：CrashLoopBackOff。

通常，在以下情况下容器无法启动：

• 应用程序中存在错误，导致无法启动
• 你未正确配置容器
• Liveness探针失败太多次

你应该尝试从该容器中检索日志以调查其失败的原因。

如果由于容器重新启动太快而看不到日志，则可以使用以下命令：

$ kubectl logs <pod-name> --previous

这个命令打印前一个容器的错误消息。

RunContainerError

当容器无法启动时，出现此错误。

甚至在容器内的应用程序启动之前。

该问题通常是由于配置错误，例如：

• 挂载不存在的卷，例如ConfigMap或Secrets
• 将只读卷安装为可读写

你应该使用kubectl describe pod 命令收集和分析错误。

处于Pending状态的Pod

当创建Pod时，该Pod保持Pending状态。

为什么？

假设你的调度程序组件运行良好，可能的原因如下：

• 集群没有足够的资源（例如CPU和内存）来运行Pod
• 当前的命名空间具有ResourceQuota对象，创建Pod将使命名空间超过配额
• 该Pod绑定到一个处于pending状态的 PersistentVolumeClaim

最好的选择是检查kubectl describe命令输出的“事件”部分内容：

$ kubectl describe pod <pod name>

对于因ResourceQuotas而导致的错误，可以使用以下方法检查集群的日志：

$ kubectl get events --sort-by=.metadata.creationTimestamp

处于未就绪状态的Pod

如果Pod正在运行但未就绪(not ready)，则表示readiness就绪探针失败。

当“就绪”探针失败时，Pod未连接到服务，并且没有流量转发到该实例。

就绪探针失败是应用程序的特定错误，因此你应检查kubectl describe中的“ 事件”部分以识别错误。

2. 服务的故障排除

如果你的Pod正在运行并处于就绪状态，但仍无法收到应用程序的响应，则应检查服务的配置是否正确。

service旨在根据流量的标签将流量路由到Pod。

因此，你应该检查的第一件事是服务关联了多少个Pod。

你可以通过检查服务中的端点(endpoint)来做到这一点：

$ kubectl describe service <service-name> | grep Endpoints

端点是一对，并且在服务（至少）以Pod为目标时，应该至少有一个端点。

如果“端点”部分为空，则有两种解释：

• 你没有运行带有正确标签的Pod（提示：你应检查自己是否在正确的命名空间中）
• service的selector标签上有错字

如果你看到端点列表，但仍然无法访问你的应用程序，则targetPort可能是你服务中的罪魁祸首。

你如何测试服务？

无论服务类型如何，你都可以使用kubectl port-forward来连接它：

$kubectl port-forward service/<service-name> 3000:80

这里：

• 是服务的名称
• 3000 是你希望在计算机上打开的端口
• 80 是服务公开的端口

3.Ingress的故障排除

如果你已到达本节，则：

• Pod正在运行并准备就绪
• 服务会将流量分配到Pod

但是你仍然看不到应用程序的响应。

这意味着最有可能是Ingress配置错误。

由于正在使用的Ingress控制器是集群中的第三方组件，因此有不同的调试技术，具体取决于Ingress控制器的类型。

但是在深入研究Ingress专用工具之前，你可以用一些简单的方法进行检查。

Ingress使用serviceName和servicePort连接到服务。

你应该检查这些配置是否正确。

你可以通过下面命令检查Ingress配置是否正确：

$kubectl describe ingress <ingress-name>

如果backend一列为空，则配置中必然有一个错误。

如果你可以在“backend”列中看到端点，但是仍然无法访问该应用程序，则可能是以下问题：

• 你如何将Ingress暴露于公共互联网
• 你如何将集群暴露于公共互联网

你可以通过直接连接到Ingress Pod来将基础结构问题与Ingress隔离开。

首先，获取你的Ingress控制器Pod（可以位于其他名称空间中）：

$ kubectl get pods --all-namespaces
NAMESPACE   NAME                              READY STATUS
kube-system coredns-5644d7b6d9-jn7cq          1/1   Running
kube-system etcd-minikube                     1/1   Running
kube-system kube-apiserver-minikube           1/1   Running
kube-system kube-controller-manager-minikube  1/1   Running
kube-system kube-proxy-zvf2h                  1/1   Running
kube-system kube-scheduler-minikube           1/1   Running
kube-system nginx-ingress-controller-6fc5bcc  1/1   Running

描述它以检索端口：

# kubectl describe pod nginx-ingress-controller-6fc5bcc
 --namespace kube-system \
 | grep Ports

最后，连接到Pod：

$ kubectl port-forward nginx-ingress-controller-6fc5bcc 3000:80 --namespace kube-system

此时，每次你访问计算机上的端口3000时，请求都会转发到Pod上的端口80。

现在可以用吗？

• 如果可行，则问题出在基础架构中。你应该调查流量如何路由到你的集群。
• 如果不起作用，则问题出在Ingress控制器中。你应该调试Ingress。

如果仍然无法使Ingress控制器正常工作，则应开始对其进行调试。

目前有许多不同版本的Ingress控制器。

热门选项包括Nginx，HAProxy，Traefik等。

你应该查阅Ingress控制器的文档以查找故障排除指南。

由于Ingress Nginx是最受欢迎的Ingress控制器，因此在下一部分中我们将介绍一些有关调试ingress-nginx的技巧。

调试Ingress Nginx

Ingress-nginx项目有一个Kubectl的官方插件。

你可以用kubectl ingress-nginx来：

• 检查日志，后端，证书等。
• 连接到ingress
• 检查当前配置

你应该尝试的三个命令是：

• kubectl ingress-nginx lint，它会检查 nginx.conf
• kubectl ingress-nginx backend，以检查后端（类似于kubectl describe ingress ）
• kubectl ingress-nginx logs，查看日志

请注意，你可能需要为Ingress控制器指定正确的名称空间–namespace 。

四. 总结

如果你不知道从哪里开始，那么在Kubernetes中进行故障排除可能是一项艰巨的任务。

你应该始终牢记从下至上解决问题：从Pod开始，然后通过Service和Ingress向上移动堆栈。

你在本文中了解到的调试技术也可以应用于其他对象，例如：

• failing Job和CronJob
• StatefulSets和DaemonSets

本文翻译自learnk8s上的文章A visual guide on troubleshooting Kubernetes deployments。

我的网课“Kubernetes实战：高可用集群搭建、配置、运维与应用”在慕课网上线了，感谢小伙伴们学习支持！

我爱发短信：企业级短信平台定制开发专家 https://tonybai.com/
smspush : 可部署在企业内部的定制化短信平台，三网覆盖，不惧大并发接入，可定制扩展； 短信内容你来定，不再受约束, 接口丰富，支持长短信，签名可选。

著名云主机服务厂商DigitalOcean发布最新的主机计划，入门级Droplet配置升级为：1 core CPU、1G内存、25G高速SSD，价格5$/月。有使用DigitalOcean需求的朋友，可以打开这个链接地址：https://m.do.co/c/bff6eed92687 开启你的DO主机之路。

Gopher Daily(Gopher每日新闻)归档仓库 – https://github.com/bigwhite/gopherdaily

我的联系方式：

微博：https://weibo.com/bigwhite20xx
微信公众号：iamtonybai
博客：tonybai.com
github: https://github.com/bigwhite

微信赞赏：

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。