Merge branch 'master' into master
jiangpengfei
GitHub
commit
c42ccc0319
|
|
@ -0,0 +1,36 @@
|
|||
version: 2
|
||||
jobs:
|
||||
lint-gitbook:
|
||||
docker:
|
||||
- image: jimmysong/gitbook-builder:2019-07-31
|
||||
working_directory: ~/gitbook
|
||||
steps:
|
||||
- checkout
|
||||
- run:
|
||||
name: Linting the gitbook
|
||||
command: scripts/lint-gitbook.sh
|
||||
markdown-spell-check:
|
||||
docker:
|
||||
- image: jimmysong/gitbook-builder:2019-07-31
|
||||
working_directory: ~/gitbook
|
||||
steps:
|
||||
- checkout
|
||||
- run:
|
||||
name: Running markdown spell check
|
||||
command: scripts/mdspell-check.sh
|
||||
markdown-style-check:
|
||||
docker:
|
||||
- image: jimmysong/gitbook-builder:2019-07-31
|
||||
working_directory: ~/gitbook
|
||||
steps:
|
||||
- checkout
|
||||
- run:
|
||||
name: Running markdown style check
|
||||
command: scripts/mdl-check.sh
|
||||
workflows:
|
||||
version: 2
|
||||
workflow:
|
||||
jobs:
|
||||
- lint-gitbook
|
||||
- markdown-spell-check
|
||||
- markdown-style-check
|
||||
|
|
@ -18,3 +18,7 @@ _book
|
|||
# Github Pages
|
||||
deploy.sh
|
||||
.DS_Store
|
||||
|
||||
# IDEA
|
||||
*.iml
|
||||
.idea
|
||||
|
|
|
|||
|
|
@ -29,6 +29,19 @@
|
|||
4. 在浏览器中访问 http://localhost:4000
|
||||
5. 生成的文档在 `_book` 目录下
|
||||
|
||||
**Docker**
|
||||
|
||||
本书提供了 Docker 构建方式。
|
||||
|
||||
```bash
|
||||
make install
|
||||
make build
|
||||
```
|
||||
|
||||
继续运行 `make serve` 即可渲染 gitbook，通过 <http://localhost:4000> 查看。
|
||||
|
||||
注：使用 `docker ps` 找到该容器 ID 后，使用 `docker kill $ID` 可以关掉网站。
|
||||
|
||||
**下载 PDF/ePub/Mobi 格式文档本地查看**
|
||||
|
||||
访问 [gitbook](https://www.gitbook.com/book/rootsongjc/kubernetes-handbook/details) 可以看到下载地址，可以下载根据最新文档生成的 **PDF/ePub/Mobi** 格式文档（文档的注脚中注明了更新时间），同时也可以直接在 gitbook 中阅读，不过 gitbook 不太稳定打开速度较慢，建议大家直接在 https://jimmysong.io/kubernetes-handbook/ 浏览。
|
||||
|
|
@ -39,7 +52,7 @@
|
|||
|
||||
- **On Mac**
|
||||
|
||||
在Mac下安装后，使用该命令创建链接
|
||||
在Mac下安装后，使用该命令创建链接：
|
||||
|
||||
```bash
|
||||
ln -s /Applications/calibre.app/Contents/MacOS/ebook-convert /usr/local/bin
|
||||
|
|
@ -51,6 +64,8 @@ ln -s /Applications/calibre.app/Contents/MacOS/ebook-convert /usr/local/bin
|
|||
gitbook pdf . ./kubernetes-handbook.pdf
|
||||
```
|
||||
|
||||
**注：因为各种依赖问题，通过 docker 方式暂时无法构建 PDF。**
|
||||
|
||||
- **On Windows**
|
||||
|
||||
需要用到的工具：[calibre](http://calibre-ebook.com/)，[phantomjs](http://phantomjs.org/download.html)
|
||||
|
|
|
|||
526
LICENSE
526
LICENSE
|
|
@ -1,187 +1,395 @@
|
|||
Apache License
|
||||
Version 2.0, January 2004
|
||||
http://www.apache.org/licenses/
|
||||
Attribution 4.0 International
|
||||
|
||||
TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
|
||||
=======================================================================
|
||||
|
||||
1. Definitions.
|
||||
Creative Commons Corporation ("Creative Commons") is not a law firm and
|
||||
does not provide legal services or legal advice. Distribution of
|
||||
Creative Commons public licenses does not create a lawyer-client or
|
||||
other relationship. Creative Commons makes its licenses and related
|
||||
information available on an "as-is" basis. Creative Commons gives no
|
||||
warranties regarding its licenses, any material licensed under their
|
||||
terms and conditions, or any related information. Creative Commons
|
||||
disclaims all liability for damages resulting from their use to the
|
||||
fullest extent possible.
|
||||
|
||||
"License" shall mean the terms and conditions for use, reproduction,
|
||||
and distribution as defined by Sections 1 through 9 of this document.
|
||||
Using Creative Commons Public Licenses
|
||||
|
||||
"Licensor" shall mean the copyright owner or entity authorized by
|
||||
the copyright owner that is granting the License.
|
||||
Creative Commons public licenses provide a standard set of terms and
|
||||
conditions that creators and other rights holders may use to share
|
||||
original works of authorship and other material subject to copyright
|
||||
and certain other rights specified in the public license below. The
|
||||
following considerations are for informational purposes only, are not
|
||||
exhaustive, and do not form part of our licenses.
|
||||
|
||||
"Legal Entity" shall mean the union of the acting entity and all
|
||||
other entities that control, are controlled by, or are under common
|
||||
control with that entity. For the purposes of this definition,
|
||||
"control" means (i) the power, direct or indirect, to cause the
|
||||
direction or management of such entity, whether by contract or
|
||||
otherwise, or (ii) ownership of fifty percent (50%) or more of the
|
||||
outstanding shares, or (iii) beneficial ownership of such entity.
|
||||
Considerations for licensors: Our public licenses are
|
||||
intended for use by those authorized to give the public
|
||||
permission to use material in ways otherwise restricted by
|
||||
copyright and certain other rights. Our licenses are
|
||||
irrevocable. Licensors should read and understand the terms
|
||||
and conditions of the license they choose before applying it.
|
||||
Licensors should also secure all rights necessary before
|
||||
applying our licenses so that the public can reuse the
|
||||
material as expected. Licensors should clearly mark any
|
||||
material not subject to the license. This includes other CC-
|
||||
licensed material, or material used under an exception or
|
||||
limitation to copyright. More considerations for licensors:
|
||||
wiki.creativecommons.org/Considerations_for_licensors
|
||||
|
||||
"You" (or "Your") shall mean an individual or Legal Entity
|
||||
exercising permissions granted by this License.
|
||||
Considerations for the public: By using one of our public
|
||||
licenses, a licensor grants the public permission to use the
|
||||
licensed material under specified terms and conditions. If
|
||||
the licensor's permission is not necessary for any reason--for
|
||||
example, because of any applicable exception or limitation to
|
||||
copyright--then that use is not regulated by the license. Our
|
||||
licenses grant only permissions under copyright and certain
|
||||
other rights that a licensor has authority to grant. Use of
|
||||
the licensed material may still be restricted for other
|
||||
reasons, including because others have copyright or other
|
||||
rights in the material. A licensor may make special requests,
|
||||
such as asking that all changes be marked or described.
|
||||
Although not required by our licenses, you are encouraged to
|
||||
respect those requests where reasonable. More_considerations
|
||||
for the public:
|
||||
wiki.creativecommons.org/Considerations_for_licensees
|
||||
|
||||
"Source" form shall mean the preferred form for making modifications,
|
||||
including but not limited to software source code, documentation
|
||||
source, and configuration files.
|
||||
=======================================================================
|
||||
|
||||
"Object" form shall mean any form resulting from mechanical
|
||||
transformation or translation of a Source form, including but
|
||||
not limited to compiled object code, generated documentation,
|
||||
and conversions to other media types.
|
||||
Creative Commons Attribution 4.0 International Public License
|
||||
|
||||
"Work" shall mean the work of authorship, whether in Source or
|
||||
Object form, made available under the License, as indicated by a
|
||||
copyright notice that is included in or attached to the work
|
||||
(an example is provided in the Appendix below).
|
||||
By exercising the Licensed Rights (defined below), You accept and agree
|
||||
to be bound by the terms and conditions of this Creative Commons
|
||||
Attribution 4.0 International Public License ("Public License"). To the
|
||||
extent this Public License may be interpreted as a contract, You are
|
||||
granted the Licensed Rights in consideration of Your acceptance of
|
||||
these terms and conditions, and the Licensor grants You such rights in
|
||||
consideration of benefits the Licensor receives from making the
|
||||
Licensed Material available under these terms and conditions.
|
||||
|
||||
"Derivative Works" shall mean any work, whether in Source or Object
|
||||
form, that is based on (or derived from) the Work and for which the
|
||||
editorial revisions, annotations, elaborations, or other modifications
|
||||
represent, as a whole, an original work of authorship. For the purposes
|
||||
of this License, Derivative Works shall not include works that remain
|
||||
separable from, or merely link (or bind by name) to the interfaces of,
|
||||
the Work and Derivative Works thereof.
|
||||
|
||||
"Contribution" shall mean any work of authorship, including
|
||||
the original version of the Work and any modifications or additions
|
||||
to that Work or Derivative Works thereof, that is intentionally
|
||||
submitted to Licensor for inclusion in the Work by the copyright owner
|
||||
or by an individual or Legal Entity authorized to submit on behalf of
|
||||
the copyright owner. For the purposes of this definition, "submitted"
|
||||
means any form of electronic, verbal, or written communication sent
|
||||
to the Licensor or its representatives, including but not limited to
|
||||
communication on electronic mailing lists, source code control systems,
|
||||
and issue tracking systems that are managed by, or on behalf of, the
|
||||
Licensor for the purpose of discussing and improving the Work, but
|
||||
excluding communication that is conspicuously marked or otherwise
|
||||
designated in writing by the copyright owner as "Not a Contribution."
|
||||
Section 1 -- Definitions.
|
||||
|
||||
"Contributor" shall mean Licensor and any individual or Legal Entity
|
||||
on behalf of whom a Contribution has been received by Licensor and
|
||||
subsequently incorporated within the Work.
|
||||
a. Adapted Material means material subject to Copyright and Similar
|
||||
Rights that is derived from or based upon the Licensed Material
|
||||
and in which the Licensed Material is translated, altered,
|
||||
arranged, transformed, or otherwise modified in a manner requiring
|
||||
permission under the Copyright and Similar Rights held by the
|
||||
Licensor. For purposes of this Public License, where the Licensed
|
||||
Material is a musical work, performance, or sound recording,
|
||||
Adapted Material is always produced where the Licensed Material is
|
||||
synched in timed relation with a moving image.
|
||||
|
||||
2. Grant of Copyright License. Subject to the terms and conditions of
|
||||
this License, each Contributor hereby grants to You a perpetual,
|
||||
worldwide, non-exclusive, no-charge, royalty-free, irrevocable
|
||||
copyright license to reproduce, prepare Derivative Works of,
|
||||
publicly display, publicly perform, sublicense, and distribute the
|
||||
Work and such Derivative Works in Source or Object form.
|
||||
b. Adapter's License means the license You apply to Your Copyright
|
||||
and Similar Rights in Your contributions to Adapted Material in
|
||||
accordance with the terms and conditions of this Public License.
|
||||
|
||||
3. Grant of Patent License. Subject to the terms and conditions of
|
||||
this License, each Contributor hereby grants to You a perpetual,
|
||||
worldwide, non-exclusive, no-charge, royalty-free, irrevocable
|
||||
(except as stated in this section) patent license to make, have made,
|
||||
use, offer to sell, sell, import, and otherwise transfer the Work,
|
||||
where such license applies only to those patent claims licensable
|
||||
by such Contributor that are necessarily infringed by their
|
||||
Contribution(s) alone or by combination of their Contribution(s)
|
||||
with the Work to which such Contribution(s) was submitted. If You
|
||||
institute patent litigation against any entity (including a
|
||||
cross-claim or counterclaim in a lawsuit) alleging that the Work
|
||||
or a Contribution incorporated within the Work constitutes direct
|
||||
or contributory patent infringement, then any patent licenses
|
||||
granted to You under this License for that Work shall terminate
|
||||
as of the date such litigation is filed.
|
||||
c. Copyright and Similar Rights means copyright and/or similar rights
|
||||
closely related to copyright including, without limitation,
|
||||
performance, broadcast, sound recording, and Sui Generis Database
|
||||
Rights, without regard to how the rights are labeled or
|
||||
categorized. For purposes of this Public License, the rights
|
||||
specified in Section 2(b)(1)-(2) are not Copyright and Similar
|
||||
Rights.
|
||||
|
||||
4. Redistribution. You may reproduce and distribute copies of the
|
||||
Work or Derivative Works thereof in any medium, with or without
|
||||
modifications, and in Source or Object form, provided that You
|
||||
meet the following conditions:
|
||||
d. Effective Technological Measures means those measures that, in the
|
||||
absence of proper authority, may not be circumvented under laws
|
||||
fulfilling obligations under Article 11 of the WIPO Copyright
|
||||
Treaty adopted on December 20, 1996, and/or similar international
|
||||
agreements.
|
||||
|
||||
(a) You must give any other recipients of the Work or
|
||||
Derivative Works a copy of this License; and
|
||||
e. Exceptions and Limitations means fair use, fair dealing, and/or
|
||||
any other exception or limitation to Copyright and Similar Rights
|
||||
that applies to Your use of the Licensed Material.
|
||||
|
||||
(b) You must cause any modified files to carry prominent notices
|
||||
stating that You changed the files; and
|
||||
f. Licensed Material means the artistic or literary work, database,
|
||||
or other material to which the Licensor applied this Public
|
||||
License.
|
||||
|
||||
(c) You must retain, in the Source form of any Derivative Works
|
||||
that You distribute, all copyright, patent, trademark, and
|
||||
attribution notices from the Source form of the Work,
|
||||
excluding those notices that do not pertain to any part of
|
||||
the Derivative Works; and
|
||||
g. Licensed Rights means the rights granted to You subject to the
|
||||
terms and conditions of this Public License, which are limited to
|
||||
all Copyright and Similar Rights that apply to Your use of the
|
||||
Licensed Material and that the Licensor has authority to license.
|
||||
|
||||
(d) If the Work includes a "NOTICE" text file as part of its
|
||||
distribution, then any Derivative Works that You distribute must
|
||||
include a readable copy of the attribution notices contained
|
||||
within such NOTICE file, excluding those notices that do not
|
||||
pertain to any part of the Derivative Works, in at least one
|
||||
of the following places: within a NOTICE text file distributed
|
||||
as part of the Derivative Works; within the Source form or
|
||||
documentation, if provided along with the Derivative Works; or,
|
||||
within a display generated by the Derivative Works, if and
|
||||
wherever such third-party notices normally appear. The contents
|
||||
of the NOTICE file are for informational purposes only and
|
||||
do not modify the License. You may add Your own attribution
|
||||
notices within Derivative Works that You distribute, alongside
|
||||
or as an addendum to the NOTICE text from the Work, provided
|
||||
that such additional attribution notices cannot be construed
|
||||
as modifying the License.
|
||||
h. Licensor means the individual(s) or entity(ies) granting rights
|
||||
under this Public License.
|
||||
|
||||
You may add Your own copyright statement to Your modifications and
|
||||
may provide additional or different license terms and conditions
|
||||
for use, reproduction, or distribution of Your modifications, or
|
||||
for any such Derivative Works as a whole, provided Your use,
|
||||
reproduction, and distribution of the Work otherwise complies with
|
||||
the conditions stated in this License.
|
||||
i. Share means to provide material to the public by any means or
|
||||
process that requires permission under the Licensed Rights, such
|
||||
as reproduction, public display, public performance, distribution,
|
||||
dissemination, communication, or importation, and to make material
|
||||
available to the public including in ways that members of the
|
||||
public may access the material from a place and at a time
|
||||
individually chosen by them.
|
||||
|
||||
5. Submission of Contributions. Unless You explicitly state otherwise,
|
||||
any Contribution intentionally submitted for inclusion in the Work
|
||||
by You to the Licensor shall be under the terms and conditions of
|
||||
this License, without any additional terms or conditions.
|
||||
Notwithstanding the above, nothing herein shall supersede or modify
|
||||
the terms of any separate license agreement you may have executed
|
||||
with Licensor regarding such Contributions.
|
||||
j. Sui Generis Database Rights means rights other than copyright
|
||||
resulting from Directive 96/9/EC of the European Parliament and of
|
||||
the Council of 11 March 1996 on the legal protection of databases,
|
||||
as amended and/or succeeded, as well as other essentially
|
||||
equivalent rights anywhere in the world.
|
||||
|
||||
6. Trademarks. This License does not grant permission to use the trade
|
||||
names, trademarks, service marks, or product names of the Licensor,
|
||||
except as required for reasonable and customary use in describing the
|
||||
origin of the Work and reproducing the content of the NOTICE file.
|
||||
k. You means the individual or entity exercising the Licensed Rights
|
||||
under this Public License. Your has a corresponding meaning.
|
||||
|
||||
7. Disclaimer of Warranty. Unless required by applicable law or
|
||||
agreed to in writing, Licensor provides the Work (and each
|
||||
Contributor provides its Contributions) on an "AS IS" BASIS,
|
||||
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
|
||||
implied, including, without limitation, any warranties or conditions
|
||||
of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
|
||||
PARTICULAR PURPOSE. You are solely responsible for determining the
|
||||
appropriateness of using or redistributing the Work and assume any
|
||||
risks associated with Your exercise of permissions under this License.
|
||||
|
||||
8. Limitation of Liability. In no event and under no legal theory,
|
||||
whether in tort (including negligence), contract, or otherwise,
|
||||
unless required by applicable law (such as deliberate and grossly
|
||||
negligent acts) or agreed to in writing, shall any Contributor be
|
||||
liable to You for damages, including any direct, indirect, special,
|
||||
incidental, or consequential damages of any character arising as a
|
||||
result of this License or out of the use or inability to use the
|
||||
Work (including but not limited to damages for loss of goodwill,
|
||||
work stoppage, computer failure or malfunction, or any and all
|
||||
other commercial damages or losses), even if such Contributor
|
||||
has been advised of the possibility of such damages.
|
||||
Section 2 -- Scope.
|
||||
|
||||
9. Accepting Warranty or Additional Liability. While redistributing
|
||||
the Work or Derivative Works thereof, You may choose to offer,
|
||||
and charge a fee for, acceptance of support, warranty, indemnity,
|
||||
or other liability obligations and/or rights consistent with this
|
||||
License. However, in accepting such obligations, You may act only
|
||||
on Your own behalf and on Your sole responsibility, not on behalf
|
||||
of any other Contributor, and only if You agree to indemnify,
|
||||
defend, and hold each Contributor harmless for any liability
|
||||
incurred by, or claims asserted against, such Contributor by reason
|
||||
of your accepting any such warranty or additional liability.
|
||||
a. License grant.
|
||||
|
||||
END OF TERMS AND CONDITIONS
|
||||
1. Subject to the terms and conditions of this Public License,
|
||||
the Licensor hereby grants You a worldwide, royalty-free,
|
||||
non-sublicensable, non-exclusive, irrevocable license to
|
||||
exercise the Licensed Rights in the Licensed Material to:
|
||||
|
||||
APPENDIX: How to apply the Apache License to your work.
|
||||
a. reproduce and Share the Licensed Material, in whole or
|
||||
in part; and
|
||||
|
||||
To apply the Apache License to your work, attach the following
|
||||
boilerplate notice, with the fields enclosed by brackets "{}"
|
||||
replaced with your own identifying information. (Don't include
|
||||
the brackets!) The text should be enclosed in the appropriate
|
||||
comment syntax for the file format. We also recommend that a
|
||||
file or class name and description of purpose be included on the
|
||||
same "printed page" as the copyright notice for easier
|
||||
identification within third-party archives.
|
||||
b. produce, reproduce, and Share Adapted Material.
|
||||
|
||||
2. Exceptions and Limitations. For the avoidance of doubt, where
|
||||
Exceptions and Limitations apply to Your use, this Public
|
||||
License does not apply, and You do not need to comply with
|
||||
its terms and conditions.
|
||||
|
||||
3. Term. The term of this Public License is specified in Section
|
||||
6(a).
|
||||
|
||||
4. Media and formats; technical modifications allowed. The
|
||||
Licensor authorizes You to exercise the Licensed Rights in
|
||||
all media and formats whether now known or hereafter created,
|
||||
and to make technical modifications necessary to do so. The
|
||||
Licensor waives and/or agrees not to assert any right or
|
||||
authority to forbid You from making technical modifications
|
||||
necessary to exercise the Licensed Rights, including
|
||||
technical modifications necessary to circumvent Effective
|
||||
Technological Measures. For purposes of this Public License,
|
||||
simply making modifications authorized by this Section 2(a)
|
||||
(4) never produces Adapted Material.
|
||||
|
||||
5. Downstream recipients.
|
||||
|
||||
a. Offer from the Licensor -- Licensed Material. Every
|
||||
recipient of the Licensed Material automatically
|
||||
receives an offer from the Licensor to exercise the
|
||||
Licensed Rights under the terms and conditions of this
|
||||
Public License.
|
||||
|
||||
b. No downstream restrictions. You may not offer or impose
|
||||
any additional or different terms or conditions on, or
|
||||
apply any Effective Technological Measures to, the
|
||||
Licensed Material if doing so restricts exercise of the
|
||||
Licensed Rights by any recipient of the Licensed
|
||||
Material.
|
||||
|
||||
6. No endorsement. Nothing in this Public License constitutes or
|
||||
may be construed as permission to assert or imply that You
|
||||
are, or that Your use of the Licensed Material is, connected
|
||||
with, or sponsored, endorsed, or granted official status by,
|
||||
the Licensor or others designated to receive attribution as
|
||||
provided in Section 3(a)(1)(A)(i).
|
||||
|
||||
b. Other rights.
|
||||
|
||||
1. Moral rights, such as the right of integrity, are not
|
||||
licensed under this Public License, nor are publicity,
|
||||
privacy, and/or other similar personality rights; however, to
|
||||
the extent possible, the Licensor waives and/or agrees not to
|
||||
assert any such rights held by the Licensor to the limited
|
||||
extent necessary to allow You to exercise the Licensed
|
||||
Rights, but not otherwise.
|
||||
|
||||
2. Patent and trademark rights are not licensed under this
|
||||
Public License.
|
||||
|
||||
3. To the extent possible, the Licensor waives any right to
|
||||
collect royalties from You for the exercise of the Licensed
|
||||
Rights, whether directly or through a collecting society
|
||||
under any voluntary or waivable statutory or compulsory
|
||||
licensing scheme. In all other cases the Licensor expressly
|
||||
reserves any right to collect such royalties.
|
||||
|
||||
|
||||
Section 3 -- License Conditions.
|
||||
|
||||
Your exercise of the Licensed Rights is expressly made subject to the
|
||||
following conditions.
|
||||
|
||||
a. Attribution.
|
||||
|
||||
1. If You Share the Licensed Material (including in modified
|
||||
form), You must:
|
||||
|
||||
a. retain the following if it is supplied by the Licensor
|
||||
with the Licensed Material:
|
||||
|
||||
i. identification of the creator(s) of the Licensed
|
||||
Material and any others designated to receive
|
||||
attribution, in any reasonable manner requested by
|
||||
the Licensor (including by pseudonym if
|
||||
designated);
|
||||
|
||||
ii. a copyright notice;
|
||||
|
||||
iii. a notice that refers to this Public License;
|
||||
|
||||
iv. a notice that refers to the disclaimer of
|
||||
warranties;
|
||||
|
||||
v. a URI or hyperlink to the Licensed Material to the
|
||||
extent reasonably practicable;
|
||||
|
||||
b. indicate if You modified the Licensed Material and
|
||||
retain an indication of any previous modifications; and
|
||||
|
||||
c. indicate the Licensed Material is licensed under this
|
||||
Public License, and include the text of, or the URI or
|
||||
hyperlink to, this Public License.
|
||||
|
||||
2. You may satisfy the conditions in Section 3(a)(1) in any
|
||||
reasonable manner based on the medium, means, and context in
|
||||
which You Share the Licensed Material. For example, it may be
|
||||
reasonable to satisfy the conditions by providing a URI or
|
||||
hyperlink to a resource that includes the required
|
||||
information.
|
||||
|
||||
3. If requested by the Licensor, You must remove any of the
|
||||
information required by Section 3(a)(1)(A) to the extent
|
||||
reasonably practicable.
|
||||
|
||||
4. If You Share Adapted Material You produce, the Adapter's
|
||||
License You apply must not prevent recipients of the Adapted
|
||||
Material from complying with this Public License.
|
||||
|
||||
|
||||
Section 4 -- Sui Generis Database Rights.
|
||||
|
||||
Where the Licensed Rights include Sui Generis Database Rights that
|
||||
apply to Your use of the Licensed Material:
|
||||
|
||||
a. for the avoidance of doubt, Section 2(a)(1) grants You the right
|
||||
to extract, reuse, reproduce, and Share all or a substantial
|
||||
portion of the contents of the database;
|
||||
|
||||
b. if You include all or a substantial portion of the database
|
||||
contents in a database in which You have Sui Generis Database
|
||||
Rights, then the database in which You have Sui Generis Database
|
||||
Rights (but not its individual contents) is Adapted Material; and
|
||||
|
||||
c. You must comply with the conditions in Section 3(a) if You Share
|
||||
all or a substantial portion of the contents of the database.
|
||||
|
||||
For the avoidance of doubt, this Section 4 supplements and does not
|
||||
replace Your obligations under this Public License where the Licensed
|
||||
Rights include other Copyright and Similar Rights.
|
||||
|
||||
|
||||
Section 5 -- Disclaimer of Warranties and Limitation of Liability.
|
||||
|
||||
a. UNLESS OTHERWISE SEPARATELY UNDERTAKEN BY THE LICENSOR, TO THE
|
||||
EXTENT POSSIBLE, THE LICENSOR OFFERS THE LICENSED MATERIAL AS-IS
|
||||
AND AS-AVAILABLE, AND MAKES NO REPRESENTATIONS OR WARRANTIES OF
|
||||
ANY KIND CONCERNING THE LICENSED MATERIAL, WHETHER EXPRESS,
|
||||
IMPLIED, STATUTORY, OR OTHER. THIS INCLUDES, WITHOUT LIMITATION,
|
||||
WARRANTIES OF TITLE, MERCHANTABILITY, FITNESS FOR A PARTICULAR
|
||||
PURPOSE, NON-INFRINGEMENT, ABSENCE OF LATENT OR OTHER DEFECTS,
|
||||
ACCURACY, OR THE PRESENCE OR ABSENCE OF ERRORS, WHETHER OR NOT
|
||||
KNOWN OR DISCOVERABLE. WHERE DISCLAIMERS OF WARRANTIES ARE NOT
|
||||
ALLOWED IN FULL OR IN PART, THIS DISCLAIMER MAY NOT APPLY TO YOU.
|
||||
|
||||
b. TO THE EXTENT POSSIBLE, IN NO EVENT WILL THE LICENSOR BE LIABLE
|
||||
TO YOU ON ANY LEGAL THEORY (INCLUDING, WITHOUT LIMITATION,
|
||||
NEGLIGENCE) OR OTHERWISE FOR ANY DIRECT, SPECIAL, INDIRECT,
|
||||
INCIDENTAL, CONSEQUENTIAL, PUNITIVE, EXEMPLARY, OR OTHER LOSSES,
|
||||
COSTS, EXPENSES, OR DAMAGES ARISING OUT OF THIS PUBLIC LICENSE OR
|
||||
USE OF THE LICENSED MATERIAL, EVEN IF THE LICENSOR HAS BEEN
|
||||
ADVISED OF THE POSSIBILITY OF SUCH LOSSES, COSTS, EXPENSES, OR
|
||||
DAMAGES. WHERE A LIMITATION OF LIABILITY IS NOT ALLOWED IN FULL OR
|
||||
IN PART, THIS LIMITATION MAY NOT APPLY TO YOU.
|
||||
|
||||
c. The disclaimer of warranties and limitation of liability provided
|
||||
above shall be interpreted in a manner that, to the extent
|
||||
possible, most closely approximates an absolute disclaimer and
|
||||
waiver of all liability.
|
||||
|
||||
|
||||
Section 6 -- Term and Termination.
|
||||
|
||||
a. This Public License applies for the term of the Copyright and
|
||||
Similar Rights licensed here. However, if You fail to comply with
|
||||
this Public License, then Your rights under this Public License
|
||||
terminate automatically.
|
||||
|
||||
b. Where Your right to use the Licensed Material has terminated under
|
||||
Section 6(a), it reinstates:
|
||||
|
||||
1. automatically as of the date the violation is cured, provided
|
||||
it is cured within 30 days of Your discovery of the
|
||||
violation; or
|
||||
|
||||
2. upon express reinstatement by the Licensor.
|
||||
|
||||
For the avoidance of doubt, this Section 6(b) does not affect any
|
||||
right the Licensor may have to seek remedies for Your violations
|
||||
of this Public License.
|
||||
|
||||
c. For the avoidance of doubt, the Licensor may also offer the
|
||||
Licensed Material under separate terms or conditions or stop
|
||||
distributing the Licensed Material at any time; however, doing so
|
||||
will not terminate this Public License.
|
||||
|
||||
d. Sections 1, 5, 6, 7, and 8 survive termination of this Public
|
||||
License.
|
||||
|
||||
|
||||
Section 7 -- Other Terms and Conditions.
|
||||
|
||||
a. The Licensor shall not be bound by any additional or different
|
||||
terms or conditions communicated by You unless expressly agreed.
|
||||
|
||||
b. Any arrangements, understandings, or agreements regarding the
|
||||
Licensed Material not stated herein are separate from and
|
||||
independent of the terms and conditions of this Public License.
|
||||
|
||||
|
||||
Section 8 -- Interpretation.
|
||||
|
||||
a. For the avoidance of doubt, this Public License does not, and
|
||||
shall not be interpreted to, reduce, limit, restrict, or impose
|
||||
conditions on any use of the Licensed Material that could lawfully
|
||||
be made without permission under this Public License.
|
||||
|
||||
b. To the extent possible, if any provision of this Public License is
|
||||
deemed unenforceable, it shall be automatically reformed to the
|
||||
minimum extent necessary to make it enforceable. If the provision
|
||||
cannot be reformed, it shall be severed from this Public License
|
||||
without affecting the enforceability of the remaining terms and
|
||||
conditions.
|
||||
|
||||
c. No term or condition of this Public License will be waived and no
|
||||
failure to comply consented to unless expressly agreed to by the
|
||||
Licensor.
|
||||
|
||||
d. Nothing in this Public License constitutes or may be interpreted
|
||||
as a limitation upon, or waiver of, any privileges and immunities
|
||||
that apply to the Licensor or You, including from the legal
|
||||
processes of any jurisdiction or authority.
|
||||
|
||||
|
||||
=======================================================================
|
||||
|
||||
Creative Commons is not a party to its public
|
||||
licenses. Notwithstanding, Creative Commons may elect to apply one of
|
||||
its public licenses to material it publishes and in those instances
|
||||
will be considered the "Licensor." The text of the Creative Commons
|
||||
public licenses is dedicated to the public domain under the CC0 Public
|
||||
Domain Dedication. Except for the limited purpose of indicating that
|
||||
material is shared under a Creative Commons public license or as
|
||||
otherwise permitted by the Creative Commons policies published at
|
||||
creativecommons.org/policies, Creative Commons does not authorize the
|
||||
use of the trademark "Creative Commons" or any other trademark or logo
|
||||
of Creative Commons without its prior written consent including,
|
||||
without limitation, in connection with any unauthorized modifications
|
||||
to any of its public licenses or any other arrangements,
|
||||
understandings, or agreements concerning use of licensed material. For
|
||||
the avoidance of doubt, this paragraph does not form part of the
|
||||
public licenses.
|
||||
|
||||
Creative Commons may be contacted at creativecommons.org.
|
||||
|
|
|
|||
44
Makefile
44
Makefile
|
|
@ -1,36 +1,36 @@
|
|||
BOOK_NAME := kubernetes-handbook
|
||||
BOOK_OUTPUT := _book
|
||||
image := jimmysong/gitbook-builder:2019-07-31
|
||||
docker := docker run -t -i --sig-proxy=true --rm -v $(shell pwd):/gitbook -w /gitbook -p 4000:4000 $(image)
|
||||
|
||||
.PHONY: build
|
||||
build:
|
||||
gitbook build . $(BOOK_OUTPUT)
|
||||
cp images/apple-touch-icon-precomposed-152.png $(BOOK_OUTPUT)/gitbook/images
|
||||
@$(docker) scripts/build-gitbook.sh
|
||||
|
||||
.PHONY: lint
|
||||
lint:
|
||||
htmlproofer --url-ignore "/localhost/,/172.17.8.101/,/172.20.0.113/,/slideshare.net/,/grpc.io/,/kiali.io/,/condiut.io/,/twitter.com/,/facebook.com/,/medium.com/,/google.com/,/jimmysong.io/" $(BOOK_OUTPUT)
|
||||
|
||||
.PHONY: serve
|
||||
serve:
|
||||
gitbook serve . $(BOOK_OUTPUT)
|
||||
|
||||
.PHONY: epub
|
||||
epub:
|
||||
gitbook epub . $(BOOK_NAME).epub
|
||||
|
||||
.PHONY: pdf
|
||||
pdf:
|
||||
gitbook pdf . $(BOOK_NAME).pdf
|
||||
|
||||
.PHONY: mobi
|
||||
mobi:
|
||||
gitbook mobi . $(BOOK_NAME).mobi
|
||||
@$(docker) scripts/lint-gitbook.sh
|
||||
htmlproofer --url-ignore "/localhost/,/172.17.8.101/,/172.20.0.113/,/slideshare.net/,/grpc.io/,/kiali.io/,/condiut.io/,/twitter.com/,/facebook.com/,/medium.com/,/google.com/,/jimmysong.io/,/openfaas.com/,/linkerd.io/,/layer5.io/,/thenewstack.io/,/blog.envoyproxy.io/,/blog.openebs.io/,/k8smeetup.github.io/,/blog.heptio.com/,/apigee.com/,/speakerdeck.com/,/download.svcat.sh/,/blog.fabric8.io/,/blog.heptio.com/,/blog.containership.io/,/blog.mobyproject.org/,/blog.spinnaker.io/,/coscale.com/,/zh.wikipedia.org/,/labs.play-with-k8s.com/,/cilium.readthedocs.io/,/azure.microsoft.com/,/storageos.com/,/openid.net/,/prometheus.io/,/coreos.com/,/openwhisk.incubator.apache.org/" $(BOOK_OUTPUT)
|
||||
|
||||
.PHONY: install
|
||||
install:
|
||||
npm install gitbook-cli -g
|
||||
gitbook install
|
||||
gem install html-proofer
|
||||
@$(docker) gitbook install
|
||||
|
||||
.PHONY: serve
|
||||
serve:
|
||||
@$(docker) gitbook serve . $(BOOK_OUTPUT)
|
||||
|
||||
.PHONY: epub
|
||||
epub:
|
||||
@$(docker) gitbook epub . $(BOOK_NAME).epub
|
||||
|
||||
.PHONY: pdf
|
||||
pdf:
|
||||
@$(docker) gitbook pdf . $(BOOK_NAME).pdf
|
||||
|
||||
.PHONY: mobi
|
||||
mobi:
|
||||
@$(docker) gitbook mobi . $(BOOK_NAME).mobi
|
||||
|
||||
.PHONY: clean
|
||||
clean:
|
||||
|
|
|
|||
|
|
@ -0,0 +1,48 @@
|
|||
BOOK_NAME := kubernetes-handbook
|
||||
BOOK_OUTPUT := _book
|
||||
|
||||
.PHONY: build
|
||||
build:
|
||||
gitbook build . $(BOOK_OUTPUT)
|
||||
cp images/apple-touch-icon-precomposed-152.png $(BOOK_OUTPUT)/gitbook/images
|
||||
|
||||
.PHONY: lint
|
||||
lint:
|
||||
htmlproofer --url-ignore "/localhost/,/172.17.8.101/,/172.20.0.113/,/slideshare.net/,/grpc.io/,/kiali.io/,/condiut.io/,/twitter.com/,/facebook.com/,/medium.com/,/google.com/,/jimmysong.io/,/openfaas.com/,/linkerd.io/,/layer5.io/,/thenewstack.io/,/blog.envoyproxy.io/,/blog.openebs.io/,/k8smeetup.github.io/,/blog.heptio.com/,/apigee.com/,/speakerdeck.com/,/download.svcat.sh/,/blog.fabric8.io/,/blog.heptio.com/,/blog.containership.io/,/blog.mobyproject.org/,/blog.spinnaker.io/,/coscale.com/,/zh.wikipedia.org/,/labs.play-with-k8s.com/,/cilium.readthedocs.io/,/azure.microsoft.com/,/storageos.com/,/openid.net/,/prometheus.io/,/coreos.com/,/openwhisk.incubator.apache.org/" $(BOOK_OUTPUT)
|
||||
|
||||
.PHONY: serve
|
||||
serve:
|
||||
gitbook serve . $(BOOK_OUTPUT)
|
||||
|
||||
.PHONY: epub
|
||||
epub:
|
||||
gitbook epub . $(BOOK_NAME).epub
|
||||
|
||||
.PHONY: pdf
|
||||
pdf:
|
||||
gitbook pdf . $(BOOK_NAME).pdf
|
||||
|
||||
.PHONY: mobi
|
||||
mobi:
|
||||
gitbook mobi . $(BOOK_NAME).mobi
|
||||
|
||||
.PHONY: install
|
||||
install:
|
||||
npm install gitbook-cli -g
|
||||
gitbook install
|
||||
gem install html-proofer
|
||||
|
||||
.PHONY: clean
|
||||
clean:
|
||||
rm -rf $(BOOK_OUTPUT)
|
||||
|
||||
.PHONY: help
|
||||
help:
|
||||
@echo "Help for make"
|
||||
@echo "make - Build the book"
|
||||
@echo "make build - Build the book"
|
||||
@echo "make serve - Serving the book on localhost:4000"
|
||||
@echo "make install - Install gitbook and plugins"
|
||||
@echo "make epub - Build epub book"
|
||||
@echo "make pdf - Build pdf book"
|
||||
@echo "make clean - Remove generated files"
|
||||
84
README.md
84
README.md
|
|
@ -1,24 +1,59 @@
|
|||
# Kubernetes Handbook——Kubernetes中文指南/云原生应用架构实践手册
|
||||
|
||||
[Kubernetes](http://kubernetes.io)是Google基于[Borg](https://research.google.com/pubs/pub43438.html)开源的容器编排调度引擎，作为[CNCF](http://cncf.io)（Cloud Native Computing Foundation）最重要的组件之一，它的目标不仅仅是一个编排系统，而是提供一个规范，可以让你来描述集群的架构，定义服务的最终状态，Kubernetes可以帮你将系统自动地达到和维持在这个状态。Kubernetes作为云原生应用的基石，相当于一个云操作系统，其重要性不言而喻。
|
||||
[Kubernetes](http://kubernetes.io)是Google基于[Borg](https://research.google.com/pubs/pub43438.html)开源的容器编排调度引擎，作为[CNCF](https://cncf.io)（Cloud Native Computing Foundation）最重要的组件之一，它的目标不仅仅是一个编排系统，而是提供一个规范，可以让你来描述集群的架构，定义服务的最终状态，Kubernetes可以帮你将系统自动地达到和维持在这个状态。Kubernetes作为云原生应用的基石，相当于一个云操作系统，其重要性不言而喻。
|
||||
|
||||
本书记录了本人从零开始学习和使用Kubernetes的心路历程，着重于经验分享和总结，同时也会有相关的概念解析，希望能够帮助大家少踩坑，少走弯路，还会指引大家关于关注Kubernetes生态周边，如微服务构建、DevOps、大数据应用、Service Mesh、Cloud Native等领域。
|
||||
## 关于本书
|
||||
|
||||
本书的主题不仅限于Kubernetes，还包括以下几大主题：
|
||||
<p align="left">
|
||||
<a href="https://circleci.com/gh/rootsongjc/kubernetes-handbook/tree/master">
|
||||
<img src="https://circleci.com/gh/rootsongjc/kubernetes-handbook/tree/master.svg?style=svg" alt="CircleCI"/>
|
||||
</a>
|
||||
</p>
|
||||
|
||||
<p align="center">
|
||||
<a href="https://jimmysong.io/kubernetes-handbook">
|
||||
<img src="cover.jpg" width="50%" height="50%" alt="Kubernetes Handbook——Kubernetes中文指南/云原生应用架构实践手册 by Jimmy Song(宋净超）">
|
||||
</a>
|
||||
</p>
|
||||
|
||||
本书起始于2017年3月，记录了本人从零开始学习和使用Kubernetes的心路历程，着重于经验分享和总结，同时也会有相关的概念解析，希望能够帮助大家少踩坑，少走弯路，还会指引大家关注Kubernetes生态周边，如微服务构建、DevOps、大数据应用、[Service Mesh](https://jimmysong.io/posts/what-is-a-service-mesh/)、Cloud Native等领域。
|
||||
|
||||
### 开始之前
|
||||
|
||||
在阅读本书之前希望您掌握以下知识和准备以下环境：
|
||||
|
||||
- Linux 操作系统原理
|
||||
- Linux 常用命令
|
||||
- Docker 容器原理及基本操作
|
||||
- 一台可以上网的电脑，Mac/Windows/Linux 皆可
|
||||
- 安装 Docker
|
||||
|
||||
### 本书主题
|
||||
|
||||
本书的主题不局限于Kubernetes，还包括以下几大主题：
|
||||
|
||||
- 云原生开源组件
|
||||
- 云原生应用与微服务架构
|
||||
- 基于Kubernete的Service Mesh架构
|
||||
- 基于Kubernetes的Service Mesh架构
|
||||
- Kubernetes与微服务结合实践
|
||||
|
||||
起初写作本书时，安装的所有组件、所用示例和操作等皆基于**Kubernetes1.6+** 版本，同时我们也将密切关注kubernetes的版本更新，随着它的版本更新升级，本书中的Kubernetes版本和示例也将随之更新。
|
||||
起初写作本书时，安装的所有组件、所用示例和操作等皆基于 **Kubernetes 1.6+** 版本，同时我们也将密切关注Kubernetes的版本更新，随着它的版本更新升级，本书中的Kubernetes版本和示例也将随之更新。
|
||||
|
||||
### 使用方式
|
||||
|
||||
您可以通过以下方式使用本书：
|
||||
|
||||
- GitHub地址：https://github.com/rootsongjc/kubernetes-handbook
|
||||
- Gitbook在线浏览：https://jimmysong.io/kubernetes-handbook/
|
||||
- GitBook在线浏览：https://jimmysong.io/kubernetes-handbook/
|
||||
- 下载本书的发行版：https://github.com/rootsongjc/kubernetes-handbook/releases
|
||||
- 按照[说明](https://github.com/rootsongjc/kubernetes-handbook/blob/master/CODE_OF_CONDUCT.md)自行编译成离线版本
|
||||
- Fork 一份添加你自己的笔记自行维护，有余力者可以一起参与进来
|
||||
|
||||
**注意：本书中的 Service Mesh 相关内容已不再维护，请转至 [istio-handbook](https://www.servicemesher.com/istio-handbook) 浏览。**
|
||||
|
||||
## 快速开始
|
||||
|
||||
如果您想要学习Kubernetes和云原生应用架构但是又不想自己从头开始搭建和配置一个集群，那么可以直接使用[**kubernetes-vagrant-centos-cluster**](https://github.com/rootsongjc/kubernetes-vagrant-centos-cluster)项目直接在本地部署一个3节点的分布式集群及其他如Heapster、EFK、Istio等可选组件。
|
||||
如果您想要学习Kubernetes和云原生应用架构但是又不想自己从头开始搭建和配置一个集群，那么可以直接使用[kubernetes-vagrant-centos-cluster](https://github.com/rootsongjc/kubernetes-vagrant-centos-cluster)项目直接在本地部署一个3节点的分布式集群及其他如Heapster、EFK、Istio等可选组件，或者使用更加轻量级的[cloud-native-sandbox](https://github.com/rootsongjc/cloud-native-sandbox)在个人电脑上使用Docker运行单节点的Kubernetes、Istio等组件。
|
||||
|
||||
## 贡献与致谢
|
||||
|
||||
|
|
@ -28,27 +63,43 @@
|
|||
- [查看如何贡献](https://github.com/rootsongjc/kubernetes-handbook/blob/master/CONTRIBUTING.md)
|
||||
- [查看文档的组织结构与使用方法](https://github.com/rootsongjc/kubernetes-handbook/blob/master/CODE_OF_CONDUCT.md)
|
||||
|
||||
## License
|
||||
|
||||
<p align="left">
|
||||
<img src="images/cc4-license.png" alt="CC4 License"/>
|
||||
</p>
|
||||
|
||||
[署名-非商业性使用-相同方式共享 4.0 (CC BY-NC-SA 4.0)](https://creativecommons.org/licenses/by-nc-sa/4.0/deed.zh)
|
||||
|
||||
## Stargazers over time
|
||||
|
||||
[](https://starcharts.herokuapp.com/rootsongjc/kubernetes-handbook)
|
||||
|
||||
## 社区&读者交流
|
||||
|
||||
- **微信群**：K8S&Cloud Native实战，扫描我的微信二维码，[Jimmy Song](http://jimmysong.io/about)，或直接搜索微信号*jimmysong*后拉您入群，请增加备注（姓名-公司/学校/博客/社区/研究所/机构等）。
|
||||
- **微信群**：K8S&Cloud Native实战，扫描我的微信二维码，[Jimmy Song](http://jimmysong.io/about)，添加时请备注姓名-公司/学校/组织/机构等。
|
||||
- **Slack**：全球中文用户可以加入[Kubernetes官方Slack](http://slack.k8s.io)中文频道**cn-users channel**
|
||||
- **知乎专栏**：[云原生应用架构](https://zhuanlan.zhihu.com/cloud-native)
|
||||
- **微信公众号**：扫描下面的二维码关注微信公众号CloudNativeGo（云原生应用架构）
|
||||
- **与我联系**：扫描下面的二维码关注Jimmy Song 的<u>个人微信公众号</u>CloudNativeGo（云原生应用架构）
|
||||
|
||||
<p align="center">
|
||||
<img src="https://github.com/rootsongjc/kubernetes-handbook/blob/master/images/cloud-native-go-wechat-qr-code.jpg?raw=true" alt="云原生应用架构微信公众号二维码"/>
|
||||
<img src="images/cloud-native-go-wechat-qr-code.jpg" alt="云原生应用架构微信公众号二维码"/>
|
||||
</p>
|
||||
|
||||
- **ServiceMesher**：CloudNativeGo的姊妹公众号，旨在加强行业内部交流，促进开源文化构建，推动Service Mesh在企业落地，发布Service Mesh资讯。[加入组织](http://www.servicemesher.com/contact/)。
|
||||
|
||||
- **ServiceMesher**：ServiceMesher 社区公众号，下承 Kubernetes、上接 Serverless，云原生应用的通信层，旨在加强行业内部交流，促进开源文化构建，推动 Kubernetes、Service Mesh、Serverless 等云原生技术在企业落地，发布活动及业界最前沿资讯。[加入组织](http://www.servicemesher.com/contact/)。
|
||||
|
||||
<p align="center">
|
||||
<img src="https://ws1.sinaimg.cn/large/00704eQkgy1fshv989hhqj309k09k0t6.jpg" alt="ServiceMesher微信公众号二维码"/>
|
||||
<img src="images/servicemesher-wechat-public.jpg" alt="ServiceMesher微信公众号二维码"/>
|
||||
</p>
|
||||
|
||||
|
||||
## 读者反馈
|
||||
|
||||
以下是部分读者反馈，希望更多人[加入我们](http://www.servicemesher.com)，共同打造中国质量最高的云原生社区！
|
||||
|
||||
|
||||
|
||||
## 云原生出版物
|
||||
|
||||
以下为本人参与出版的图书。
|
||||
|
|
@ -56,15 +107,12 @@
|
|||
- [Cloud Native Go](https://jimmysong.io/posts/cloud-native-go/) - 基于Go和React的web云原生应用构建指南（Kevin Hoffman & Dan Nemeth著 宋净超 吴迎松 徐蓓 马超 译），电子工业出版社，2017年6月出版
|
||||
- [Python云原生](https://jimmysong.io/posts/cloud-native-python/) - 使用Python和React构建云原生应用（Manish Sethi著，宋净超译），电子工业出版社，2018年6月出版
|
||||
- [云原生Java](https://jimmysong.io/posts/cloud-native-java/) - Spring Boot、Spring Cloud与Cloud Foundry弹性系统设计（Josh Long & Kenny Bastani著，张若飞 宋净超译 ），电子工业出版社，2018年7月出版
|
||||
- [未来架构——从服务化到云原生](https://jimmysong.io/posts/future-architecture-from-soa-to-cloud-native/) - 张亮 吴晟 敖小剑 宋净超 著，电子工业出版社，2019年2月出版
|
||||
- [未来架构——从服务化到云原生](https://jimmysong.io/posts/future-architecture-from-soa-to-cloud-native/) - 张亮 吴晟 敖小剑 宋净超 著，电子工业出版社，2019年3月出版
|
||||
|
||||
## 支持本书
|
||||
|
||||
为贡献者加油！为云原生干杯🍻！
|
||||
|
||||
使用微信扫一扫请贡献者喝一杯☕️
|
||||
为云原生干杯🍻！使用微信扫一扫请我喝一杯☕️
|
||||
|
||||
<p align="center">
|
||||
<img src="https://github.com/rootsongjc/kubernetes-handbook/blob/master/images/wechat-appreciate-qrcode.jpg?raw=true" alt="微信赞赏码"/>
|
||||
<img src="images/wechat-appreciate-qrcode.jpg" alt="微信赞赏码"/>
|
||||
</p>
|
||||
|
||||
|
|
|
|||
27
SUMMARY.md
27
SUMMARY.md
|
|
@ -6,12 +6,11 @@
|
|||
|
||||
## 云原生
|
||||
|
||||
* [云原生的定义](cloud-native/cloud-native-definition.md)
|
||||
* [CNCF - 云原生计算基金会简介](cloud-native/cncf.md)
|
||||
* [CNCF章程](cloud-native/cncf-charter.md)
|
||||
* [云原生（Cloud Native）的定义](cloud-native/cloud-native-definition.md)
|
||||
* [云原生的设计哲学](cloud-native/cloud-native-philosophy.md)
|
||||
* [Play with Kubernetes](cloud-native/play-with-kubernetes.md)
|
||||
* [快速部署一个云原生本地实验环境](cloud-native/cloud-native-local-quick-start.md)
|
||||
* [使用Rancher在阿里云上部署Kubenretes集群](cloud-native/setup-kubernetes-with-rancher-and-aliyun.md)
|
||||
* [Kubernetes与云原生应用概览](cloud-native/kubernetes-and-cloud-native-app-overview.md)
|
||||
* [云原生应用之路——从Kubernetes到Cloud Native](cloud-native/from-kubernetes-to-cloud-native.md)
|
||||
* [云原生编程语言](cloud-native/cloud-native-programming-languages.md)
|
||||
|
|
@ -95,7 +94,7 @@
|
|||
* [Secret配置](guide/secret-configuration.md)
|
||||
* [管理namespace中的资源配额](guide/resource-quota-management.md)
|
||||
* [命令使用](guide/command-usage.md)
|
||||
* [Docker用户过度到kubectl命令行指南](guide/docker-cli-to-kubectl.md)
|
||||
* [Docker用户过渡到kubectl命令行指南](guide/docker-cli-to-kubectl.md)
|
||||
* [kubectl命令概览](guide/using-kubectl.md)
|
||||
* [kubectl命令技巧大全](guide/kubectl-cheatsheet.md)
|
||||
* [使用etcdctl访问kubernetes数据](guide/using-etcdctl-to-access-kubernetes-data.md)
|
||||
|
|
@ -137,7 +136,7 @@
|
|||
* [安装dashboard插件](practice/dashboard-addon-installation.md)
|
||||
* [安装heapster插件](practice/heapster-addon-installation.md)
|
||||
* [安装EFK插件](practice/efk-addon-installation.md)
|
||||
* [使用kubeadm快速构建测试集群](practice/install-kubernetes-with-kubeadm.md)
|
||||
* [生产级的Kubernetes简化管理工具kubeadm](practice/install-kubernetes-with-kubeadm.md)
|
||||
* [使用kubeadm在Ubuntu Server 16.04上快速构建测试集群](practice/install-kubernetes-on-ubuntu-server-16.04-with-kubeadm.md)
|
||||
* [服务发现与负载均衡](practice/service-discovery-and-loadbalancing.md)
|
||||
* [安装Traefik ingress](practice/traefik-ingress-installation.md)
|
||||
|
|
@ -214,7 +213,8 @@
|
|||
* [如何参与Istio社区及注意事项](usecases/istio-community-tips.md)
|
||||
* [Istio教程](usecases/istio-tutorial.md)
|
||||
* [Istio免费学习资源汇总](usecases/istio-tutorials-collection.md)
|
||||
* [深入理解Istio中的Sidecar注入与流量劫持](usecases/understand-sidecar-injection-and-traffic-hijack-in-istio-service-mesh.md)
|
||||
* [深入理解Istio Service Mesh中的Envoy Sidecar注入与流量劫持](usecases/understand-sidecar-injection-and-traffic-hijack-in-istio-service-mesh.md)
|
||||
* [深入理解Istio Service Mesh中的Envoy Sidecar代理的路由转发](usecases/envoy-sidecar-routing-of-istio-service-mesh-deep-dive.md)
|
||||
* [Linkerd](usecases/linkerd.md)
|
||||
* [Linkerd 使用指南](usecases/linkerd-user-guide.md)
|
||||
* [Conduit](usecases/conduit.md)
|
||||
|
|
@ -253,6 +253,15 @@
|
|||
* [社区贡献](develop/contribute.md)
|
||||
* [Minikube](develop/minikube.md)
|
||||
|
||||
## CNCF（云原生计算基金会）
|
||||
|
||||
* [CNCF - 云原生计算基金会简介](cloud-native/cncf.md)
|
||||
* [CNCF章程](cloud-native/cncf-charter.md)
|
||||
* [CNCF特别兴趣小组（SIG）说明](cloud-native/cncf-sig.md)
|
||||
* [开源项目加入CNCF Sandbox的要求](cloud-native/cncf-sandbox-criteria.md)
|
||||
* [CNCF中的项目治理](cloud-native/cncf-project-governing.md)
|
||||
* [CNCF Ambassador](cloud-native/cncf-ambassador.md)
|
||||
|
||||
## 附录
|
||||
|
||||
* [附录说明](appendix/index.md)
|
||||
|
|
@ -268,7 +277,13 @@
|
|||
* [Kubernetes1.10更新日志](appendix/kubernetes-1.10-changelog.md)
|
||||
* [Kubernetes1.11更新日志](appendix/kubernetes-1.11-changelog.md)
|
||||
* [Kubernetes1.12更新日志](appendix/kubernetes-1.12-changelog.md)
|
||||
* [Kubernetes1.13更新日志](appendix/kubernetes-1.13-changelog.md)
|
||||
* [Kubernetes1.14更新日志](appendix/kubernetes-1.14-changelog.md)
|
||||
* [Kubernetes1.15更新日志](appendix/kubernetes-1.15-changelog.md)
|
||||
* [Kubernetes及云原生年度总结及展望](appendix/summary-and-outlook.md)
|
||||
* [Kubernetes与云原生2017年年终总结及2018年展望](appendix/kubernetes-and-cloud-native-summary-in-2017-and-outlook-for-2018.md)
|
||||
* [Kubernetes与云原生2018年年中总结及2019年展望](appendix/kubernetes-and-cloud-native-summary-in-2018-and-outlook-for-2019.md)
|
||||
* [CNCF年度报告解读](appendix/cncf-annual-report.md)
|
||||
* [CNCF 2018年年度报告解读](appendix/cncf-annual-report-2018.md)
|
||||
* [Kubernetes认证服务提供商（KCSP）说明](appendix/about-kcsp.md)
|
||||
* [认证Kubernetes管理员（CKA）说明](appendix/about-cka-candidate.md)
|
||||
|
|
|
|||
|
|
@ -0,0 +1,189 @@
|
|||
# CNCF 2018年年度报告解读
|
||||
|
||||
2019年2月初，CNCF 发布了2018年的年度报告，这是 CNCF 继2017年度报告之后，第二次发布年度报告，2017年度的报告只有区区14页，今年的报告长度增长了一倍达31页。下面我将带大家一起来深度解读下这份2018年的年度报告，一窥 CNCF 过去一年里在推广云原生的道路上取得的进展。
|
||||
|
||||
*注：本文最后附上了2017年和2018年度的报告下载地址。*
|
||||
|
||||
## CNCF 年度报告涵盖的范围
|
||||
|
||||
在解读 CNCF 的2018年度报告之前，我们先简单回顾下[2017年度的报告](https://www.cncf.io/wp-content/uploads/2018/03/CNCF-Annual-Report-2017.pdf)，因为2017年度报告是 CNCF 的首份年度报告，这样我们也能更好的了解 CNCF 的来龙去脉。
|
||||
|
||||
2017年度报告已经基本确定了 CNCF 每个年度报告所包含的主题：
|
||||
|
||||
- 自我定位
|
||||
- 会员参与情况
|
||||
- 终端用户社区
|
||||
- 项目更新
|
||||
- 会议和活动
|
||||
- 社区
|
||||
- 培训和认证
|
||||
|
||||
以上为 CNCF 主要的市场活动，2017年时其成立的第二年，经过一年时间的筹备，这一年里各种市场活动都已经开始确立并有声有色的开展了起来，包括 KubeCon、成员单位、终端用户都已经发展起来了，以后历年里只是对其不断的发展和完善。
|
||||
|
||||
2018年度报告中又新增了一些主题，这些主题是从2018年开始开展的，包括：
|
||||
|
||||
- **项目更新与满意度调查**
|
||||
- 给 CNCF 项目的维护者发调查问卷询问满意度
|
||||
- [CNCF charter](https://www.cncf.io/about/charter/) 的修订（2018年11月）
|
||||
- 项目更新与发布
|
||||
- 项目服务与支援
|
||||
- 专项活动、文档、网站与博客支持
|
||||
- 本地化、IT 支持和培训
|
||||
- **社区拓展**
|
||||
- 社区奖项
|
||||
- CNCF Meetup
|
||||
- [CNCF Ambassador 计划](https://www.cncf.io/people/ambassadors/)
|
||||
- 卡通吉祥物 Phippy
|
||||
- **生态系统工具**
|
||||
- [devstats](https://devstats.cncf.io/)
|
||||
- [CNCF Landscape](https://landscape.cncf.io) 和路线图
|
||||
- 项目 logo 物料
|
||||
- **测试一致性项目**
|
||||
- **国际化**
|
||||
- 进入中国
|
||||
- 本地化网站
|
||||
|
||||
详情请大家从本文最后的链接下载报告原文以查看详情。
|
||||
|
||||
## CNCF 的定位
|
||||
|
||||
CNCF（云原生计算基金会）成立于2015年12月11日，每届年度报告的开篇都会阐明 CNCF 的定位，CNCF 的自我定位在2018年发生了一次变动，这也说明基金会是跟随市场形势而动，其定位不是一成不变的，其中的变化暗含着 CNCF 战略的转变。
|
||||
|
||||
### CNCF 的2017年度定位
|
||||
|
||||
[2017年度报告](https://www.cncf.io/wp-content/uploads/2018/03/CNCF-Annual-Report-2017.pdf)中是这样正式介绍自己的：
|
||||
|
||||
The Cloud Native Computing Foundation (CNCF) is an open source software foundation dedicated to making cloud-native computing universal and sustainable. Cloud-native computing uses an **open source** software stack to deploy applications as **microservices**, packaging each part into its own **container**, and **dynamically orchestrating** those containers to optimize resource utilization. Cloud-native technologies enable software developers to build great products faster.
|
||||
|
||||
We are a community of open source projects, including Kubernetes, Envoy and Prometheus. Kubernetes and other CNCF projects are some of the highest velocity projects in the history of open source.
|
||||
|
||||
可以看到介绍中的重点技术是：微服务、容器、动态编排。而在2018年 CNCF 对自己进行了重新的定位和包装，增加了新的内容。
|
||||
|
||||
### CNCF 的2018年度定位
|
||||
|
||||
[2018年度报告](https://www.cncf.io/wp-content/uploads/2019/02/CNCF_Annual_Report_2018_FInal.pdf)中 CNCF 对自己的定位是：
|
||||
|
||||
The Cloud Native Computing Foundation (CNCF) is an open source software foundation dedicated to making cloud native computing universal and sustainable. Cloud native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. **Containers**, **service meshes**, **microservices**, **immutable infrastructure**, and **declarative APIs** exemplify this approach.
|
||||
|
||||
We are a community of open source projects, including Kubernetes, Prometheus, Envoy, and many others. Kubernetes and other CNCF projects are some of the highest velocity projects in the history of open source.
|
||||
|
||||
我们可以看到其表述中更加注重多云环境，主要涉及的技术比2017年多了Service Mesh（服务网格）、不可变基础设施和声明式 API。
|
||||
|
||||
## 数读报告
|
||||
|
||||
CNCF 年度报告的原文主要是汇报了 CNCF 一年来的所展开的活动和进展，下表示根据 CNCF 2017和2018年度报告整理了关键数据。
|
||||
|
||||
| **Year** | **2016** | **2017** | **2018** |
|
||||
| ------------------------------------------ | -------- | -------- | -------- |
|
||||
| **Members** | 63 | 170 | 365 |
|
||||
| **Contributors** | - | 18687 | 47358 |
|
||||
| **CNCF Meetup Members** | - | 53925 | 89112 |
|
||||
| **Projects** | 4 | 14 | 32 |
|
||||
| **End User Community Members** | - | 32 | 69 |
|
||||
| **Conference and Events Participants** | - | 4085 | - |
|
||||
| **Certified Kubernetes Partners** | - | 44 | - |
|
||||
| **Certified Kubernetes Service Providers** | - | 28 | 74 |
|
||||
| **CNCF Ambassador** | - | - | 65 |
|
||||
| **Kubernetes Training Partners** | - | - | 18 |
|
||||
|
||||
**注**：其中2016年是 CNCF 正式开始工作的第一年，大部分数据因为活动尚未开展而缺失。
|
||||
|
||||
从上表中我们可以看到 CNCF 诞生三年来基金会成员规模、托管项目的贡献者、参加 CNCF 名义的 Meetup 的人数取得较大范围的增长，尤其是2018年，因为基金会成员的爆发式增长（+130%），CNCF 开始给成员分级，会员级别、费用和权益也在 [CNCF 官网](https://www.cncf.io/about/join/)上明码标价。
|
||||
|
||||
2018年 CNCF 组织的 KubeCon&CloudNativeCon 开始固定每年在西欧、北美和中国举行，且2018年是首次进入中国；原来的 Certified Kubernetes Partners 也取消了变成了 Certified Kubernetes Service Providers；CNCF 的 [Ambassador](https://www.cncf.io/people/ambassadors/) 计划拥有了来自15个国家的65位 Ambassador，在世界各地为云原生布道；CNCF 还首次引入了 Kubernetes Training Partner。
|
||||
|
||||
2018 年 CNCF 又推出了一系列新的认证（CKA 为2017年推出），包括：
|
||||
|
||||
- [CKA](https://www.cncf.io/certification/cka/)（Kubernetes 管理员认证）：这是 CNCF 最早制定的一个证书，顾名思义，通过该认证证明用户具有管理 Kubernetes 集群的技能、知识和能力。虽然该证书在2017年即推出，但2018年对考试做了更细致的指导。KCSP 要求企业必须有至少三人通过 CKA。
|
||||
- [CKAD](https://www.cncf.io/certification/ckad/)（Kubernetes 应用开发者认证）：该认证证明用户可以为 Kubernetes 设计、构建、配置和发布云原生应用程序。经过认证的 Kubernetes Application Developer 可以定义应用程序资源并使用核心原语来构建、监控 Kubernetes 中可伸缩应用程序和排除故障。
|
||||
- [KCSP](https://www.cncf.io/certification/kcsp/)（Kubernetes 服务提供商认证）：截止本文发稿时共有74家企业通过该认证。该认证的主体是企业或组织，通过 KCSP 的企业意味着可以为其他组织提供 Kubernetes 支持、咨询、专业服务和培训。通过该认证的中国企业有：灵雀云、阿里云、博云、才云、DaoCloud、EasyStack、易建科技、精灵云、谐云科技、华为、时速云、星号科技、睿云智合、沃趣、元鼎科技、ZTE。
|
||||
- [Certified Kubernetes Conformance](https://www.cncf.io/certification/software-conformance/)（Kubernetes 一致性认证）：通过该认证的 Kubernetes 提供商所提供的服务，意味着其可以保证 Kubernetes API 的可移植性及跨云的互操作性；及时更新到最新的 Kubernetes 版本；是否一致是可以通过[运行开源脚本](https://github.com/cncf/k8s-conformance/blob/master/instructions.md)验证的。截止本文发稿通过该认证的中国企业的发行版有：灵雀云（ACE、ACP、AKS）、才云 Compass、华为 FusionStage、酷栈科技 CStack MiaoYun、Daocloud Enterprise、新智认知新氦云、浪潮云、京东 TIG、网易云、七牛云、同方有云、睿云智合 WiseCloud；通过认证的中国企业托管平台有：阿里云、百度云、博云、EasyStack、易建科技、谐云科技、华为云 CCE、腾讯云 TKE、时速云、ZTE TECS。
|
||||
|
||||
以上是 CNCF 提供的主要证书，一般通过 KCSP 的企业都要先通过 Kubernetes 一致性认证，而通过 Kubernetes 一致性认证不一定要同时通过 KCSP，所以我们看到很多通过 Kubernetes 一致性认证的企业就不一定会通过 KCSP，因为 KCSP 的要求更多，至少要成为 CNCF 会员才可以。
|
||||
|
||||
下面将就 CNCF 会员、托管项目的成熟度等级划分、Kubernetes 服务提供商认证和 Kubernetes 提供商认证做详细说明。
|
||||
|
||||
## CNCF 会员
|
||||
|
||||
2018年 CNCF 的会员单位经历了爆发式增长，从170家增长到365家。CNCF 制定了如下的会员等级：
|
||||
|
||||
- Silver Member
|
||||
- Gold Member
|
||||
- Platinum Member
|
||||
- Academic/Nonprofit Member
|
||||
- End User Member
|
||||
|
||||
不同等级的会员需要交纳的年费与权益不同，详情请见 <https://www.cncf.io/about/join/>。
|
||||
|
||||
### 成为 CNCF 会员的好处
|
||||
|
||||
成为 CNCF 会员包括但不限于如下好处：
|
||||
|
||||
- 将可以参与 CNCF 市场委员会、CNCF Webinar、在 CNCF 和 Kubernetes 官网发表博客、博客被 KubeWeekly 收录、
|
||||
- 获得 KubeCon + CloudNativeCon 的门票折扣和参与大会的市场活动
|
||||
- 对于 Kubernetes 系列认证如 KCSP、入选 TOC 也要求必须成为 CNCF 会员才可以获得
|
||||
- End User Case Study
|
||||
- 有机会加入 Ambassador 计划
|
||||
- 在社区里具有更多的话语权，例如 CNCF 在全球范围内组织的活动
|
||||
|
||||
## 项目成熟度等级
|
||||
|
||||
自2015年底 CNCF 创立之初 Kubernetes 成为其首个托管项目以来，截止到2018年底，CNCF 已经托管了[32个开源项目](https://www.cncf.io/projects/)，随着越来越多的项目加入到 CNCF，为了更好的管理这些项目，为这些项目划分不同的成熟度等级就成了迫在眉睫的事情。
|
||||
|
||||
|
||||
|
||||
根据《Crossing the Chasm》一书中的技术采用生命周期理论，CNCF 将其托管的项目划分为三个等级：
|
||||
|
||||
- Graduated：对应于早期成熟项目。截止到本文发稿时只有 [Kubernetes](https://kubernetes.io/)、[Prometheus](https://prometheus.io/)、[Envoy](https://www.envoyproxy.io/) 和 [CoreDNS](https://coredns.io/) 毕业。
|
||||
- Incubating：对应于早期采用者阶段。截止到本文发稿时有 16 个项目。
|
||||
- Sandbox：对应于创新者阶段。截止到本文发稿时有 12 个项目。
|
||||
|
||||
查看 CNCF 托管的项目列表请访问：https://www.cncf.io/projects/
|
||||
|
||||
CNCF 通过为项目设置成熟度水平是来建议企业应该采用哪些项目。CNCF 中托管的项目通过向 CNCF 的技术监督委员会（TOC）展示其可持续发展性来提高其成熟度：项目的采用率，健康的变化率，有来自多个组织的提交者，采用了 [CNCF 行为准则](https://github.com/cncf/foundation/blob/master/code-of-conduct-languages/zh.md)，实现并维护了核心基础设施倡议（Core Infrastructure Initiative）[最佳实践证书](https://bestpractices.coreinfrastructure.org/)。详细信息在 [毕业标准v1.1](https://github.com/cncf/toc/blob/master/process/graduation_criteria.adoc)。
|
||||
|
||||
## Certified Kubernetes Service Provider
|
||||
|
||||
通过 [KCSP](https://www.cncf.io/certification/kcsp/) 意味着企业具有为其他企业或组织提供 Kubernetes 支持、咨询、专业服务和培训的资质。 2018年又有46家企业通过了[KCSP](https://www.cncf.io/certification/kcsp/)，通过该认证的企业累计达到76家。
|
||||
|
||||
|
||||
|
||||
**如何通过 KCSP**
|
||||
|
||||
要想通过 KCSP 必须满足以下三个条件：
|
||||
|
||||
- 三名或更多工程师通过认证Kubernetes管理员（CKA）考试。*（CKAD考试不计入此要求）*
|
||||
- 支持企业最终用户的商业模式，包括为客户提供驻场工程师
|
||||
- 成为 CNCF 会员
|
||||
|
||||
通过 KCSP 有如下好处：
|
||||
|
||||
- 企业的 logo 会出现在 [Kubernetes Partners](https://kubernetes.io/partners/) 页面
|
||||
- 参加与云原生项目 leader、TOC 成员、CNCF Governing Board 的月度会议
|
||||
- 向终端用户的 leader 寻求帮助
|
||||
|
||||
因为有如上这些好处，为了获得 Kubernetes 项目实施的资质，同时保持与基金会至今的交流，Kubernetes 厂商对该认证都趋之若鹜。
|
||||
|
||||
## Certified Kubernetes offering
|
||||
|
||||
通过 KCSP 认证只代表企业有为他人实施 Kubernetes 项目的资质，而企业自身可能并不对外提供 Kubernetes 平台或服务，这些企业可能只是系统集成商或 ISV，这时候 CNCF 又推出了 Kubernetes 提供商认证。
|
||||
|
||||
Kubernetes 认证的提供商包括 Kubernetes 发行版、托管平台和安装器，通过认证的工具或平台将允许使用 Kubernetes 认证的 Logo，并保证 Kubernetes 一致性认证。
|
||||
|
||||
## 展望 2019
|
||||
|
||||
2018年 Kubernetes 成为 CNCF 孵化的首个毕业项目，根据 CNCF 打造的项目成熟度模型，Prometheus、Envoy、CoreDNS 相继毕业，CNCF 的眼光早已不再仅盯着 Kubernetes 了，[CNCF Landscape](https://landscape.cncf.io) 几乎包揽了所有云计算相关开源项目。可以说 CNCF 早已超出了 Kubernetes 的范畴，而是旨在一个建立在 Kubernetes 为底层资源调度和应用生命周期管理之上的生态系统，CNCF 中还演进出了如 Service Mesh 和 Serverless 之类的分支。
|
||||
|
||||
从 CNCF 2017和2018年度的变化来看，其中已经去掉了”dynamically orchestrating“的字眼，也就意味着 Kubernetes 在容器编排领域已经胜出，进而强调多云环境，同时 CNCF 推动的 Kubernetes 一致性认证也受到众多云厂商的支持，这也意味着 Kubernetes 将成为多云环境 API 一致性的保证。
|
||||
|
||||
CNCF 在2019年的战略将更聚焦于开发者社区，协助尤其是来自终端用户的开发者成为项目的 contributor 和 maintainer，保证终端用户的意见能够在社区里被正确地传达和并最终成功地采纳云原生。
|
||||
|
||||
## 参考
|
||||
|
||||
- [CNCF Annual Report 2017 pdf](https://www.cncf.io/wp-content/uploads/2018/03/CNCF-Annual-Report-2017.pdf)
|
||||
- [CNCF Annual Report 2018 pdf](https://www.cncf.io/wp-content/uploads/2019/02/CNCF_Annual_Report_2018_FInal.pdf)
|
||||
- [CNCF Projects](https://www.cncf.io/projects/)
|
||||
- [CNCF Landscape](https://landscape.cncf.io)
|
||||
- [CNCF Ambassadors](https://www.cncf.io/people/ambassadors/)
|
||||
- [Kubernetes Certified Service Providers](https://www.cncf.io/certification/kcsp/)
|
||||
|
||||
|
|
@ -0,0 +1,8 @@
|
|||
# CNCF年度报告解读
|
||||
|
||||
CNCF成立于2015年12月11日，自2018年开始每年年初都会发布一次 CNCF Annual Report（CNCF 年度报告），总结 CNCF 去年一年里在推广云原生技术和理念上付出的行动和取得的进展，这一章节将从2018年的年度报告开始每年都会解读一次 CNCF 年度报告，2018年的年度报告延续了2017年年度报告的大体分类，但2017年的报告过于精简（只列举了一些活动与数字），本章不对其解读，而是从2018年的年度报告开始，感兴趣的读者可以下载其报告自行阅览。
|
||||
|
||||
## 参考
|
||||
|
||||
- [CNCF Annual Report 2017 pdf](https://www.cncf.io/wp-content/uploads/2018/03/CNCF-Annual-Report-2017.pdf)
|
||||
- [CNCF Annual Report 2018 pdf](https://www.cncf.io/wp-content/uploads/2019/02/CNCF_Annual_Report_2018_FInal.pdf)
|
||||
|
|
@ -20,7 +20,6 @@
|
|||
|
||||
- [swarm mode的路由网络](https://jimmysong.io/docker-handbook/docs/swarm_mode_routing_mesh)
|
||||
|
||||
- [docker扁平化网络插件Shrike（基于docker1.11）](https://github.com/TalkingData/shrike)
|
||||
|
||||
## 存储管理
|
||||
|
||||
|
|
|
|||
|
|
@ -24,7 +24,3 @@
|
|||
## 获取
|
||||
|
||||
Kubernetes1.10已经可以通过[GitHub下载](https://github.com/kubernetes/kubernetes/releases/tag/v1.10.0)。
|
||||
|
||||
## 参考
|
||||
|
||||
[Kubernetes 1.10: Stabilizing Storage, Security, and Networking](http://blog.kubernetes.io/2018/03/kubernetes-1.10-stabilizing-storage-security-networking.html)
|
||||
|
|
@ -0,0 +1,25 @@
|
|||
# Kubernetes 1.13 更新日志
|
||||
|
||||
2018年12月3日，Kubernetes 1.13发布，这是2018年发布的第四个也是最后一个大版本。该版本中最显著地改进包括：
|
||||
|
||||
- 使用 [kubeadm](https://kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm/) 简化集群管理
|
||||
- [CSI](../concepts/csi.md)（容器存储接口），[查看 CSI 规范](https://github.com/container-storage-interface/spec)
|
||||
- [CoreDNS](https://github.com/coredns/coredns) 作为默认的 DNS
|
||||
|
||||
以上功能正式成为 GA（General Available）。
|
||||
|
||||
还有其他一些小的功能更新，例如：
|
||||
|
||||
- 支持第三方设备监控插件成为 alpha 功能。
|
||||
- kubelet 设备插件注册 GA。
|
||||
- 拓扑感知的 Volume 调度进入 stable。
|
||||
- APIServer DryRun 进入 beta。
|
||||
- kubectl diff 进入 beta。
|
||||
- 使用 PV 源的原始块设备进入 beta。
|
||||
|
||||
详细的更新日志请访问 [Kubernetes 1.13: Simplified Cluster Management with Kubeadm, Container Storage Interface (CSI), and CoreDNS as Default DNS are Now Generally Available](https://kubernetes.io/blog/2018/12/03/kubernetes-1-13-release-announcement/)。
|
||||
|
||||
## 参考
|
||||
|
||||
- [Overview of kubeadm](https://kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm/)
|
||||
- [Kubernetes 1.13: Simplified Cluster Management with Kubeadm, Container Storage Interface (CSI), and CoreDNS as Default DNS are Now Generally Available](https://kubernetes.io/blog/2018/12/03/kubernetes-1-13-release-announcement/)
|
||||
|
|
@ -0,0 +1,20 @@
|
|||
# Kubernetes 1.14 更新日志
|
||||
|
||||
北京时间2019年3月26日，Kubernetes 1.14发布，这是2019年发布的第一个版本，距离上个版本发布刚好又是三个月的时间。该版本中最显著地改进包括：
|
||||
|
||||
- 对于管理 Windows node 的生产级支持。
|
||||
- 重写了 kubectl 的文档，并为其专门启用新域名 <https://kubectl.docs.kubernetes.io/>，该文档本身类似 Gitbook 的形式，使用 Resource Config 的形式组织，集成了 [kustomize](https://github.com/kubernetes-sigs/kustomize)，还有了自己的 logo 和吉祥物 kubee-cuddle。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
- kubectl 插件机制发布稳定版本。
|
||||
- Persistent Local Volume GA。
|
||||
- 限制每个 Pod 的 PID 功能发布 beta 版本。
|
||||
|
||||
详细的更新日志请访问 [Kubernetes 1.14: Production-level support for Windows Nodes, Kubectl Updates, Persistent Local Volumes GA](https://kubernetes.io/blog/2019/03/25/kubernetes-1-14-release-announcement/)。
|
||||
|
||||
## 参考
|
||||
|
||||
- [Kubernetes 1.14: Production-level support for Windows Nodes, Kubectl Updates, Persistent Local Volumes GA - kuberentes.io](https://kubernetes.io/blog/2019/03/25/kubernetes-1-14-release-announcement/)
|
||||
|
|
@ -0,0 +1,17 @@
|
|||
# Kubernetes 1.15 更新日志
|
||||
|
||||
北京时间 2019 年 6 月 20 日，Kubernetes 1.15 发布，这是 2019 年的第二个版本，距离上个版本发布刚好又是三个月的时间。该版本中最显著地改进包括：
|
||||
|
||||
- CRD
|
||||
- SIG API Machinery 相关的改进
|
||||
- 集群生命周期的稳定性和可用性的改进，kubeadm 管理的证书轮换得到进一步加强，还有了自己的 logo
|
||||
|
||||
|
||||
|
||||
详细的日志请访问：[Kubernetes 1.15: Extensibility and Continuous Improvement](https://kubernetes.io/blog/2019/06/19/kubernetes-1-15-release-announcement/)。
|
||||
|
||||
## 参考
|
||||
|
||||
- [Kubernetes 1.15: Extensibility and Continuous Improvement](https://kubernetes.io/blog/2019/06/19/kubernetes-1-15-release-announcement/)
|
||||
|
||||
- [Kubernetes 1.15 Changelog](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.15.md)
|
||||
|
|
@ -29,7 +29,7 @@
|
|||
**可扩展性**
|
||||
|
||||
- 运行时的[API聚合](https://kubernetes.io/docs/concepts/api-extension/apiserver-aggregation/)是此版本中最强大的扩展功能，允许高级用户将Kubernetes风格的预先构建的第三方或用户创建的API添加到其集群中。
|
||||
- [容器运行时接口](https://github.com/kubernetes/community/blob/master/contributors/devel/container-runtime-interface.md)（CRI）已经增强，可以使用新的RPC调用从运行时检索容器度量。 [CRI的验证测试](https://github.com/kubernetes/community/blob/master/contributors/devel/cri-validation.md)已经发布，与[containerd](http://containerd.io/)进行了Alpha集成，现在支持基本的生命周期和镜像管理。参考[深入介绍CRI](http://blog.kubernetes.io/2016/12/container-runtime-interface-cri-in-kubernetes.html)的文章。
|
||||
- 容器运行时接口（CRI）已经增强，可以使用新的RPC调用从运行时检索容器度量。 CRI的验证测试已经发布，与[containerd](http://containerd.io/)进行了Alpha集成，现在支持基本的生命周期和镜像管理。参考[深入介绍CRI](http://blog.kubernetes.io/2016/12/container-runtime-interface-cri-in-kubernetes.html)的文章。
|
||||
|
||||
**其它功能**
|
||||
|
||||
|
|
@ -38,10 +38,6 @@
|
|||
|
||||
**弃用**
|
||||
|
||||
- 第三方资源（TPR）已被自定义资源定义（Custom Resource Definitions，CRD）取代，后者提供了一个更清晰的API，并解决了TPR测试期间引发的问题和案例。如果您使用TPR测试版功能，则建议您[迁移](https://kubernetes.io/docs/tasks/access-kubernetes-api/migrate-third-party-resource/)，因为它将在Kubernetes 1.8中被移除。
|
||||
- 第三方资源（TPR）已被自定义资源定义（Custom Resource Definitions，CRD）取代，后者提供了一个更清晰的API，并解决了TPR测试期间引发的问题和案例。如果您使用TPR测试版功能，则建议您迁移，因为它将在Kubernetes 1.8中被移除。
|
||||
|
||||
以上是Kubernetes1.7中的主要新特性，详细更新文档请查看[Changelog](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.7.md)。
|
||||
|
||||
## 参考
|
||||
|
||||
[Kuberentes 1.7: Security Hardening, Stateful Application Updates and Extensibility](http://blog.kubernetes.io/2017/06/kubernetes-1.7-security-hardening-stateful-application-extensibility-updates.html)
|
||||
|
|
@ -25,7 +25,3 @@ Volume快照、PV调整大小、自动taint、pod优先级、kubectl插件等！
|
|||
除了稳定现有的功能，Kubernetes 1.8还提供了许多预览新功能的alpha版本。
|
||||
|
||||
社区中的每个特别兴趣小组（SIG）都在继续为所在领域的用户提供更多的功能。有关完整列表，请访问[发行说明](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.8.md)。
|
||||
|
||||
## 参考
|
||||
|
||||
[Kubernetes 1.8: Security, Workloads and Feature Depth](http://blog.kubernetes.io/2017/09/kubernetes-18-security-workloads-and.html)
|
||||
|
|
@ -4,13 +4,13 @@
|
|||
|
||||
## Workloads API GA
|
||||
|
||||
[apps/v1 Workloads API](https://kubernetes.io/docs/reference/workloads-18-19/)成为GA（General Availability），且默认启用。 Apps Workloads API将**DaemonSet**、**Deployment**、**ReplicaSet**和**StatefulSet** API组合在一起，作为Kubernetes中长时间运行的无状态和有状态工作负载的基础。
|
||||
apps/v1 Workloads API成为GA（General Availability），且默认启用。 Apps Workloads API将**DaemonSet**、**Deployment**、**ReplicaSet**和**StatefulSet** API组合在一起，作为Kubernetes中长时间运行的无状态和有状态工作负载的基础。
|
||||
|
||||
Deployment和ReplicaSet是Kubernetes中最常用的两个对象，经过一年多的实际使用和反馈后，现在已经趋于稳定。[SIG apps](https://github.com/kubernetes/community/tree/master/sig-apps)同时将这些经验应用到另外的两个对象上，使得DaemonSet和StatefulSet也能顺利毕业走向成熟。v1（GA）意味着已经生产可用，并保证长期的向后兼容。
|
||||
|
||||
## Windows支持（beta）
|
||||
|
||||
Kubernetes最初是为Linux系统开发的，但是用户逐渐意识到容器编排的好处，我们看到有人需要在Kubernetes上运行Windows工作负载。在12个月前，我们开始认真考虑在Kubernetes上支持Windows Server的工作。 [SIG-Windows](https://github.com/kubernetes/community/tree/master/sig-windows)现在已经将这个功能推广到beta版本，这意味着我们可以评估它的[使用情况](https://kubernetes.io/docs/getting-started-guides/windows/)。
|
||||
Kubernetes最初是为Linux系统开发的，但是用户逐渐意识到容器编排的好处，我们看到有人需要在Kubernetes上运行Windows工作负载。在12个月前，我们开始认真考虑在Kubernetes上支持Windows Server的工作。 [SIG-Windows](https://github.com/kubernetes/community/tree/master/sig-windows)现在已经将这个功能推广到beta版本，这意味着我们可以评估它的使用情况。
|
||||
|
||||
## 增强存储
|
||||
|
||||
|
|
@ -37,7 +37,3 @@ kube-proxy的IPVS模式进入beta版，为大型集群提供更好的可扩展
|
|||
## 获取
|
||||
|
||||
Kubernetes1.9已经可以通过[GitHub下载](https://github.com/kubernetes/kubernetes/releases/tag/v1.9.0)。
|
||||
|
||||
## 参考
|
||||
|
||||
[Kubernetes 1.9: Apps Workloads GA and Expanded Ecosystem](http://blog.kubernetes.io/2017/12/kubernetes-19-workloads-expanded-ecosystem.html)
|
||||
|
|
@ -0,0 +1,163 @@
|
|||
# Kubernetes与云原生2018年年终总结及2019年展望
|
||||
|
||||
去年我写了[Kubernetes与云原生2017年年终总结及2018年展望](kubernetes-and-cloud-native-summary-in-2017-and-outlook-for-2018.md)，按照惯例也应该推出2018年的总结和2019年的展望了，写这篇文章的时候已经是2019年的1月末了，如果不写点什么回顾下2018年总觉得这一年过的不完整。
|
||||
|
||||
本文将回顾 Kubernetes 与云原生在2018年的进展，可以说2018年是 Kubernetes 大规模落地，Service Mesh 蓄势待发的一年。
|
||||
|
||||
## 2017年时对2018年的预测
|
||||
|
||||
首先我先带大家回顾下2017年时我对2018年的预测。2017年底我预测2018年的Kubernetes和云原生将向以下方向发展：
|
||||
|
||||
- 服务网格（Service Mesh），在Kubernetes上践行微服务架构进行服务治理所必须的组件；
|
||||
- 无服务器架构（Serverless），以FaaS为代表的无服务器架构将会流行开来；
|
||||
- 加强数据服务承载能力，例如在Kubernetes上运行大数据应用；
|
||||
- 简化应用部署与运维包括云应用的监控与日志收集分析等；
|
||||
|
||||
下面我来分别总结下以上四点预测：
|
||||
|
||||
- 其中服务网格（Service Mesh）是我2018年一直在大力主张和推广的，并创立了[ServiceMesher社区](http://www.servicemesher.com)，业界已经对服务网格有了广泛的认知，其在微服务和分布式架构领域将有广阔的前景，2018年7月31日[Istio](https://istio.io)发布1.0，预示着服务网格即将走向成熟；
|
||||
- 无服务器架构的理念提出已久但仍需找到合适的应用场景来大面积铺开，2018年Google、Pivotal等公司新开源的[knative](https://github.com/knative)更加弱化了底层平台的差异，开发者直接定义服务，应用自动打包和部署；
|
||||
- 关于Kubernetes承载大数据计算，已经有很多公司应用它来运行大数据应用，还有一些创业公司提供基于Kubernetes的异构计算平台，在大企业内部也有使用Kubernetes来统一大数据、机器学习、人工智能等平台的需求，大数据行业领先的两家公司Cloudera与Hortonworks的合并势必也会在云原生领域发力；
|
||||
- 随着越来越多的公司选择Kubernetes作为底层的基础设施平台，Kubernetes周边的生态越来越完善，围绕发布部署、监控和APM相关的SaaS类应用层出不穷；
|
||||
|
||||
## CNCF 的毕业项目
|
||||
|
||||
2018年至今按照时间顺序，CNCF中毕业的项目有：
|
||||
|
||||
- 2018年3月：Kubernetes 毕业
|
||||
- 2018年8月，Prometheus 毕业
|
||||
- 2018年11月，Envoy 毕业
|
||||
- 2019年1月，CoreDNS 毕业
|
||||
|
||||
截至本文发稿，已有4个项目毕业，2019将会有更多的项目走向成熟。CNCF 托管的全部项目状态请见：https://www.cncf.io/projects-graduated/
|
||||
|
||||
## Kubernetes在2018年的发展
|
||||
|
||||
2018年3月Kubernetes经过CNCF基金会的投票正式毕业，这意味着它拥有足够多的提交者和贡献人员，并被业界广泛的采纳，已经可以依靠社区的维护健康的发展。关于CNCF项目的毕业标准的详情请参考[CNCF Graduation Criteria v1.1](https://github.com/cncf/toc/blob/master/process/graduation_criteria.adoc)。
|
||||
|
||||
一年里按计划发布了4个版本，详见以下更新日志：
|
||||
|
||||
- [Kubernetes1.10更新日志](../appendix/kubernetes-1.10-changelog.md)
|
||||
- [Kubernetes1.11更新日志](../appendix/kubernetes-1.11-changelog.md)
|
||||
- [Kubernetes1.12更新日志](../appendix/kubernetes-1.12-changelog.md)
|
||||
- [Kubernetes1.13更新日志](../appendix/kubernetes-1.13-changelog.md)
|
||||
|
||||
早在2017年的北美 KubeCon 上就有一种论调说 Kubernetes 正变得 boring，因为它已经越来越成熟，在未来不会出现大的变动，从以上更新日志中也可以看到，大多是一些功能进入 beta 或者 stable 状态，很少有新的功能出现。
|
||||
|
||||
下图是 Google trend 中过去一年来全球搜索 Kubernetes 的趋势图。
|
||||
|
||||
|
||||
|
||||
从图中可以看出 Kubernetes 在全球搜索趋势在2018年底已经达到了最巅峰，2019年可能会开始走下降趋势。
|
||||
|
||||
下图是最近5年来 Kubernetes 关键词的百度指数。
|
||||
|
||||
|
||||
|
||||
上图来自百度指数，可以大体概括 Kubernetes 关键字在中国的搜索情况，同 Kubernetes 在全球的搜索情况一样，可能已经过了巅峰期。
|
||||
|
||||
## Kubernetes Operator
|
||||
|
||||
以 Kubernetes 为核心来运维上层应用，诞生了一种名为”Kubernetes Native“的新型运维方式，真正践行 DevOps 理念的产物，开发者将于软件的运维逻辑写成代码，利用 Kubernetes 的**控制器模式（Controller Pattern）**和 [CRD](../concepts/crd.md) 来扩展 Kubernetes 的 API，各种 Operator 层出不穷，[awesome-operators](https://github.com/operator-framework/awesome-operators) 列举了目前所有的 Operator。例如我们熟悉的 [Istio](https://istio.io) 中就有50个 CRD。
|
||||
|
||||
|
||||
|
||||
CNCF 生态中的诸多应用都已支持 Kubernetes Operator，可以说 Operator 将成为云原生中默认的软件动态运行时管理工具，参考 CoreOS（已被 RedHat 收购，RedHat 已被 IBM 收购） CTO Brandon Philips 的这篇文章 [Introducing the Operator Framework: Building Apps on Kubernetes](https://www.redhat.com/en/blog/introducing-operator-framework-building-apps-kubernetes)。
|
||||
|
||||
## ServiceMesher社区
|
||||
|
||||
下图展示的是 2019 Q1 的软件架构趋势，（图片来自 [Architecture and Design InfoQ Trends Report - January 2019](https://www.infoq.com/articles/architecture-trends-2019)）我们可以看到 Service Mesh 还处于创新者阶段，如果从软件生命周期的全阶段来看，它还只是刚刚进入很多人的眼帘，对于这张的新兴技术，在蚂蚁金服的支持的下创办了 [ServiceMesher 社区](http://www.servicemesher.com)。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
既然 Kubernetes 已经开始变得无聊，2018年落地 Kubernetes 已经不是初创公司的事情了，很多大公司甚至传统企业都开始试水或者大规模落地，在 Kubernetes 进一步成熟之时，以 Kubernetes 为基础向上发展，开辟新的战场就能收获更多的业务场景和需求。
|
||||
|
||||
Kubernetes 并不直接对外提供业务能力，而是作为应用运行的底层平台，在应用和平台间还有一个 Gap，这需要中间件的能力来补充。
|
||||
|
||||
|
||||
|
||||
- 2018年5月，ServiceMesher 社区由蚂蚁金服发起成立。
|
||||
- 2018年5月30日，[Envoy最新官方文档中文版发布——由Service Mesh爱好者倾情奉献](http://www.servicemesher.com/envoy/)。
|
||||
- 2018年6月21日，[启用新的社区logo](http://mp.weixin.qq.com/s?__biz=MzIwNDIzODExOA==&mid=2650165956&idx=2&sn=8ef0f080fd428b6307389fce4546103a&chksm=8ec1ce8db9b6479b846b37e0fdffbc0f1a6b23c17329032af7e1b9e6dc6412966f42edcf08f9&scene=21#wechat_redirect)。
|
||||
- 2018年6月30日，[开启新域名servicemesher.com](http://www.servicemesher.com)。
|
||||
- 2018年6月30日，举办了第一届 Service Mesh Meetup 杭州站，见[ServiceMesher杭州Meetup圆满完成](http://www.servicemesher.com/blog/hangzhou-meetup-20180630/)。
|
||||
- 2018年7月，ServiceMesher 社区成为 [Istio 社区中国合作伙伴](https://istio.io/about/community/)。
|
||||
- 2018年7月29日，举办了第二届 Service Mesh Meetup 北京站，见[第二届Service Mesh Meetup北京站回顾、视频回放和资料下载](http://www.servicemesher.com/blog/beijing-meetup-20180729/)。
|
||||
- 2018年8月25日，举办了第三届 Service Mesh Meetup 深圳站，见[Service Mesh Meetup深圳站回顾、视频回放及PPT资料分享](http://www.servicemesher.com/blog/service-mesh-meetup-shenzhen-20180825/)。
|
||||
- 2018年9月19日，开始了开源电子书 [istio-handbook](https://github.com/rootsongjc/istio-handbook/) 的创作。
|
||||
- 2018年11月13日，[ServiceMesher社区成员聚首KubeCon&CloudNativeCon上海](https://jimmysong.io/posts/kubecon-cloudnativecon-china-2018/)。
|
||||
- 2018年11月25日，举办了第四届 Service Mesh Meetup 上海站，见[第四届 Service Mesh Meetup 上海站活动回顾与资料下载](http://www.servicemesher.com/blog/service-mesh-meetup-shanghai-20181125/)。
|
||||
- 2019年1月6日，举办了第五届 Service Mesh Meetup 广州站，见[第五届 Service Mesh Meetup 广州站活动回顾与资料下载](http://www.servicemesher.com/blog/service-mesh-meetup-guangzhou-20190106/)。
|
||||
|
||||
|
||||
## Service Mesh Meetup
|
||||
|
||||
这一年 [ServiceMesher 社区](http://www.servicemesher.com)为大家带来5次 Meetup 共 20 次 Topic 分享：
|
||||
|
||||
- 敖小剑（蚂蚁金服）：大规模微服务架构下的 Service Mesh 探索之路
|
||||
- 刘超（网易）：网易云的 Service Mesh 产品架构和实现
|
||||
- 唐鹏程（才云科技）：在 Kubernetes 上搭建高可用 Service Mesh 监控
|
||||
- 徐运元（谐云科技）：Service Mesh 结合容器云平台的思考与实践
|
||||
- 张亮（京东金融数据研发负责人）：Service Mesh的延伸 —— 论道Database Mesh
|
||||
- 吴晟（Apache SkyWalking创始人）：Observability on Service Mesh —— Apache SkyWalking 6.0
|
||||
- 朵晓东（蚂蚁金服，高级技术专家）：蚂蚁金服开源的Service Mesh数据平面SOFA MOSN深层揭秘
|
||||
- 丁振凯（新浪微博，微博搜索架构师）：微博Service Mesh实践 - WeiboMesh
|
||||
- 张超盟（华为）：Kubernetes容器应用基于Istio的灰度发布实践
|
||||
- 朱经惠 （联邦车网）：Istio控制平面组件原理解析
|
||||
- 邵俊雄（蚂蚁金服）：SOFAMesh 的通用协议扩展
|
||||
- 杨文（JEX）：Kubernetes、Service Mesh、CI/CD 实践
|
||||
- 吴晟（Apache SkyWalking 创始人）：Observability and Istio telemetry
|
||||
- 敖小剑&张瑜标（蚂蚁金服）：蚂蚁金服 Service Mesh 渐进式迁移方案
|
||||
- 徐运元（谐云科技）：探讨和实践基于Isito的微服务治理事件监控
|
||||
- 冯玮（七牛容器云平台产品架构师）：Envoy、Contour与Kubernetes实践
|
||||
- 郑德惠（唯品会Java资深开发工程师）：唯品会的Service Mesh 实践与分享
|
||||
- 陈逸凡（蚂蚁金服）：SOFAMosn 持续演进路径及实践案例
|
||||
- 崔秀龙（HPE 软件分析师）：在网格的边缘试探——企业 Istio 试水指南
|
||||
- 宋净超（蚂蚁金服）：Service Mesh 圆桌讨论
|
||||
|
||||
## Serverless
|
||||
|
||||
我们再看 CNCF 的 [Landscape](https://landscape.cncf.io/)，其中右下部分有一个单列的 Serverless 单元，详见 <https://landscape.cncf.io/>。
|
||||
|
||||
|
||||
|
||||
我们再看下 Kubernetes、Service Mesh、Serviceless 三者之间的关系：
|
||||
|
||||
- Kubernetes 负责应用的生命周期管理，最小的治理单元是 Pod；
|
||||
- Service Mesh 解决服务间的流量治理，最小的治理单元是 Service（可以类比为 Kubernetes 中 Service 资源）；
|
||||
- 而 Serviceless 是更高一层的抽象，最小的治理单元是 APP；
|
||||
|
||||
越向上层就越不关心应用的底层实现，到了 Serverless 开发者只需要关心代码逻辑，其他的一起都是配置，因此 Google 联合 Pivotal 等其他公司于2018年7月创建了 [knative](https://github.com/knative) 这个基于 Kubernetes 和 Istio 的 Serverless 的开源项目。
|
||||
|
||||
## 出版物
|
||||
|
||||
一个繁荣的生态将有大量的开发者支持，有开发者的地方就会有出版物。2018年至本文发稿关于 Kubernetes 和云原生的中文出版物（译作或原著），根据出版时间排序如下：
|
||||
|
||||
- 2018年3月：[《每天5分钟玩转Kubernetes》，CloudMan 著](https://item.jd.com/12329528.html)
|
||||
- 2018年7月：[《Python 云原生——构建应对海量用户数据的高可扩展 Web 应用》，Manish Sathi著，宋净超 译](https://item.jd.com/12365097.html)
|
||||
- 2018年7月：[《云原生 Java——Spring Boot、Spring Cloud 与 Cloud Foundry 弹性系统设计》，Josh Long & Kenny Bastani著，张若飞 宋净超 译](https://item.jd.com/12398618.html)
|
||||
- 2018年8月：[《Kubernetes 权威指南：企业级容器云实战》，闫健勇 龚正 吴治辉 刘晓红 崔秀龙 等 著](https://item.jd.com/12420042.html)
|
||||
- 2018年9月：[《云原生基础架构：构建和管理现代可扩展基础架构的模式及实践》，Justin Garrision & Kris Nova著，孙杰、肖力 译](https://item.jd.com/12432007.html)
|
||||
- 2018年9月：[《基于Kubernetes的容器云平台实战》，陆平 左奇 付光 张晗 著](https://item.jd.com/12433425.html)
|
||||
- 2018年10月：[《Kubernetes经典实例》，Sébastien Goasguen & Michael Hausenblas 著，马晶慧 译](https://item.jd.com/12446081.html)
|
||||
- 2018年11月：[《持续演进的Cloud Native：云原生架构下微服务最佳实践》，王启军 著](https://item.jd.com/12452009.html)
|
||||
- 2018年11月：[《云原生分布式存储基石：etcd深入解析》，华为容器服务团队 杜军 等著](https://item.jd.com/12455265.html)
|
||||
- 2018年12月：[《Kubernetes即学即用》，Kelsey Hightower & Brendan Burns & Joe Beda 著，韩波 译](https://item.jd.com/12476325.html)
|
||||
- 2018年12月：[《Kubernetes 进阶实战》，马永亮 著](https://item.jd.com/12477105.html)
|
||||
- 2018年12月：[《Service Mesh实战：基于Linkerd和Kubernetes的微服务实践》，杨章显 著](https://item.jd.com/12494016.html)
|
||||
- 2019年1月：[《深入浅出 Istio：Service Mesh 快速入门与实践》，崔秀龙 著](https://item.jd.com/12527008.html)
|
||||
- 2019年1月：[《Kubernetes in Action中文版，Marko Luksa著，七牛容器云团队 译](https://item.jd.com/12510666.html)
|
||||
|
||||
**注**：以上仅列举了2018年至本文发稿时已上市发售的书籍，并不代表本人立场推荐以上书籍。
|
||||
|
||||
预告：2019年2月，[《未来架构——从服务化到云原生》张亮 吴晟 敖小剑 宋净超 著](https://jimmysong.io/posts/future-architecture-from-soa-to-cloud-native/)即将上市。
|
||||
|
||||
另外还有很多线上、线下的 Kubernetes 实训课程、电子出版物不胜枚举，例如极客时间出品的[深入剖析 Kubernetes](https://jimmysong.io/posts/kubernetes-tutorial-recommendation/)。
|
||||
|
||||
## 2019年展望
|
||||
|
||||
2019年才开始学 Kubernetes 依然不晚，这可能是影响云计算未来10年的技术，甚至有人预测，未来的开发者可能一上手就是在云上开发，从提交代码、测试到发布一气呵成，直接基于 Git 操作即可完成，完全感受不到 Kubernetes 的存在。展望2019年，我在2017年的预测的趋势依然不变，2019年将更加深化。如果以 Kubernetes 的发展阶段类比，就像2017年时的 Kubernetes 一样，在一部分企业中 Service Mesh 已经开始快速落地，而 Knative 更像 2015 年时的 Kubernetes，一起才刚刚开始，毕竟也是 2018 年中才开源。
|
||||
|
||||
2018年11月 CNCF 在上海举办了第一届中国 KubeCon + CloudNativeCon，2019年6月大会将升级为 KubeCon + CloudNativeCon + Open Source Summit，将进一步推送中国的开源发展与云原生的应用，[查看大会详情](https://www.lfasiallc.com/events/kubecon-cloudnativecon-china-2019/)。
|
||||
|
|
@ -11,6 +11,9 @@
|
|||
- 2017年12月15日，[Kubernetes1.9发布](kubernetes-1.9-changelog.md)
|
||||
- 2018年3月26日，[Kubernetes1.10发布](kubernetes-1.10-changelog.md)
|
||||
- 2018年6月27日，[Kubernetes1.11发布](kubernetes-1.11-changelog.md)
|
||||
- 2018年9月27日，[Kubernetes1.12发布](kubernetes-1.12-changelog.md)
|
||||
- 2018年12月3日，[Kubernetes1.13发布](kubernetes-1.13-changelog.md)
|
||||
- 2019年3月26日，[Kubernetes 1.14发布](kubernetes-1.14-changelog.md)
|
||||
|
||||
## 更多
|
||||
|
||||
|
|
|
|||
|
|
@ -2,13 +2,26 @@
|
|||
|
||||
授人以鱼，不如授人以渔。下面的资料将有助于大家了解kubernetes生态圈当前发展状况和发展趋势，我特此整理相关资料如下。
|
||||
|
||||
## 社区资源
|
||||
|
||||
Kubernetes 社区的贡献、交流和治理方式相关的内容都保存在 <https://github.com/kubernetes/community> 这个 repo 中，建议参与 Kubernetes 社区前先阅读该 repo 中的资料。
|
||||
|
||||
在这里你可以找到：
|
||||
|
||||
- Kubernetes 的各个 SIG 联系方式、会议记录等
|
||||
- 社区贡献指南
|
||||
- 社区成员的角色分类与职责
|
||||
- 社区贡献的 Kubernetes 资源图标
|
||||
|
||||
|
||||
|
||||
## 生态环境
|
||||
|
||||
包括kubernetes和cloud native相关的开源软件、工具和全景图。
|
||||
|
||||
- [awesome-kubernetes](https://github.com/ramitsurana/awesome-kubernetes) - A curated list for awesome kubernetes sources 🚢🎉 [https://ramitsurana.github.io/awesome…](https://ramitsurana.github.io/awesome-kubernetes)
|
||||
- [awesome-kubernetes](https://github.com/ramitsurana/awesome-kubernetes) - A curated list for awesome kubernetes sources 🚢🎉 [https://ramitsurana.github.io/awesome-kubernetes](https://ramitsurana.github.io/awesome-kubernetes)
|
||||
- [awesome-cloud-native](https://github.com/rootsongjc/awesome-cloud-native/) - A curated list for awesome cloud native architectures <https://jimmysong.io/awesome-cloud-native/>
|
||||
- [cloud native landscape](https://github.com/cncf/landscape) - Cloud Native Landscape [https://cncf.io](https://cncf.io/)
|
||||
- [cloud native landscape](https://github.com/cncf/landscape) - Cloud Native Landscape [https://landscape.cncf.io](https://landscape.cncf.io/)
|
||||
|
||||
## 开源书籍和教程
|
||||
|
||||
|
|
@ -31,12 +44,12 @@ Kubernetes和Cloud Native相关网站、专栏、博客等。
|
|||
### 网站与专栏
|
||||
|
||||
- [thenewstack.io](https://thenewstack.io/)
|
||||
- [k8sport.org](http://k8sport.org/)
|
||||
- [giantswarm blog](https://blog.giantswarm.io/)
|
||||
- [k8smeetup.com](http://www.k8smeetup.com)
|
||||
- [dockone.io](http://www.dockone.io)
|
||||
- [Cloud Native知乎专栏](https://zhuanlan.zhihu.com/cloud-native)
|
||||
- [kubernetes.org.cn](https://www.kubernetes.org.cn/)
|
||||
- [servicemesher.com](https://www.servicemesher.com)
|
||||
|
||||
### 博客
|
||||
|
||||
|
|
@ -67,7 +80,6 @@ Kubernetes和Cloud Native相关网站、专栏、博客等。
|
|||
- [sysdig](https://sysdig.com/blog/)
|
||||
- [spinnaker](https://blog.spinnaker.io)
|
||||
- [supergiant](https://supergiant.io/blog)
|
||||
- [thecodeteam](https://blog.thecodeteam.com/)
|
||||
- [twistlock](https://www.twistlock.com/blog/)
|
||||
- [vamp](https://medium.com/vamp-io)
|
||||
- [weave](https://www.weave.works/blog/)
|
||||
|
|
|
|||
|
|
@ -35,7 +35,7 @@ spec:
|
|||
|
||||
我们可以在 Pod 中为容器使用 command 为容器指定启动参数：
|
||||
|
||||
```Bash
|
||||
```bash
|
||||
command: ["/bin/bash","-c","bootstrap.sh"]
|
||||
```
|
||||
|
||||
|
|
@ -205,7 +205,7 @@ data:
|
|||
["8.8.8.8", "8.8.4.4"]
|
||||
```
|
||||
|
||||
`upstreamNameservers` 即使用的外部DNS，参考：[Configuring Private DNS Zones and Upstream Nameservers in Kubernetes](http://blog.kubernetes.io/2017/04/configuring-private-dns-zones-upstream-nameservers-kubernetes.html)
|
||||
`upstreamNameservers` 即使用的外部DNS。
|
||||
|
||||
## 8. 创建一个CentOS测试容器
|
||||
|
||||
|
|
|
|||
27
book.json
27
book.json
|
|
@ -1,20 +1,19 @@
|
|||
{
|
||||
"title": "Kubernetes Handbook - Kubernetes中文指南/云原生应用架构实践手册 by Jimmy Song(宋净超)",
|
||||
"description": "Kubernetes Handbook - Kubernetes中文指南/云原生应用架构实践手册，本书记录了本人从零开始学习和使用Kubernetes的心路历程，着重于经验分享和总结，同时也会有相关的概念解析，希望能够帮助大家少踩坑，少走弯路，还会指引大家关于关注Kubernetes生态周边，如微服务构建、DevOps、大数据应用、Service Mesh、Cloud Native等领域。",
|
||||
"description": "Kubernetes Handbook - Kubernetes中文指南/云原生应用架构实践手册，本书记录了本人从零开始学习和使用Kubernetes的心路历程，着重于经验分享和总结，同时也会有相关的概念解析，希望能够帮助大家少踩坑，少走弯路，还会指引大家关注Kubernetes生态周边，如微服务构建、DevOps、大数据应用、Service Mesh、Cloud Native等领域。",
|
||||
"language": "zh-hans",
|
||||
"author": "Jimmy Song（宋净超）",
|
||||
"links": {
|
||||
"sidebar": {
|
||||
"Jimmy Song": "https://jimmysong.io",
|
||||
"Awesome Cloud Native": "https://jimmysong.io/awesome-cloud-native",
|
||||
"ServiceMesher社区": "http://www.servicemesher.com",
|
||||
"Istio Handbook - Istio 中文指南/服务网格实践手册": "https://jimmysong.io/istio-handbook",
|
||||
"Awesome Service Mesh": "http://www.servicemesher.com/awesome-servicemesh",
|
||||
"ServiceMesher社区": "https://www.servicemesher.com",
|
||||
"Istio Handbook - Istio服务网格进阶实战": "https://www.servicemesher.com/istio-handbook",
|
||||
"Serverless Handbook - 无服务器架构实践手册": "https://jimmysong.io/serverless-handbook",
|
||||
"Cloud Native Go - 基于Go和React的web云原生应用构建指南": "https://jimmysong.io/posts/cloud-native-go",
|
||||
"Cloud Native Python（Python云原生） - 使用Python和React构建云原生应用": "https://jimmysong.io/posts/cloud-native-python",
|
||||
"Cloud Native Java（云原生Java）- Spring Boot、Spring Cloud与Cloud Foundry弹性系统设计": "https://jimmysong.io/posts/cloud-native-java",
|
||||
"SOFAMesh - 基于Istio的大规模服务网格解决方案": "https://github.com/alipay/sofa-mesh",
|
||||
"SOFAMosn - Golang版的高性能Service Mesh Sidecar代理": "https://github.com/alipay/sofa-mosn"
|
||||
"Cloud Native Java（云原生Java）- Spring Boot、Spring Cloud与CloudFoundry弹性系统设计": "https://jimmysong.io/posts/cloud-native-java",
|
||||
"未来架构——从服务化到云原生": "https://jimmysong.io/posts/future-architecture-from-soa-to-cloud-native/"
|
||||
}
|
||||
},
|
||||
"plugins": [
|
||||
|
|
@ -34,7 +33,9 @@
|
|||
"-highlight", "prism", "prism-themes",
|
||||
"sitemap-general",
|
||||
"lightbox",
|
||||
"adsense"
|
||||
"ga",
|
||||
"copy-code-button",
|
||||
"alerts"
|
||||
],
|
||||
"pluginsConfig": {
|
||||
"theme-default": {
|
||||
|
|
@ -56,7 +57,7 @@
|
|||
"size": "small"
|
||||
},
|
||||
"tbfed-pagefooter": {
|
||||
"copyright": "<p><a href=https://github.com/alipay/sofa-mesh>SOFAMesh - 基于 Istio 的大规模服务网格解决方案</a> | <a href=https://github.com/alipay/sofa-mosn>SOFAMosn - Golang 版的高性能 Service Mesh Sidecar 代理</a></p><p><a href=https://ws4.sinaimg.cn/large/006tNbRwly1fw3ku0cwuhj304g056dgk.jpg data-lightbox=2fd927ee-fa64-4eca-8ed5-6bd72b573a3c>点击关注【云原生应用架构】公众号回复【加群】加入学习群</a> | <a href=https://ws1.sinaimg.cn/large/006tNbRwly1fw3fzx37obj30yi1pdk1r.jpg data-lightbox=2fd927ee-fa64-4eca-8ed5-6bd72b573a33>深入剖析 Kubernetes by 张磊</a></p>Copyright © <a href=https://jimmysong.io>jimmysong.io</a> 2017-2018",
|
||||
"copyright": "<p><a href=https://tva1.sinaimg.cn/large/006y8mN6ly1g7vf4p12rpj30u01hdjwp.jpg data-lightbox=2fd927ee-fa64-4eca-8ed5-6bd72b573rfe>极客时间专栏推荐《深入剖析 Kubernetes》</a> | <a href=https://tva1.sinaimg.cn/large/006y8mN6ly1g7vew6rqmvj304g056weg.jpg data-lightbox=2fd927ee-fa64-4eca-8ed5-6bd72b573a3c>点击关注【云原生应用架构】公众号回复【加群】加入学习群</a></p>Copyright © 2017-2019 | Distributed under <a href=https://creativecommons.org/licenses/by-nc-sa/4.0/deed.zh>CC BY 4.0</a> | <a href=https://jimmysong.io>jimmysong.io</a>",
|
||||
"modify_label": " Updated at ",
|
||||
"modify_format": "YYYY-MM-DD HH:mm:ss"
|
||||
},
|
||||
|
|
@ -75,12 +76,8 @@
|
|||
"sitemap-general": {
|
||||
"prefix": "https://jimmysong.io/kubernetes-handbook/"
|
||||
},
|
||||
"adsense": {
|
||||
"client": "ca-pub-4029167986768912",
|
||||
"slot": "2445941692",
|
||||
"format": "auto",
|
||||
"element": ".page-inner section",
|
||||
"position": "bottom"
|
||||
"ga": {
|
||||
"token": "UA-93485976-1"
|
||||
}
|
||||
}
|
||||
}
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
# 云原生的定义
|
||||
# 云原生（Cloud Native）的定义
|
||||
|
||||
[Pivotal](https://pivotal.io/) 是云原生应用的提出者，并推出了 [Pivotal Cloud Foundry](https://pivotal.io/platform) 云原生应用平台和 [Spring](https://spring.io/) 开源 Java 开发框架，成为云原生应用架构中先驱者和探路者。
|
||||
|
||||
|
|
@ -16,7 +16,7 @@
|
|||
|
||||
## CNCF最初的定义
|
||||
|
||||
到了2015年Google主导成了云原生计算基金会（CNCF），起初CNCF对云原生（Cloud Native）的定义包含以下三个方面：
|
||||
到了2015年Google主导成立了云原生计算基金会（CNCF），起初CNCF对云原生（Cloud Native）的定义包含以下三个方面：
|
||||
|
||||
- 应用容器化
|
||||
- 面向微服务架构
|
||||
|
|
@ -30,14 +30,16 @@
|
|||
|
||||
> Cloud native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach.
|
||||
|
||||
云原生技术帮助公司和机构在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。
|
||||
云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。
|
||||
|
||||
> These techniques enable loosely coupled systems that are resilient, manageable, and observable. Combined with robust automation, they allow engineers to make high-impact changes frequently and predictably with minimal toil.
|
||||
|
||||
这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术可以使开发者轻松地对系统进行频繁并可预测的重大变更。
|
||||
这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术使工程师能够轻松地对系统作出频繁和可预测的重大变更。
|
||||
|
||||
> The Cloud Native Computing Foundation seeks to drive adoption of this paradigm by fostering and sustaining an ecosystem of open source, vendor-neutral projects. We democratize state-of-the-art patterns to make these innovations accessible for everyone.
|
||||
|
||||
云原生计算基金会（CNCF）致力于培育和维护一个厂商中立的开源生态系统，来推广云原生技术。我们通过将最前沿的模式普惠，让这些创新为大众所用。
|
||||
云原生计算基金会（CNCF）致力于培育和维护一个厂商中立的开源生态系统，来推广云原生技术。我们通过将最前沿的模式民主化，让这些创新为大众所用。
|
||||
|
||||
**注**：该定义的中文译本还未正式确定，详见[Cloud Native Definition in Chinese](https://docs.google.com/document/d/1-QhD9UeOqEBxaEiXrFP89EhG5K-MFJ4vsfNZOg6E9co/)。
|
||||
## 参考
|
||||
|
||||
- [CNCF Cloud Native Definition v1.0 - github.com](https://github.com/cncf/toc/blob/master/DEFINITION.md)
|
||||
|
|
@ -2,9 +2,9 @@
|
|||
|
||||
本文旨在帮助您快速部署一个云原生本地实验环境，让您可以基本不需要任何Kubernetes和云原生技术的基础就可以对云原生环境一探究竟。
|
||||
|
||||
另外本环境也可以作为一个Kubernetes及其它云原生应用的测试与演示环境。
|
||||
本文中使用[kubernetes-vagrant-centos-cluster](https://github.com/rootsongjc/kubernetes-vagrant-centos-cluster)在本地使用 Vagrant 启动三个虚拟机部署分布式的Kubernetes集群。
|
||||
|
||||
在GitHub上该repo：https://github.com/rootsongjc/kubernetes-vagrant-centos-cluster
|
||||
如仅需要体验云原生环境和测试服务功能，可以使用更加轻量级的[cloud-native-sandbox](https://github.com/rootsongjc/cloud-native-sandbox)，通过个人电脑的Docker部署单节点的Kubernetes、Istio等云原生环境。
|
||||
|
||||
## 准备环境
|
||||
|
||||
|
|
@ -214,8 +214,6 @@ istioctl create -f yaml/istio-bookinfo/bookinfo-gateway.yaml
|
|||
|
||||
**注意**：`JAEGER_PORT`可以通过`kubectl -n istio-system get svc tracing -o jsonpath='{.spec.ports[0].nodePort}'`获取，`GATEWAY_PORT`可以通过`kubectl -n istio-system get svc istio-ingressgateway -o jsonpath='{.spec.ports[0].nodePort}'`获取。
|
||||
|
||||
详细信息请参阅 https://istio.io/zh/docs/examples/bookinfo/
|
||||
|
||||
|
||||
|
||||
### Vistio
|
||||
|
|
@ -352,5 +350,4 @@ rm -rf .vagrant
|
|||
- [Kubernetes handbook - jimmysong.io](https://jimmysong.io/kubernetes-handbook)
|
||||
- [duffqiu/centos-vagrant](https://github.com/duffqiu/centos-vagrant)
|
||||
- [coredns/deployment](https://github.com/coredns/deployment)
|
||||
- [Kubernetes 1.8 kube-proxy 开启 ipvs](https://mritd.me/2017/10/10/kube-proxy-use-ipvs-on-kubernetes-1.8/#%E4%B8%80%E7%8E%AF%E5%A2%83%E5%87%86%E5%A4%87)
|
||||
- [Vistio—使用Netflix的Vizceral可视化Istio service mesh](https://servicemesher.github.io/blog/vistio-visualize-your-istio-mesh-using-netflixs-vizceral/)
|
||||
- [Vistio—使用Netflix的Vizceral可视化Istio service mesh](http://www.servicemesher.com/blog/vistio-visualize-your-istio-mesh-using-netflixs-vizceral/)
|
||||
|
|
|
|||
|
|
@ -4,15 +4,29 @@
|
|||
|
||||
云原生本身甚至不能称为是一种架构，它首先是一种基础设施，运行在其上的应用称作云原生应用，只有符合云原生设计哲学的应用架构才叫云原生应用架构。
|
||||
|
||||
首先我们将向您解释什么不是云原生基础设施。
|
||||
## 云原生的设计理念
|
||||
|
||||
云原生系统的设计理念如下:
|
||||
|
||||
- 面向分布式设计（Distribution）：容器、微服务、API 驱动的开发；
|
||||
- 面向配置设计（Configuration）：一个镜像，多个环境配置；
|
||||
- 面向韧性设计（Resistancy）：故障容忍和自愈；
|
||||
- 面向弹性设计（Elasticity）：弹性扩展和对环境变化（负载）做出响应；
|
||||
- 面向交付设计（Delivery）：自动拉起，缩短交付时间；
|
||||
- 面向性能设计（Performance）：响应式，并发和资源高效利用；
|
||||
- 面向自动化设计（Automation）：自动化的 DevOps；
|
||||
- 面向诊断性设计（Diagnosability）：集群级别的日志、metric 和追踪；
|
||||
- 面向安全性设计（Security）：安全端点、API Gateway、端到端加密；
|
||||
|
||||
以上的设计理念很多都是继承自分布式应用的设计理念。虽然有如此多的理念但是我们仍然无法辨认什么样的设施才是云原生基础设施，不过可以先用排除法，我将解释什么不是云原生基础设施。
|
||||
|
||||
## 什么不是云原生基础设施？
|
||||
|
||||
云原生基础设施不仅是在公有云上运行基础设施。仅仅因为你从其他人那里租用服务器时间并不会使您的基础设施云原生化。管理IaaS的流程通常与运行物理数据中心没有什么不同，许多将现有基础架构迁移到云的公司都未能获得回报。
|
||||
云原生基础设施不等于在公有云上运行的基础设施。光是租用服务器并不会使您的基础设施云原生化。管理IaaS的流程与运维物理数据中心没什么两样，将现有架构迁移到云上也未必能获得回报。
|
||||
|
||||
云原生不是关于在容器中运行应用程序。当Netflix率先推出云原生基础设施时，几乎所有应用程序都部署了虚拟机映像，而不是容器。打包应用程序的方式并不意味着您将拥有自治系统的可扩展性和优势。即使您的应用程序是通过持续集成和持续交付渠道自动构建和部署的，这并不意味着您可以从可以补充API驱动部署的基础设施中受益。
|
||||
云原生不是指在容器中运行应用程序。Netflix率先推出云原生基础设施时，几乎所有应用程序部署在虚拟机中，而不是在容器中。改变应用程序的打包方式并不意味着就会增加自治系统的可扩展性和优势。即使应用程序是通过CI/CD渠道自动构建和部署的，也不意味着您就可以从增强API驱动部署的基础设施中受益。
|
||||
|
||||
这也并不意味着你只能运行容器编排器（例如Kubernetes和Mesos）。容器编排器提供了云原生基础设施所需的许多平台功能，但并未按预期方式使用这些功能，这意味着您的应用程序会被动态调度以在一组服务器上运行。这是一个非常好的起步，但仍有工作要做。
|
||||
这也并不意味着您只能运行容器编排器（例如Kubernetes和Mesos）。容器编排器提供了云原生基础设施所需的许多平台功能，但并未按预期方式使用这些功能，这意味着您的应用程序会在一组服务器上运行，被动态调度。这是一个非常好的起步，但仍有许多工作要做。
|
||||
|
||||
> **调度器与编排器**
|
||||
>
|
||||
|
|
@ -38,7 +52,7 @@
|
|||
|
||||
为了写好本书，也为了有一个共享词汇表，我们需要定义“云原生应用程序”是什么意思。云原生与12因素应用程序不同，即使它们可能共享一些类似的特征。如果你想了解更多细节，请阅读Kevin Hoffman撰写的“超越12因素应用程序”（O'Reilly，2012）。
|
||||
|
||||
云原生应用程序被设计为在平台上运行，并设计用于弹性，敏捷性，可操作性和可观察性。弹性包含失败而不是试图阻止它们;它利用了在平台上运行的动态特性。敏捷性允许快速部署和快速迭代。可操作性从应用程序内部控制应用程序生命周期，而不是依赖外部进程和监视器。可观察性提供信息来回答有关应用程序状态的问题。
|
||||
云原生应用程序被设计为在平台上运行，并设计用于弹性，敏捷性，可操作性和可观察性。弹性包含失败而不是试图阻止它们；它利用了在平台上运行的动态特性。敏捷性允许快速部署和快速迭代。可操作性从应用程序内部控制应用程序生命周期，而不是依赖外部进程和监视器。可观察性提供信息来回答有关应用程序状态的问题。
|
||||
|
||||
> **云原生定义**
|
||||
>
|
||||
|
|
@ -50,7 +64,7 @@
|
|||
- 健康报告
|
||||
- 遥测数据
|
||||
- 弹性
|
||||
- 声明式的，而不是反应式的
|
||||
- 声明式的，而不是命令式的
|
||||
|
||||
### 微服务
|
||||
|
||||
|
|
@ -64,9 +78,9 @@
|
|||
|
||||
我们无法考虑转向微服务的所有考虑因素。拥有微服务并不意味着您拥有云原生基础设施。如果您想阅读更多，我们推荐Sam Newman的Building Microservices（O'Reilly，2015）。虽然微服务是实现您的应用程序灵活性的一种方式，但正如我们之前所说的，它们不是云原生应用程序的必需条件。
|
||||
|
||||
> **健康报告**
|
||||
>
|
||||
> 停止逆向工程应用程序并开始从内部进行监控。 - Kelsey Hightower，Monitorama PDX 2016：healthz
|
||||
### 健康报告
|
||||
|
||||
> 停止逆向工程应用程序并开始从内部进行监控。 —— Kelsey Hightower，Monitorama PDX 2016：healthz
|
||||
|
||||
没有人比开发人员更了解应用程序需要什么才能以健康的状态运行。很长一段时间，基础设施管理员都试图从他们负责运行的应用程序中找出“健康”该怎么定义。如果不实际了解应用程序的健康状况，他们尝试在应用程序不健康时进行监控并发出警报，这往往是脆弱和不完整的。
|
||||
|
||||
|
|
@ -139,7 +153,7 @@
|
|||
|
||||
设计具有弹性的应用程序可能是整本书本身。我们将在云原生应用程序中考虑弹性的两个主要方面：为失败设计和优雅降级。
|
||||
|
||||
### 为失败设计
|
||||
#### 为失败设计
|
||||
|
||||
唯一永远不会失败的系统是那些让你活着的系统（例如心脏植入物和刹车系统）。如果您的服务永远不会停止运行，您需要花费太多时间设计它们来抵制故障，并且没有足够的时间增加业务价值。您的SLO确定服务需要多长时间。您花费在工程设计上超出SLO的正常运行时间的任何资源都将被浪费掉。
|
||||
|
||||
|
|
@ -151,13 +165,13 @@
|
|||
|
||||
知道应用程序可能失败的每种方式是不可能的。假设任何事情都可能并且可能会失败，这是一种云原生应用程序的模式。
|
||||
|
||||
您的应用程序的最佳状态是健康状态。第二好的状态是失败状态。其他一切都是非二进制的，难以监控和排除故障。 Honeycomb首席执行官CharityMajors在她的文章“Ops：现在每个人都在工作”中指出：“分布式系统永远不会起作用;它们处于部分退化服务的持续状态。接受失败，设计弹性，保护和缩小关键路径。“
|
||||
您的应用程序的最佳状态是健康状态。第二好的状态是失败状态。其他一切都是非二进制的，难以监控和排除故障。 Honeycomb首席执行官CharityMajors在她的文章“Ops：现在每个人都在工作”中指出：“分布式系统永远不会起作用；它们处于部分退化服务的持续状态。接受失败，设计弹性，保护和缩小关键路径。”
|
||||
|
||||
无论发生什么故障，云原生应用程序都应该是可适应的。他们期望失败，所以他们在检测到时进行调整。
|
||||
|
||||
有些故障不能也不应该被设计到应用程序中（例如，网络分区和可用区故障）。该平台应自主处理未集成到应用程序中的故障域。
|
||||
|
||||
### 优雅降级
|
||||
#### 优雅降级
|
||||
|
||||
云原生应用程序需要有一种方法来处理过载，无论它是应用程序还是负载下的相关服务。处理负载的一种方式是优雅降级。 “站点可靠性工程”一书中描述了应用程序的优雅降级，因为它提供的响应在负载过重的情况下“不如正常响应准确或含有较少数据的响应，但计算更容易”。
|
||||
|
||||
|
|
@ -165,23 +179,23 @@
|
|||
|
||||
优雅降级的重点是允许应用程序始终返回请求的答案。如果应用程序没有足够的本地计算资源，并且依赖服务没有及时返回信息，则这是正确的。依赖于一个或多个其他服务的服务应该可用于应答请求，即使依赖于服务不是。当服务退化时，返回部分答案或使用本地缓存中的旧信息进行答案是可能的解决方案。
|
||||
|
||||
尽管优雅的降级和失败处理都应该在应用程序中实现，但平台的多个层面应该提供帮助。如果采用微服务，则网络基础设施成为需要在提供应用弹性方面发挥积极作用的关键组件。有关构建弹性网络层的更多信息，请参阅附录A.
|
||||
尽管优雅的降级和失败处理都应该在应用程序中实现，但平台的多个层面应该提供帮助。如果采用微服务，则网络基础设施成为需要在提供应用弹性方面发挥积极作用的关键组件。有关构建弹性网络层的更多信息，请参阅附录A。
|
||||
|
||||
### 可用性数学
|
||||
|
||||
云原生应用程序需要在基础设施之上建立一个平台，以使基础设施更具弹性。如果您希望将现有应用程序“提升并转移”到云中，则应检查云提供商的服务级别协议（SLA），并考虑在使用多个服务时会发生什么情况。
|
||||
|
||||
让我们拿运行我们的应用程序的云来进行假设。
|
||||
|
||||
计算基础设施的典型可用性是每月99.95％的正常运行时间。这意味着您的实例每天可能会缩短到43.2秒，并且仍在您的云服务提供商的SLA中。
|
||||
|
||||
另外，实例的本地存储（例如EBS卷）也具有99.95％的可用性正常运行时间。如果幸运的话，他们都会同时出现故障，但最糟糕的情况是他们可能会在不同的时间停机，让您的实例只有99.9％的可用性。
|
||||
|
||||
您的应用程序可能还需要一个数据库，而不是自己安装一个计算可能的停机时间为1分26秒（99.9％可用性）的情况下，选择可靠性为99.95％的更可靠的托管数据库。这使您的应用程序的可靠性达到99.85％，或者每天可能发生2分钟和9秒的宕机时间。
|
||||
|
||||
将可用性乘到一起可以快速了解为什么应以不同方式处理云。真正不好的部分是，如果云提供商不符合其SLA，它将退还其账单中一定比例的退款。
|
||||
|
||||
虽然您不必为停机支付费用，但我们并不知道世界上存在云计算信用的单一业务。如果您的应用程序的可用性不足以超过您收到的信用额度，那么您应该真正考虑是否应该运行这个应用程序。
|
||||
> **可用性数学**
|
||||
>
|
||||
> 云原生应用程序需要在基础设施之上建立一个平台，以使基础设施更具弹性。如果您希望将现有应用程序“提升并转移”到云中，则应检查云提供商的服务级别协议（SLA），并考虑在使用多个服务时会发生什么情况。
|
||||
>
|
||||
> 让我们拿运行我们的应用程序的云来进行假设。
|
||||
>
|
||||
> 计算基础设施的典型可用性是每月99.95％的正常运行时间。这意味着您的实例每天可能会缩短到43.2秒，并且仍在您的云服务提供商的SLA中。
|
||||
>
|
||||
> 另外，实例的本地存储（例如EBS卷）也具有99.95％的可用性正常运行时间。如果幸运的话，他们都会同时出现故障，但最糟糕的情况是他们可能会在不同的时间停机，让您的实例只有99.9％的可用性。
|
||||
>
|
||||
> 您的应用程序可能还需要一个数据库，而不是自己安装一个计算可能的停机时间为1分26秒（99.9％可用性）的情况下，选择可靠性为99.95％的更可靠的托管数据库。这使您的应用程序的可靠性达到99.85％，或者每天可能发生2分钟和9秒的宕机时间。
|
||||
>
|
||||
> 将可用性乘到一起可以快速了解为什么应以不同方式处理云。真正不好的部分是，如果云提供商不符合其SLA，它将退还其账单中一定比例的退款。
|
||||
>
|
||||
> 虽然您不必为停机支付费用，但我们并不知道世界上存在云计算信用的单一业务。如果您的应用程序的可用性不足以超过您收到的信用额度，那么您应该真正考虑是否应该运行这个应用程序。
|
||||
|
||||
### 声明式，非反应式
|
||||
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@
|
|||
|
||||
下文部分来自Joe Duffy的博客[Hello, Pulumi](http://joeduffyblog.com/2018/06/18/hello-pulumi/)！
|
||||
|
||||
|
||||
|
||||
|
||||
TL;DR 有了Pulumi，38页的手动操作说明将变成了38行代码。25000行YAML配置变成了使用真实编程语言的500行语句。
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,42 @@
|
|||
## CNCF Ambassador
|
||||
|
||||
CNCF Ambassador（CNCF 大使），人员名单详见 <https://www.cncf.io/people/ambassadors/>，笔者很荣幸作为第二位成为 CNCF Ambassador 的中国人。
|
||||
|
||||
## 如何成为 CNCF Ambassador
|
||||
|
||||
可以通过以下方式成为 CNCF Ambassador：
|
||||
|
||||
- 成为 CNCF 会员或对成为某个 CNCF 的项目的贡献者
|
||||
- 以 contributor、blogger、演讲者等身份参与 CNCF 社区项目
|
||||
- 在社区中演讲或撰写博客
|
||||
- 主持云原生社区 meetup
|
||||
|
||||
### 捷径
|
||||
|
||||
只要通过组织和举办推广 CNCF 推广的技术相关的活动即可，具体步骤如下：
|
||||
|
||||
1. 在 [meetup.com](https://www.meetup.com) 上创建一个 group（费用大概半年$42）
|
||||
1. 以策展人名义组织与 CNCF 提倡的云原生主题相关的 meetup
|
||||
1. 将活动加入到 CNCF group（<https://www.meetup.com/pro/cncf>）和为活动申请使用 CNCF logo（<https://github.com/cncf/meetups#how-to-apply>）
|
||||
1. 申请成为 CNCF Ambassador：<https://github.com/cncf/ambassadors> 附上自己最近三个月内举办的 meetup 链接（CNCF 只认 meetup.com 里的活动）
|
||||
|
||||
关于 CNCF meetup 的更多信息请访问：<https://github.com/cncf/meetups/>
|
||||
|
||||
## 成为 CNCF 大使有什么好处？
|
||||
|
||||
这是一个被经常问到的问题，毕竟全球各地的 CNCF 大使推广云原生技术，总得给他们一些甜头。以下是成为 CNCF 大使的好处：
|
||||
|
||||
- 组织社区聚会可以报销 $150/月
|
||||
- 可按年度申请 CNCF 项目的贴纸
|
||||
- CNCF 会议折扣
|
||||
- 免费参加 CNCF CKA/CKAD 考试
|
||||
- 一次在 [CNCF Store](https://store.cncf.io/) 免费购买纪念品的权利
|
||||
- 支持与当地发现演讲者的聚会和活动
|
||||
- 在云原生行业活动中演讲（差旅费用报销，需申请）
|
||||
- 发布博客的机会（CNCF 博客、Kubernetes 博客及其他业界知名平台）
|
||||
- 社交媒体推广支持
|
||||
|
||||
## 参考：
|
||||
|
||||
- <https://github.com/cncf/ambassadors>
|
||||
- <https://www.cncf.io/people/ambassadors/>
|
||||
|
|
@ -1,12 +1,12 @@
|
|||
# CNCF章程
|
||||
|
||||
CNCF（云原生计算基金会）是Linux基金会旗下的一个基金会，加入CNCF等于同时加入Linux基金会（也意味着你还要交Linux基金会的份子钱），对于想加入CNCF基金会的企业或者组织首先要做的事情就是要了解CNCF的章程（charter），就像是作为一个国家的公民，必须遵守该国家的宪法一样。CNCF之所以能在短短三年的时间内发展壮大到如此规模，很大程度上是与它出色的社区治理和运作模式有关。了解该章程可以帮助我们理解CNCF是如何运作的，也可以当我们自己进行开源项目治理时派上用场。
|
||||
CNCF（云原生计算基金会）是Linux基金会旗下的一个基金会，加入CNCF等于同时加入Linux基金会（也意味着你还要交Linux基金会的份子钱），对于想加入CNCF基金会的企业或者组织首先要做的事情就是要了解CNCF的章程（charter），就像是作为一个国家的公民，必须遵守该国家的宪法一样。CNCF之所以能在短短三年的时间内发展壮大到如此规模，很大程度上是与它出色的社区治理和运作模式有关。了解该章程可以帮助我们理解CNCF是如何运作的，当我们自己进行开源项目治理时也可以派上用场。
|
||||
|
||||
该章程最后更新于2018年5月15日，详见<https://www.cncf.io/about/charter/>。下文中关于CNCF章程的介绍部分引用自[CNCF 是如何工作的](http://www.ocselected.org/posts/foundation_introduce/how_cncf_works/)，有改动。
|
||||
|
||||
下图是我根据CNCF章程绘制的组织架构图。
|
||||
|
||||
|
||||
|
||||
|
||||
## 1. CNCF的使命
|
||||
|
||||
|
|
@ -42,8 +42,8 @@ d) 通过使技术可访问和可靠来为社区服务
|
|||
|
||||
CNCF 会极力遵循以下一些原则：
|
||||
|
||||
1. **快速胜过磨叽**，基金会的初衷之一就是让项目快速的发展，从而支持用户能够积极的使用。
|
||||
2. **开放！** CNCF 是以开放和高度透明为最高准则的，而且是独立于任何的其它团体进行运作的。CNCF根据贡献的内容和优点接受所有的贡献者，且遵循开源的价值观，CNCF输出的技术是可以让所有人使用和受益的，技术社区及其决策应保持高度透明。
|
||||
1. **快速胜过磨叽**：基金会的初衷之一就是让项目快速的发展，从而支持用户能够积极的使用。
|
||||
2. **开放！**：CNCF 是以开放和高度透明为最高准则的，而且是独立于任何的其它团体进行运作的。CNCF根据贡献的内容和优点接受所有的贡献者，且遵循开源的价值观，CNCF输出的技术是可以让所有人使用和受益的，技术社区及其决策应保持高度透明。
|
||||
3. **公平**：CNCF 会极力避免那些不好的影响、不良行为、以及“按需付费”的决策。
|
||||
4. **强大的技术身份**：CNCF 会实现并保持高度的自身技术认同，并将之同步到所有的共享项目中。
|
||||
5. **清晰的边界**：CNCF 制定明确的目标，并在某些情况下，要确定什么不是基金会的目标，并会帮助整个生态系统的运转，让人们理解新创新的重点所在。
|
||||
|
|
@ -54,13 +54,13 @@ CNCF 会极力遵循以下一些原则：
|
|||
|
||||
CNCF中的会员包括白金、金牌、银牌、最终用户、学术和非赢利成员等级别，不同级别的会员在理事会中的投票权不同。
|
||||
|
||||
a) **白金会员**：在CNCF理事会中任命1名代表，在理事会的每个次级委员会和活动中任命1名有投票权的代表，在网站可以突出显示；如果也是终端用户成员将继承终端用户成员的所有权利
|
||||
a) **白金会员**：在CNCF理事会中任命1名代表，在理事会的每个次级委员会和活动中任命1名有投票权的代表，在网站可以突出显示；如果也是终端用户成员将继承终端用户成员的所有权利。
|
||||
|
||||
b) **金牌会员**：基金会中每有5个金牌会员，该级别的会员就可以任命1名代表，最多任命3个；如果也是终端用户成员将继承终端用户成员的所有权利
|
||||
b) **金牌会员**：基金会中每有5个金牌会员，该级别的会员就可以任命1名代表，最多任命3个；如果也是终端用户成员将继承终端用户成员的所有权利。
|
||||
|
||||
c) **银牌会员**：基金会中每有10个银牌会员，该级别的会员就可以任命1名代表，最多任命3个；如果也是终端用户成员将继承终端用户成员的所有权利
|
||||
c) **银牌会员**：基金会中每有10个银牌会员，该级别的会员就可以任命1名代表，最多任命3个；如果也是终端用户成员将继承终端用户成员的所有权利。
|
||||
|
||||
d) **终端用户**：参加终端用户咨询社区；向终端用户技术咨询委员会中提名1名代表
|
||||
d) **终端用户**：参加终端用户咨询社区；向终端用户技术咨询委员会中提名1名代表。
|
||||
|
||||
e) **学术和非赢利会员**：学术和非营利会员分别限于学术和非营利机构，需要理事会批准。学术成员和非营利成员有权将其组织认定为支持CNCF使命的成员以及理事会确定的任何其他权利或利益。
|
||||
|
||||
|
|
@ -74,16 +74,16 @@ b) 负责日常事务
|
|||
2. 商标和版权保护
|
||||
3. 市场营销、布道和生态系统建设
|
||||
4. 创建和执行品牌承诺项目，如果需要的话
|
||||
5. 监督运营，业务发展；
|
||||
5. 监督运营，业务发展
|
||||
6. 募资和财务管理
|
||||
|
||||
c) 理事会投票成员由会员代表和社区代表组成：
|
||||
|
||||
1. 成员代表包括：
|
||||
- 每名白金会员任命1名代表
|
||||
- 黄金和银牌成员当选代表
|
||||
- 每名白金会员任命1名代表；
|
||||
- 黄金和银牌成员当选代表。
|
||||
2. 技术社区代表包括：
|
||||
- 技术监督委员会主席
|
||||
- 技术监督委员会主席；
|
||||
- 根据当时在任的理事会批准的程序从CNCF项目中选出两名提交者。
|
||||
3. 理事会可能会以白金会员比例的价格扩展白金会员资格，对年收入低于5000万美元的创业公司进行长达5年的逐年审计，这些公司被视为理事会的战略技术贡献者。
|
||||
4. 只有来自一组**关联公司**的人员可以担任会员代表。只有来自一组**关联公司**的人员可以担任技术社区代表。
|
||||
|
|
@ -117,7 +117,7 @@ CNCF 技术监督委员会，为了保持中立，则达成了以下共识：
|
|||
2. 批准由理事会制定的CNCF范围内的新项目，并为项目创建一个概念架构。
|
||||
3. 纠正项目的发展方向，决策删除或存档项目。
|
||||
4. 接受最终用户委员会的反馈并反映在项目中。
|
||||
5. 在科学管理的情况下调整组件的接口（在代码标准化之前实现参考）
|
||||
5. 在科学管理的情况下调整组件的接口（在代码标准化之前实现参考）。
|
||||
6. 定义在CNCF项目中实施的常用做法（如果有的话）。
|
||||
|
||||
### b) 技术监督委员会的构成
|
||||
|
|
@ -169,7 +169,7 @@ CNCF 技术监督委员会，为了保持中立，则达成了以下共识：
|
|||
|
||||
1. TOC 的成员任期为两年，来自理事会选举的最初六名当选TOC成员的任期为3年。由最终用户TAB和TOC选出的TOC成员的初始任期为2年。
|
||||
2. TOC成员可能会被其他TOC成员的三分之二投票撤除，受影响的个人不能参加投票。
|
||||
3. 任何TOC成员连续3次连续会议都将被自动暂停投票资格，直至连续参加两次会议。为避免疑义，暂停的TOC成员有资格在连续第二次会议中投票。
|
||||
3. 任何TOC成员连续3次缺席会议都将被自动暂停投票资格，直至连续参加两次会议。为避免疑义，暂停的TOC成员有资格在连续第二次会议中投票。
|
||||
4. TOC章程、模式、方法、组成等可以由整个理事会的三分之二票通过修改。
|
||||
5. TOC议程将由TOC制定。但是，预计最初的TOC讨论和决定将包括：
|
||||
- 评估包含在CNCF中的技术
|
||||
|
|
@ -233,7 +233,7 @@ i) 为促进与TOC的双边互动，最终用户技术咨询委员会应选出1
|
|||
|
||||
a) 项目或组件完全根据OSI批准的开源许可证进行授权，并且管理良好，并在CNCF中被用作组件。
|
||||
|
||||
b) 项目并没有由CNCF 来进行市场推广
|
||||
b) 项目并没有由CNCF来进行市场推广
|
||||
|
||||
c) 项目或组件的开发是由上游社区所开发，而且保持一定的活跃度
|
||||
|
||||
|
|
@ -253,7 +253,7 @@ c) 如果市场委员会变得太大而无法有效运作，市场委员会可
|
|||
|
||||
## 11. 知识产权政策
|
||||
|
||||
a) 任何加入到CNCF的项目都必须将其拥有的商标和徽标资产转让给Linux基金会的所有权。
|
||||
a) 任何加入到CNCF的项目都必须将其拥有的商标和徽标资产转的所有权让给Linux基金会。
|
||||
|
||||
b) 每个项目应确定是否需要使用经批准的CNCF CLA。对于选择使用CLA的项目，所有代码贡献者将承担Apache贡献者许可协议中规定的义务，只有在必要时才作出修改，以确定CNCF是捐赠的接受者，并且应由理事会批准。请参阅 <https://github.com/cncf/cla> 上提供的CNCF参与者许可协议。
|
||||
|
||||
|
|
@ -265,7 +265,7 @@ e) 所有评估纳入CNCF的项目都必须获得OSI批准的开源许可证的
|
|||
|
||||
f) 所有文档将由CNCF根据知识共享署名4.0国际许可证来提供。
|
||||
|
||||
g) 如果需要替代入站或出站许可证以符合杠杆式开放源代码项目的许可证或为实现CNCF的使命而需要其他许可证，理事会可以批准使用替代许可证 对于例外情况下的接受或提供的项目捐赠。
|
||||
g) 如果需要替代入站或出站许可证以符合杠杆式开放源代码项目的许可证或为实现CNCF的使命而需要其他许可证，理事会可以批准使用替代许可证对于例外情况下的接受或提供的项目捐赠。
|
||||
|
||||
## 12. 反托拉斯指南
|
||||
|
||||
|
|
@ -307,7 +307,7 @@ b) 一般和行政（G＆A）费用将用于筹集资金以支付财务、会计
|
|||
|
||||
## 17. 一般规则和操作
|
||||
|
||||
参与CNCF 应做到：
|
||||
参与 CNCF 应做到：
|
||||
|
||||
a) 展示与开源项目开发人员社区进行协调的计划和方法，包括关于代表社区的品牌、徽标和其它标志性的主题；
|
||||
|
||||
|
|
@ -319,7 +319,7 @@ d) 参与Linux基金会的所有新闻和分析师关系活动；
|
|||
|
||||
e) 根据要求，向Linux基金会提供关于项目参与的信息，包括参加项目赞助活动的信息；
|
||||
|
||||
f) 直接参与到基金会旗下的任何站点。
|
||||
f) 直接参与到基金会旗下的任何站点；
|
||||
|
||||
g) 根据理事会批准的规则和程序进行运营，前提是这些规则和程序不得与Linux基金会的宗旨和政策不一致，并且不得损害Linux基金会。
|
||||
|
||||
|
|
@ -345,7 +345,7 @@ CNCF社区坚信云原生计算包含三个核心属性：
|
|||
- 在标准化子系统的边界处定义良好的API
|
||||
- 应用程序生命周期管理的最小障碍
|
||||
|
||||
|
||||
|
||||
|
||||
因为上述时间表已经有些过时了，CNCF成立已经有三年时间了，正在规划新的方案。
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,102 @@
|
|||
## CNCF中的项目治理
|
||||
|
||||
CNCF 根据“[鸿沟理论](https://www.jianshu.com/p/a305fa93580b)”将其托管的项目分成三个成熟阶段，并设置了项目晋级到更高阶段的标准。
|
||||
|
||||
> “[鸿沟理论](https://www.jianshu.com/p/a305fa93580b)”是由Geoffrey A. Moore提出的高科技产品的市场营销理论。新技术要想跨越鸿沟，必须能够实现一些跨越式的发展，**拥有某一些以前不可能实现的功能**，具有某种内在价值并能够**赢得非技术人员的**青睐。
|
||||
|
||||
|
||||
|
||||
目前处于沙箱、孵化中、已毕业项目的数量比例为5：16：13，详见 <https://cncf.io/projects>。其中沙箱（sandbox）项目因为其处于早期阶段并没有直接在上面的链接页面中列出，而是一个单独的 [Sandbox](https://www.cncf.io/sandbox-projects/) 页面，因为 CNCF 为 sandbox 阶段的项目会谨慎背书。
|
||||
|
||||
## 纳入CNCF开源版图的项目需要符合其对云原生的定义
|
||||
|
||||
CNCF 中托管的开源项目要符合云原生定义：
|
||||
|
||||
- 云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。**云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API**。
|
||||
- 这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术使工程师能够轻松地对系统作出频繁和可预测的重大变更。
|
||||
- 云原生计算基金会（CNCF）致力于培育和维护一个厂商中立的开源生态系统，来推广云原生技术。我们通过将最前沿的模式民主化，让这些创新为大众所用。
|
||||
|
||||
## 项目运作流程
|
||||
|
||||
下图演示了开源项目加入 CNCF 后的整个运作流程。
|
||||
|
||||
|
||||
|
||||
## 开源项目如何加入 CNCF
|
||||
|
||||
1. 开源项目所支持的公司成为 CNCF 会员
|
||||
2. 开源项目满足 CNCF 的要求（见后文）
|
||||
3. 在 GitHub 上提交[proposal](https://github.com/cncf/toc/issues/113)（GitHub Issue）列举项目介绍、现状、目标、license、用户与社区等
|
||||
4. 由 Chris Aniszczyk 安排该项目在某个TOC双月会议上介绍给 TOC 成员
|
||||
5. 1.TOC 会将开源项目指定到某个 [SIG](cncf-sig.md) 中
|
||||
6. 项目获得两个TOC成员的赞成可进入[sandbox](https://github.com/cncf/toc/blob/master/process/sandbox.md)（也可以直接获得2/3多数TOC 投票进入Incubating状态）
|
||||
7. 知识产权转移给 CNCF
|
||||
8. CNCF 安排博客撰写、PR等
|
||||
9. 每年一次评审，晋升到 incubating需要2/3的 TOC 成员投票赞成；至少3家用户成功在生产上使用；通过TOC的尽职调查；贡献者数量健康稳定
|
||||
10. Sandbox 中的项目没有时效性质，可能永远都无法进入incubating 状态，被CNCF谨慎宣传
|
||||
|
||||
## CNCF 开源项目成熟度演进
|
||||
|
||||
CNCF 的开源项目遵循如下图所示的成熟度演进。
|
||||
|
||||
|
||||
|
||||
- 加入Sandbox只需要2个TOC成员赞成
|
||||
- 成熟一点的项目可以直接进入incubating阶段，但是 CNCF 会控制不同阶段的项目比例
|
||||
- 晋级到Incubating或Graduated 需要至少2/3的 TOC成员（6名或以上）投票赞成
|
||||
- 每年将评审一次
|
||||
|
||||
## 开源项目加入 CNCF 的最低要求（Sandbox）
|
||||
|
||||
一个开源项目要想加入 CNCF 必须满足以下要求：
|
||||
|
||||
- 项目名称必须在 CNCF 中唯一
|
||||
|
||||
- 项目描述（用途、价值、起源、历史）
|
||||
|
||||
- 与 CNCF 章程一致的声明
|
||||
|
||||
- 来自 TOC 的 sponsor（项目辅导）
|
||||
|
||||
- license（默认为 Apache 2）
|
||||
|
||||
- 源码控制（Github）
|
||||
|
||||
- 网站（英文）
|
||||
|
||||
- 外部依赖（包括 license）
|
||||
|
||||
- 成熟度模型评估（参考 [开源项目加入CNCF Sandbox的要求](cncf-sandbox-criteria.md)）
|
||||
- 创始 committer（贡献项目的时长）
|
||||
- 基础设施需求（CI/CNCF集群）
|
||||
- 沟通渠道（slack、irc、邮件列表）
|
||||
- issue 追踪（GitHub）
|
||||
- 发布方法和机制
|
||||
- 社交媒体账号
|
||||
- 社区规模和已有的赞助商
|
||||
- svg 格式的项目 logo
|
||||
|
||||
## 由 Sandbox 升级到 Incubating 的要求
|
||||
|
||||
- 通过 TOC 的[尽职调查](https://github.com/cncf/toc/blob/master/process/due-diligence-guidelines.md)
|
||||
- 至少有 3 个独立的终端用户在在生产上使用该项目：一般在项目的官网列举实际用户
|
||||
- 足够健康数量的贡献者：项目的 GitHub 上有明确的 committer 权限划分、职责说明及成员列表，TOC 将根据项目大小来确认多少committer才算健康
|
||||
- **展示项目在持续进行、良好的发布节奏、贡献频率十分重要**
|
||||
|
||||
|
||||
## 由Incubating升级到Graduated的要求
|
||||
|
||||
- 满足 Sandbox 和 Incubating 的所有要求
|
||||
- **至少有来自两个组织的贡献者**
|
||||
- 明确定义的项目治理及 committer 身份、权限管理
|
||||
- 接受 CNCF 的[行为准则](https://github.com/cncf/foundation/blob/master/code-of-conduct.md)，参考[Prometheus](https://bestpractices.coreinfrastructure.org/en/projects/486)
|
||||
- 获得CII 最佳实践徽章
|
||||
- 在项目主库或项目官网有公开的采用者的 logo
|
||||
|
||||
参考归档的 Review：https://github.com/cncf/toc/tree/master/reviews
|
||||
|
||||
## 参考
|
||||
|
||||
- [鸿沟理论 - jianshu.com](https://www.jianshu.com/p/a305fa93580b)
|
||||
- [CNCF Graduation Criteria v1.2 - github.com](https://github.com/cncf/toc/blob/master/process/graduation_criteria.adoc)
|
||||
|
||||
|
|
@ -0,0 +1,30 @@
|
|||
## 开源项目加入CNCF Sandbox的要求
|
||||
|
||||
[CNCF Project Proposal Process v1.2][CNCF Project Proposal Process v1.2]中指出开源项目要想加入 CNCF 必须满足以下条件：
|
||||
|
||||
1. 项目名称必须在 CNCF 中唯一
|
||||
2. 项目描述（用途、价值、起源、历史）
|
||||
3. 与 CNCF 章程一致的声明
|
||||
4. 来自 TOC 的 sponsor（项目辅导）
|
||||
5. 成熟度模型评估（参考 [CNCF Graduation Criteria](https://github.com/cncf/toc/blob/master/process/project_proposals.adoc)）
|
||||
6. license（默认为 Apache 2）
|
||||
7. 源码控制（Github）
|
||||
8. 外部依赖（包括 license）
|
||||
9. 创始 committer（贡献项目的时长）
|
||||
10. 基础设施需求（CI/CNCF集群）
|
||||
11. 沟通渠道（slack、irc、邮件列表）
|
||||
12. issue 追踪（GitHub）
|
||||
13. 网站
|
||||
14. 发布方法和机制
|
||||
15. 社交媒体账号
|
||||
16. 社区规模和已有的赞助商
|
||||
17. svg 格式的项目 logo
|
||||
|
||||
### 项目接纳过程
|
||||
|
||||
1. 在 TOC 会议上展示提议
|
||||
2. 项目获得 TOC 2/3 多数投票同意
|
||||
|
||||
## 参考
|
||||
|
||||
- [CNCF Project Proposal Process v1.2 - github.com](https://github.com/cncf/toc/blob/master/process/project_proposals.adoc)
|
||||
|
|
@ -0,0 +1,173 @@
|
|||
# CNCF特别兴趣小组（SIG）说明
|
||||
|
||||
本文译自 [CNCF Special Interest Groups（SIGs）](https://github.com/cncf/toc/blob/master/sigs/cncf-sigs.md)最终草案v1.0。
|
||||
|
||||
本提案创作于2018年11月至2019年1月期间，由CNCF TOC和”Contributors Primary Author“ Alexis Richardson，Quinton Hoole共同起草。
|
||||
|
||||
## 总体目的
|
||||
|
||||
为了我们的[使命](https://github.com/cncf/foundation/blob/master/charter.md#1-mission-of-the-cloud-native-computing-foundation)，在扩展CNCF技术版图、增加用户社区贡献的同时保持其完整性和提高贡献质量。
|
||||
|
||||
## 具体目标
|
||||
|
||||
- 加强项目生态系统建设以满足最终用户和项目贡献者的需求。
|
||||
- 识别CNCF项目组合中的鸿沟（gap），寻找并吸引项目填补这些鸿沟。
|
||||
- 教育和指导用户，为用户提供无偏见、有效且实用的信息。
|
||||
- 将注意力和资源集中在促进CNCF项目的成熟度上。
|
||||
- 明确项目、CNCF项目人员和社区志愿者之间的关系。
|
||||
- 吸引更多社区参与，创建有效的TOC贡献和认可的入口。
|
||||
- 在减少TOC在某些项目上工作量的同时保留选举机构的执行控制和音调完整性。
|
||||
- 避免在供应商之间建立政治平台。
|
||||
|
||||
## 介绍
|
||||
|
||||
CNCF SIG将监督和协调与最终用户和（或）项目需求的逻辑领域相关的利益。这些领域如安全性、测试、可观察性、存储、网络等。通常由一组CNCF项目来满足SIG监督的领域，也可能是多个项目共享的跨领域特征组（如安全性和可观察性）。 SIG是：
|
||||
|
||||
- 是一个长期存在的群体，向技术监督委员会报告
|
||||
- 主要由相关领域的公认专家领导，并得到其他贡献者的支持
|
||||
|
||||
CNCF SIG以Kubernetes SIG为模型，旨在最小化差异以避免混淆——[此处](https://docs.google.com/document/d/1oSGhx5Hw7Hs_qawYB46BvRSPh0ZvFoxvHx-NWaf5Nsc/edit?usp=sharing)描述了两者之间不可避免的差异。
|
||||
|
||||
## SIG的职责与权利
|
||||
|
||||
CNCF SIG在TOC的指导下，提供高质量的专业技术知识、无偏见的信息及其领域内的领导力。TOC作为知情方和高效的执行委员会，利用这一输入来选择和推广适当的CNCF项目与实践，并向最终用户和云原生社区传播高质量的信息。可以很明确的说，SIG对CNCF项目没有直接的权力。特别是，CNCF SIG的创建并没有改变现有已成功实施的[章程](https://github.com/cncf/foundation/blob/master/charter.md)目标，即“项目......轻松地受技术监督委员会管辖”。
|
||||
|
||||
SIG应努力向TOC提供易于理解和可投票的“提议（proposition）”，提议需要有明确的书面证据支持。这些提议可以是：“基于此[书面尽职调查](https://github.com/cncf/toc/blob/master/process/due-diligence-guidelines.md)“或”根据明确的目标和证据来批准这个landscape文件“。SIG提供给TOC的信息和建议必须高度准确和公正，这一点至关重要，这也是受整体上改进CNCF的目标所驱动，而不是使一个项目或公司受益于其他项目或公司。我们相信涨潮会抬升所有船只，这是我们的目标。
|
||||
|
||||
之所以这样设计是考虑到：
|
||||
|
||||
- TOC是仲裁者和撰写者，可能总是会干预和驳回提议。
|
||||
- SIG是受人尊敬的人才。
|
||||
|
||||
SIG可以选择组建有时间限制的集中式工作组来实现某些职责（例如，制作特定的教育白皮书或组合空白分析报告）。工作组应有明确记录的章程、时间表（通常最多几个季度）和一套可交付的成果。一旦时间表过去或成果交付，工作组就会解散重组。
|
||||
|
||||
### 特定SIG责任
|
||||
|
||||
#### 项目处理：
|
||||
|
||||
- 了解并记录该领域内项目的宏观（high-level）路线图，包括CNCF和非CNCF项目。确定项目前景中的差距。
|
||||
- 对于CNCF的项目，执行健康检查（health check）。
|
||||
- 发掘和展出对候选项目。
|
||||
- 帮助候选项目准备向TOC提交。
|
||||
- 每个CNCF项目将由TOC分配给一个合适的SIG。
|
||||
|
||||
#### 最终用户教育（输出）
|
||||
|
||||
- 提供最新、高质量、无偏见且易于使用的材料，帮助最终用户理解并有效采用SIG领域内的云原生技术和实践，例如：
|
||||
- 白皮书、演示文稿、视频或其他形式的培训、阐明术语、比较不同的方法，可用的项目或产品、常见或推荐的做法、趋势、说明性的成功和失败等。
|
||||
- 信息应尽可能基于研究和事实收集，而不是纯粹的营销或推测。
|
||||
|
||||
#### 最终用户输入收集（输入）
|
||||
|
||||
- 收集有用的最终用户输入和有关期望、痛点、主要用例等的反馈。
|
||||
- 将其编译成易于使用的报告和（或）演示文稿，以帮助项目进行功能设计、优先级排序、UX等。
|
||||
|
||||
#### 社区支持
|
||||
|
||||
- SIG是开放式组织，提供会议、会议议程和笔记，邮件列表以及其他公开通信。
|
||||
- SIG的邮件列表、SIG会议日历和其他通信文件将公开发布和维护。
|
||||
|
||||
#### 作为TOC的值得信赖的专家顾问
|
||||
|
||||
- 对新项目和毕业项目进行技术尽职调查，并就调查结果向TOC提出建议。
|
||||
- 参与或定期检查其所在领域的项目，并根据需要或应要求向TOC提供有关健康、状态和措施（如果有）的建议。
|
||||
|
||||
#### SIG章程：
|
||||
|
||||
- 每年正式审核，并由TOC批准。章程必须明确表达：
|
||||
- 哪些属于SIG的范围，哪些不属于；
|
||||
- 与其他CNCF SIG或其他相关团体交流，明确是否有重叠；
|
||||
- 如何运作和管理，具体是否以及如何偏离TOC提供的标准SIG操作指南。不鼓励偏离这些指导原则，除非有TOC批准的对这种分歧的良好且记录良好的原因。
|
||||
|
||||
请参阅[CNCF SIG的责任示例](https://docs.google.com/document/d/1L9dJl5aBFnN5KEf82J689FY0UtnUawnt9ooCq8SkO_w/edit?usp=sharing)。
|
||||
|
||||
## 运营模式
|
||||
|
||||
重要提示：每个SIG都由CNCF执行人员的指定成员提供支持，该成员负责与CNCF执行董事（Executive Director）的联络、SIG的沟通和绩效，并向理事会（Governing Board）和TOC提交季度和年度报告。
|
||||
|
||||
作为起点，我们受到CNCF OSS项目和K8S SIG的启发。这意味着最小的可行治理和基于社区的组织。
|
||||
|
||||
### SIG组建、领导和成员构成
|
||||
|
||||
1. SIG由TOC组建。初始SIG列在下面，并将根据需要随时间进行调整。如果社区成员认为需要增加额外的SIG，应该向TOC提出，并给出明确的理由，最好是由志愿者领导SIG。TOC希望拥有最小的可行SIG数量，并且所有SIG都是高效的（与具有大量相对无效的SIG的“SIG蔓延（SIG sprawl）”相反）。
|
||||
2. SIG有三名联席主席，他们是TOC贡献者，该领域的公认专家，并且有能力共同领导SIG以产生无偏见信息。
|
||||
3. SIG有一名TOC联络员，作为TOC的投票成员，在TOC或SIG主席认为有必要提交TOC时，作为额外的非执行主席。
|
||||
4. SIG拥有多名技术领导者，他们被公认为（1）SIG领域的专家，（2）SIG领域的项目负责人（3）展示了提供产生SIG所需的无偏见信息所需的平衡技术领导能力。采取独立主席和技术主管角色的原因主要是想将行政职能的责任与深层技术职能和相关的时间承诺和技能组合分开。在适当的情况下，个人可以同时担任两种角色（见下文）。
|
||||
5. 强烈鼓励SIG内部的思想和兴趣多样性。为此，TOC将主动阻止绝大多数技术主管来自单一公司、市场细分等的绝大多数（⅔或更多）主席。
|
||||
6. SIG成员是自己任命的，因此一些SIG工作由TOC贡献者和社区的志愿者完成。为了识别随着时间的推移对SIG做出持续和有价值贡献的成员，可以创建SIG定义和分配的角色（例如，抄写员、培训或文档协调员等）。 SIG应该记录这些角色和职责是什么，执行者是谁，并让SIG领导批准。
|
||||
|
||||
### SIG成员角色
|
||||
|
||||
#### 主席
|
||||
|
||||
- 每周/两周/每月轮转的三个活动席位。
|
||||
- 主要执行管理功能，包括收集和编制每周（双周）议程的主题、主持会议、确保发布高质量的会议记录，以及跟踪和解决后续行动。
|
||||
- 如果有人有时间和能力同时担任这两个角色，只要TOC和SIG成员满意，则可以由技术主管兼任。
|
||||
|
||||
#### 技术主管
|
||||
|
||||
- 领导SIG领域的项目。
|
||||
- 是否有时间和能力对项目进行深度技术探索。项目可能包括正式的CNCF项目或SIG所涵盖领域的其他项目。
|
||||
|
||||
#### 其他命名角色
|
||||
|
||||
- 由SIG命名和定义（例如抄写员、公关主管、文档/培训负责人等）
|
||||
- 由绝大多数主席批准。
|
||||
|
||||
#### 其他成员
|
||||
|
||||
- 自我任命
|
||||
- 可能没有明确的角色或职责，也没有正式分配的角色（见上文）。
|
||||
- 除了指定的角色外，不得为公众造成他们在SIG中拥有任何权限或正式职责的印象。
|
||||
|
||||
### 选举
|
||||
|
||||
- TOC提名主席
|
||||
- 在TOC的2/3多数票后，分配了主席
|
||||
- 任期2年但交错排列，使至少有一个席位能够保持连续性
|
||||
- TOC和主席提名技术主管
|
||||
- 技术主管需要获得TOC的2/3多数票和SIG主席的2/3多数票
|
||||
- 在获得TOC的2/3多数票通过后，SIG主席和技术主管可以被随时取消任命
|
||||
|
||||
### 治理
|
||||
|
||||
- 所有SIG都继承并遵循CNCF TOC操作原则。
|
||||
- SIG必须有一个记录在案的治理流程，鼓励社区参与和明确的指导方针，以避免有偏见的决策。
|
||||
- 注意：这里的目标是与CNCF项目的“最小可行”模型保持一致，并且只需要这样的治理，而不是任何过于繁琐的事情
|
||||
- 如果符合CNCF运营原则，他们可能会像OSS项目一样，随着时间的推移逐步实施一系列实践。
|
||||
- 与CNCF项目一样，所有例外和争议均由TOC和CNCF员工帮助处理
|
||||
|
||||
### 预算和资源
|
||||
|
||||
- 此时没有正式的系统预算，除了CNCF执行人员承诺提供指定人员作为联络点。
|
||||
- 正如CNCF项目可能需要通过CNCF提供的“帮助”，SIG可以通过[ServiceDesk](https://github.com/cncf/servicedesk)求人办事。
|
||||
|
||||
## 退休
|
||||
|
||||
- 在SIG无法建立履行职责和（或）定期向TOC报告的情况下，TOC将：
|
||||
- 考虑在3个月后解散（retire）SIG
|
||||
- 必须在6个月后解散SIG
|
||||
- TOC可以通过2/3多数票通过对SIG的“不信任（no confidence）”。 在这种情况下，TOC可以投票解散或重组SIG。
|
||||
|
||||
## 初始SIG
|
||||
|
||||
为了开始该过程，TOC提出以下SIG和分配给每个SIG的项目。显然，所有这些SIG都不会在一夜之间完全形成或立即开始运作，因此TOC本身将履行尚未形成的SIG的职责，直到SIG形成为止。 然而，我们可以立即指定TOC的一个投票成员作为每个SIG的联络员，并优先考虑SIG的组建顺序，立即从最紧迫的SIG开始。
|
||||
|
||||
| 命名（待定） | 领域 | 当前的CNCF项目 |
|
||||
| ------------------------------ | ------------------------------------------------------------ | ------------------------------------------------------------ |
|
||||
| Traffic | networking, service discovery, load balancing, service mesh, RPC, pubsub, etc. | Envoy, Linkerd, NATS, gRPC, CoreDNS, CNI |
|
||||
| Observability | monitoring, logging, tracing, profiling, etc. | Prometheus, OpenTracing, Fluentd, Jaeger, Cortex, OpenMetrics, |
|
||||
| Governance | security, authentication, authorization, auditing, policy enforcement, compliance, GDPR, cost management, etc | SPIFFE, SPIRE, Open Policy Agent, Notary, TUF, Falco, |
|
||||
| App Dev, Ops & Testing | PaaS, Serverless, Operators,... CI/CD, Conformance, Chaos Eng, Scalability and Reliability measurement etc. | Helm, CloudEvents, Telepresence, Buildpacks |
|
||||
| Core and Applied Architectures | orchestration, scheduling, container runtimes, sandboxing technologies, packaging and distribution, specialized architectures thereof (e.g. Edge, IoT, Big Data, AI/ML, etc). | Kubernetes, containerd, rkt, Harbor, Dragonfly, Virtual Kubelet |
|
||||
| Storage | Block, File and Object Stores, Databases, Key-Value stores etc. | TiKV, etcd, Vitess, Rook |
|
||||
|
||||
TOC和CNCF工作人员将一起起草一套上述初步章程，并征集/选举合适的席位。
|
||||
|
||||
## 附录A：工作示例 - CNCF治理SIG
|
||||
|
||||
请参阅[单独文档](https://docs.google.com/document/d/18ufx6TjPavfZubwrpyMwz6KkU-YA_aHaHmBBQkplnr0/edit?usp=sharing)。
|
||||
|
||||
## 参考
|
||||
|
||||
- [CNCF Special Interest Groups（SIGs）](https://github.com/cncf/toc/blob/master/sigs/cncf-sigs.md)
|
||||
|
|
@ -1,12 +1,12 @@
|
|||
# CNCF - 云原生计算基金会简介
|
||||
|
||||
CNCF，全称Cloud Native Computing Foundation（云原生计算基金会），口号是**坚持和整合开源技术来让编排容器作为微服务架构的一部分**，其作为致力于云原生应用推广和普及的一支重要力量，不论您是云原生应用的开发者、管理者还是研究人员都有必要了解。
|
||||
CNCF，全称Cloud Native Computing Foundation（云原生计算基金会），成立于 2015 年7月21日（[于美国波特兰OSCON 2015上宣布](https://www.cncf.io/announcement/2015/06/21/new-cloud-native-computing-foundation-to-drive-alignment-among-container-technologies/)），其最初的口号是**坚持和整合开源技术来让编排容器作为微服务架构的一部分**，其作为致力于云原生应用推广和普及的一支重要力量，不论您是云原生应用的开发者、管理者还是研究人员都有必要了解。
|
||||
|
||||
CNCF作为一个厂商中立的基金会，致力于Github上的快速成长的开源技术的推广，如Kubernetes、Prometheus、Envoy等，帮助开发人员更快更好的构建出色的产品。
|
||||
|
||||
下图是CNCF的全景图。
|
||||
|
||||
|
||||
|
||||
|
||||
该全景图不断更新中，原图请见：https://github.com/cncf/landscape
|
||||
|
||||
|
|
@ -54,7 +54,7 @@ TOC（Technical Oversight Committee）作为CNCF中的一个重要组织，它
|
|||
* 定义和维护技术视野
|
||||
* 审批新项目加入组织，为项目设定概念架构
|
||||
* 接受最终用户的反馈并映射到项目中
|
||||
* 调整组件见的访问接口，协调组件之间兼容性
|
||||
* 调整组件间的访问接口，协调组件之间兼容性
|
||||
|
||||
TOC成员通过选举产生，见[选举时间表](https://github.com/cncf/toc/blob/master/process/election-schedule.md)。
|
||||
|
||||
|
|
@ -66,3 +66,4 @@ TOC成员通过选举产生，见[选举时间表](https://github.com/cncf/toc/b
|
|||
* [https://www.cncf.io/about/charter/](https://www.cncf.io/about/charter/)
|
||||
* [https://github.com/cncf/landscape](https://github.com/cncf/landscape)
|
||||
* [https://github.com/cncf/toc](https://github.com/cncf/toc)
|
||||
* [AT&T, Box, Cisco, Cloud Foundry Foundation, CoreOS, Cycle Computing, Docker, eBay, Goldman Sachs, Google, Huawei, IBM, Intel, Joyent, Kismatic, Mesosphere, Red Hat, Switch SUPERNAP, Twitter, Univa, VMware and Weaveworks join new effort to build and maintain cloud native distributed systems - cncf.io](https://www.cncf.io/announcement/2015/06/21/new-cloud-native-computing-foundation-to-drive-alignment-among-container-technologies/)
|
||||
|
|
|
|||
|
|
@ -44,11 +44,11 @@
|
|||
|
||||
但就2017年为止，Kubernetes的主要使用场景也主要作为应用开发测试环境、CI/CD和运行Web应用这几个领域，如下图[TheNewStack](http://thenewstack.io)的Kubernetes生态状况调查报告所示。
|
||||
|
||||
|
||||
|
||||
|
||||
另外基于Kubernetes的构建PaaS平台和Serverless也处于爆发的准备的阶段，如下图中Gartner的报告中所示：
|
||||
|
||||
|
||||
|
||||
|
||||
当前各大公有云如Google GKE、微软Azure ACS、亚马逊EKS（2018年上线）、VMWare、Pivotal、腾讯云、阿里云等都提供了Kubernetes服务。
|
||||
|
||||
|
|
@ -84,7 +84,7 @@ CNCF（云原生计算基金会）给出了云原生应用的三大特征：
|
|||
|
||||
[CNCF](https://cncf.io)所托管的应用（目前已达12个），即朝着这个目标发展，其公布的[Cloud Native Landscape](https://github.com/cncf/landscape)，给出了云原生生态的参考体系。
|
||||
|
||||
|
||||
|
||||
|
||||
**使用Kubernetes构建云原生应用**
|
||||
|
||||
|
|
@ -181,7 +181,7 @@ Linker的部署十分简单，本身就是一个镜像，使用Kubernetes的[Dae
|
|||
|
||||
给开发者带来最大的配置和上线的灵活性，践行DevOps流程，改善研发效率，下图这样的情况将更少发生。
|
||||
|
||||
|
||||
|
||||
|
||||
我们知道Kubernetes中的所有应用的部署都是基于YAML文件的，这实际上就是一种**Infrastructure as code**，完全可以通过Git来管控基础设施和部署环境的变更。
|
||||
|
||||
|
|
@ -246,7 +246,7 @@ Spark现在已经非官方支持了基于Kubernetes的原生调度，其具有
|
|||
|
||||
下图是我们刚调研准备使用Kubernetes时候的调研方案选择。
|
||||
|
||||
|
||||
|
||||
|
||||
对于一个初次接触Kubernetes的人来说，看到这样一个庞大的架构选型时会望而生畏，但是Kubernetes的开源社区帮助了我们很多。
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
# Kubernetes与云原生应用概览
|
||||
|
||||
几个月前Mesos已经宣布支持Kubernetes，而在2017年10月份的DockerCon EU上，Docker公司宣布官方同时支持Swarm和Kubernetes容器编排，Kubernetes已然成为容器编排调度的标准。
|
||||
2017年9月，Mesos宣布支持Kubernetes，而在2017年10月份的DockerCon EU上，Docker公司宣布官方同时支持Swarm和Kubernetes容器编排，Kubernetes已然成为容器编排调度的标准。
|
||||
|
||||
作为全书的开头，首先从历史、生态和应用角度介绍一下Kubernetes与云原生应用，深入浅出，高屋建瓴，没有深入到具体细节，主要是为了给初次接触Kubernetes的小白扫盲，具体细节请参考链接。
|
||||
|
||||
|
|
@ -338,7 +338,7 @@ Kubernetes是一个多租户的云平台，因此必须对用户的权限加以
|
|||
|
||||
Service Mesh现在一般被翻译作服务网格，目前主流的Service Mesh有如下几款：
|
||||
|
||||
* [Istio](https://istio.io)：IBM、Google、Lyft共同开源，详细文档见[Istio官方中文文档](https://istio.io/zh/)
|
||||
* [Istio](https://istio.io)：IBM、Google、Lyft共同开源，详细文档见[Istio官方文档](https://istio.io)
|
||||
* [Linkerd](https://linkerd.io)：原Twitter工程师开发，现为[CNCF](https://cncf.io)中的项目之一
|
||||
* [Envoy](https://www.envoyproxy.io/)：Lyft开源的，可以在Istio中使用Sidecar模式运行
|
||||
* [Conduit](https://conduit.io)：同样由Buoyant开源的轻量级的基于Kubernetes的Service Mesh
|
||||
|
|
@ -387,7 +387,7 @@ Kubernetes作为云原生计算的基本组件之一，开源2年时间以来热
|
|||
|
||||
**使用Kibana查看日志**
|
||||
|
||||
日志字段中包括了应用的标签、容器名称、主机名称、宿主机名称、IP地址、时间、
|
||||
日志字段中包括了应用的标签、容器名称、主机名称、宿主机名称、IP地址、时间。
|
||||
|
||||
|
||||
|
||||
|
|
@ -476,4 +476,4 @@ Spark原生支持standalone、mesos和YARN资源调度，现已支持Kubernetes
|
|||
* [迁移到云原生应用架构指南](https://jimmysong.io/migrating-to-cloud-native-application-architectures)
|
||||
* [Cloud Native Go - 已由电子工业出版社出版](https://jimmysong.io/cloud-native-go)
|
||||
* [Cloud Native Python - 已由电子工业出版社出版](https://jimmysong.io/posts/cloud-native-python)
|
||||
* [Istio Service Mesh 中文文档](https://istio.io/zh/)
|
||||
* [Istio Service Mesh 中文文档 v1.2](https://archive.istio.io/v1.2/zh/)
|
||||
|
|
|
|||
|
|
@ -0,0 +1,61 @@
|
|||
# 使用Rancher在阿里云上部署Kubernetes集群
|
||||
|
||||
如果您已经购买了阿里云的 ECS，那么您可以使用 Rancher 很方便的构建起一套 Kubernetes 集群用于测试及小规模使用。使用 Rancher 可以自动和可视化的完成 Kubernetes 集群的安装工作，省去的繁琐的人工安装过程，然您快速投入的业务开发中。下文根据 Rancher 2.x 安装 Kubernetes 集群。
|
||||
|
||||
**注：阿里云上已支持[容器服务 ACK](https://cn.aliyun.com/product/kubernetes)，如果您需要高性能、企业级的 Kubernetes 服务不妨考虑一下。**
|
||||
|
||||
## 准备
|
||||
|
||||
要想使用阿里云 ECS 和 Rancher 直接搭建一套 Kubernetes 集群，需要准备以下条件：
|
||||
|
||||
- 开通了公网 IP 的 ECS
|
||||
- ECS 规格建议至少 4C8G
|
||||
- ECS 使用的阿里云的经典网络
|
||||
|
||||
### 安全组规则
|
||||
|
||||
组成 Kubenretes 集群的 ECS 位于阿里云经典网络中，需要为集群配置安全组规则如下：
|
||||
|
||||
- UDP/8472 端口：阿里云默认禁止了 UDP，我们使用的 flannel 网络插件的VXLAN 模式，需要将 ECS 的安全组设置 UDP/8472 端口开放
|
||||
- TCP/6443：Kubernetes API Server
|
||||
- TCP/2379：etcd
|
||||
- TCP/2380：etcd
|
||||
- TCP/80：http
|
||||
- TCP/443：https
|
||||
|
||||
## 步骤
|
||||
|
||||
假设现在我们有两个节点 master 和 node，请参考 [Rancher Quick Start Guide](https://rancher.com/docs/rancher/v2.x/en/quick-start-guide/deployment/quickstart-manual-setup/) 安装 Rancher。
|
||||
|
||||
|
||||
|
||||
**Master**
|
||||
|
||||
先在 Master 节点安装 Rancher server、control、etcd 和 worker。
|
||||
|
||||
选择网络组件为 Flannel，同时在自定义主机运行命令中选择主机角色、填写主机的内网和外网 IP。
|
||||
|
||||
|
||||
|
||||
```bash
|
||||
docker run -d --restart=unless-stopped -p 80:80 -p 443:443 rancher/rancher
|
||||
```
|
||||
|
||||
Rancher 将自动创建 Kubernetes 集群，并默认在 80 端口运行 web server。
|
||||
|
||||
**Node**
|
||||
|
||||
添加 Node 节点时只需要在 Rancher 的 web 界面上找到您刚安装的集群并选择【编辑集群】并选择节点角色为 Worker 即可增加一台 Kubenretes 集群节点。
|
||||
|
||||
## 集群交互
|
||||
|
||||
|
||||
|
||||
如果您习惯使用命令行与集群交互可以 Rancher 的 web 上找到集群首页上的 `Kubeconfig File` 下载按钮，将该文件中的内容保存到您自己电脑的 `~/.kube/config` 文件中。然后现在对应 Kubernetes 版本的 `kubectl` 命令并放到 `PATH` 路径下即可。
|
||||
|
||||
如果您没有在本地安装 `kubectl` 工具，也可以通过 Rancher 的集群页面上的 `Launch kubectl` 命令通过 web 来操作集群。
|
||||
|
||||
## 参考
|
||||
|
||||
- [Rancher - rancher.com](https://rancher.com/products/rancher/)
|
||||
- [阿里云容器服务 ACK - aliyun.com](https://cn.aliyun.com/product/kubernetes)
|
||||
|
|
@ -15,13 +15,13 @@
|
|||
|
||||
一句话解释什么是云原生应用：云原生应用就是为了在云上运行而开发的应用
|
||||
|
||||
|
||||
|
||||
|
||||
要运行这样的应用必须有一个操作系统，就像我们运行PC或手机应用一样，而Kubernetes就是一个这样的操作系统。
|
||||
|
||||
我们再来看下操作系统宝库哪些层次。
|
||||
|
||||
|
||||
|
||||
|
||||
- 硬件管理：可以管理CPU、内存、网络和存储
|
||||
- 设备接口、虚拟化工具、实用工具
|
||||
|
|
@ -30,7 +30,7 @@
|
|||
|
||||
下面是CNCF给出的云原生景观图。
|
||||
|
||||
|
||||
|
||||
|
||||
该图中包括云原生的各种层次的提供者和应用，通过该图可以组合出一些列的云原生平台。
|
||||
|
||||
|
|
@ -52,7 +52,7 @@ Kubernetes发展已经有3年多的时间了，它已经基本成为了容器编
|
|||
|
||||
这是KubeVirt的架构图。
|
||||
|
||||
|
||||
|
||||
|
||||
我们看到图中有两个是Kubernetes原生的组件，API server和kubelet，我们创建了virt-controller就是为了创建CRD的controller，它扩展了kube-controller的功能，用于管理虚拟机的生命周期，同时在每个节点上都用DaemonSet的方式运行一个virt-handler，这个handler是用于创建虚拟机的处理器，每个节点上即可用运行虚拟机也可以运行容器，只要这个节点上有virt-handler就可以运行和调度虚拟机。
|
||||
|
||||
|
|
@ -64,7 +64,7 @@ Kubernetes的资源隔离也能保证对集群资源的最大化和最优利用
|
|||
|
||||
下图中展示了Kubernetes中的资源隔离层次。
|
||||
|
||||
|
||||
|
||||
|
||||
- 容器
|
||||
- Pod：命名空间的隔离，共享网络，每个Pod都有独立IP，使用Service Account为Pod赋予账户
|
||||
|
|
@ -80,13 +80,13 @@ Kubernetes中的基本资源类型分成了三类：
|
|||
|
||||
在最近一届的KubeCon & CloudNativeCon上Operator已经变得越来越流行。下面是OpenEBS的一个使用Operator的例子。
|
||||
|
||||
|
||||
|
||||
|
||||
OpenEBS是一款容器化存储，它基于Ceph构建，容器化存储最大的好处就是复用Kubernetes的资源类型，简化存储应用的部署，将单体的存储拆分为“微服务化”的存储，即每个应用在声明PV的时候才会创建存储，并与PV的生命周期一样都是独立于应用的。
|
||||
|
||||
OpenEBS的存储也是分控制平面和数据平面的，下图是OpenEBS的架构图。
|
||||
|
||||
|
||||
|
||||
|
||||
黄色部分是OpenEBS的组件（除了kube-dashboard），它是使用Kubernetes的各种原语和CRD来创建的，架构跟Kubernetes本身也很类似。
|
||||
|
||||
|
|
@ -94,13 +94,13 @@ OpenEBS的存储也是分控制平面和数据平面的，下图是OpenEBS的架
|
|||
|
||||
上面说到了Operator的一个应用，下面再来看一个我们之前在Kubernetes中部署Hadoop YARN和Spark的例子。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Kubernetes始于12因素应用的PaaS平台，它是微服务的绝佳部署管理平台，基于它可以应用多种设计模式。它的未来将变成什么样呢？
|
||||
|
||||
|
||||
|
||||
|
||||
- Service Mesh：解决微服务治理问题
|
||||
- Auto Pilot：自动驾驭能力，服务自动扩展，智能运维
|
||||
|
|
@ -114,7 +114,7 @@ Kubernetes始于12因素应用的PaaS平台，它是微服务的绝佳部署管
|
|||
|
||||
甚至出现了像ballerina这样的云原生编程语言，它的出现就是为了解决应用开发到服务集成之间的鸿沟的。它有以下几个特点。
|
||||
|
||||
|
||||
|
||||
|
||||
- 使用云原生语义的DSL
|
||||
- 注解式配置
|
||||
|
|
@ -123,13 +123,13 @@ Kubernetes始于12因素应用的PaaS平台，它是微服务的绝佳部署管
|
|||
|
||||
要完成云的集成CI/CD，或者用一个词代替来说就是GitOps的需求越来越强烈。
|
||||
|
||||
|
||||
|
||||
|
||||
### Kubernetes没有做什么
|
||||
|
||||
看下这张图中的两个服务，它们使用的是kube-proxy里基于iptables的原生的负载均衡，并且服务间的流量也没有任何控制。
|
||||
|
||||
|
||||
|
||||
|
||||
Kubernetes缺少的最重要的一个功能就是微服务的治理，微服务比起单体服务来说使得部署和运维起来更加复杂，对于微服务的可观测性也有更高的要求，同时CI/CD流程Kubernetes本身也没有提供。
|
||||
|
||||
|
|
@ -141,7 +141,7 @@ Service Mesh是一个专用的基础设施层，它能够将微服务的治理
|
|||
|
||||
这是Istio Service Mesh的架构图。
|
||||
|
||||
|
||||
|
||||
|
||||
- Pilot：提供用户接口，用户可以通过该接口配置各种路由规则，Pilot还可以通过适配器获取平台上各种服务之间的管理，Evnoy这个使用Sidecar方式部署到每个应用pod中的进程会通过Pilot中的Envoy API获得平台上各个服务之间的管理，同时也会应用用户配置的路由规则。
|
||||
- Mixer：获取各种平台属性，服务间通讯时会先访问Mixer兼容各平台的属性信息，如quota、访问控制和策略评估，将服务间的访问信息记录后上报到mixer形成遥测报告。
|
||||
|
|
@ -149,7 +149,7 @@ Service Mesh是一个专用的基础设施层，它能够将微服务的治理
|
|||
|
||||
Service Mesh实际上为了解决社会分工问题，它本身是为了解决微服务的治理。
|
||||
|
||||
|
||||
|
||||
|
||||
Pilot和控制平面是为了运维人员准备的。
|
||||
|
||||
|
|
@ -157,7 +157,7 @@ Pilot和控制平面是为了运维人员准备的。
|
|||
|
||||
Isito在每个上下游服务之间部署一个Envoy，Envoy中有几个基本的服务发现服务，监听器即Envoy要转发的流量端口，Endpoint是要转发的目的地，Cluster是一系列Endpoint用来做负载均衡，Route是定义各种路由规则，每个Envoy进程里可以设置多个Listener。
|
||||
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
|
|
|
|||
|
|
@ -126,9 +126,3 @@ storage.k8s.io/v1
|
|||
storage.k8s.io/v1beta1
|
||||
v1
|
||||
```
|
||||
|
||||
## 参考
|
||||
|
||||
[API Conventions](https://github.com/kubernetes/community/blob/master/contributors/devel/api-conventions.md#resources)
|
||||
|
||||
[Kuberentes1.8 reference doc](https://kubernetes.io/docs/api-reference/v1.8/#apiservicespec-v1beta1-apiregistration)
|
||||
|
|
|
|||
|
|
@ -1,17 +1,22 @@
|
|||
# Kubernetes中的网络解析——以calico为例
|
||||
|
||||
[Calico](https://www.projectcalico.org/) 原意为”有斑点的“，如果说一只猫为 calico cat 的话，就是说这是只花猫，也叫三色猫，所以 calico 的 logo 是只三色猫。
|
||||
|
||||
|
||||
|
||||
## 概念
|
||||
|
||||
Calico 创建和管理一个扁平的三层网络(不需要overlay)，每个容器会分配一个可路由的ip。由于通信时不需要解包和封包，网络性能损耗小，易于排查，且易于水平扩展。
|
||||
Calico创建和管理一个扁平的三层网络（不需要overlay），每个容器会分配一个可路由的IP。由于通信时不需要解包和封包，网络性能损耗小，易于排查，且易于水平扩展。
|
||||
|
||||
小规模部署时可以通过bgp client直接互联，大规模下可通过指定的BGP route reflector来完成，这样保证所有的数据流量都是通过IP路由的方式完成互联的。
|
||||
Calico基于iptables还提供了丰富而灵活的网络Policy，保证通过各个节点上的ACLs来提供Workload的多租户隔离、安全组以及其他可达性限制等功能。
|
||||
小规模部署时可以通过BGP client直接互联，大规模下可通过指定的BGP Route Reflector来完成，这样保证所有的数据流量都是通过IP路由的方式完成互联的。
|
||||
|
||||
Calico基于iptables还提供了丰富而灵活的网络Policy，保证通过各个节点上的ACL来提供Workload的多租户隔离、安全组以及其他可达性限制等功能。
|
||||
|
||||
## Calico架构
|
||||
|
||||
|
||||
|
||||
calico主要由Felix,etcd,BGP client,BGP Route Reflector组成。
|
||||
Calico主要由Felix、etcd、BGP client、BGP Route Reflector组成。
|
||||
|
||||
- [Etcd](https://docs.projectcalico.org/v3.0/reference/architecture/)：负责存储网络信息
|
||||
- [BGP client](https://docs.projectcalico.org/v3.0/reference/architecture/)：负责将Felix配置的路由信息分发到其他节点
|
||||
|
|
@ -20,14 +25,16 @@ calico主要由Felix,etcd,BGP client,BGP Route Reflector组成。
|
|||
|
||||
## 部署
|
||||
|
||||
```
|
||||
运行下面的命令可以部署 calico 网络。
|
||||
|
||||
```bash
|
||||
mkdir /etc/cni/net.d/
|
||||
|
||||
kubectl apply -f https://docs.projectcalico.org/v3.0/getting-started/kubernetes/installation/rbac.yaml
|
||||
|
||||
wget https://docs.projectcalico.org/v3.0/getting-started/kubernetes/installation/hosted/calico.yaml
|
||||
|
||||
修改etcd_endpoints的值和默认的192.168.0.0/16(不能和已有网段冲突)
|
||||
# 修改etcd_endpoints的值和默认的192.168.0.0/16(不能和已有网段冲突)
|
||||
|
||||
kubectl apply -f calico.yaml
|
||||
|
||||
|
|
@ -40,6 +47,10 @@ calicoctl get ippool
|
|||
calicoctl get node
|
||||
```
|
||||
|
||||
- [部署](https://docs.projectcalico.org/v3.0/usage/calicoctl/install)
|
||||
- [calicoctl命令](https://docs.projectcalico.org/v3.0/reference/calicoctl/commands/)
|
||||
- [架构](https://docs.projectcalico.org/v3.0/reference/architecture/)
|
||||
如果安装时启用应用层策略的话还需要安装 [istio](https://istio.io)，详见 [Enabling application layer policy](https://docs.projectcalico.org/v3.4/getting-started/kubernetes/installation/app-layer-policy#about-enabling-application-layer-policy)。
|
||||
|
||||
## 参考
|
||||
|
||||
- [安装Calico - docs.projectcalico.org](https://docs.projectcalico.org/v3.4/usage/calicoctl/install)
|
||||
- [calicoctl命令参考 - docs.projectcalico.org](https://docs.projectcalico.org/v3.4/reference/calicoctl/commands/)
|
||||
- [Calico架构 - docs.projectcalico.org](https://docs.projectcalico.org/v3.4/reference/architecture/)
|
||||
|
|
|
|||
|
|
@ -14,7 +14,7 @@ KV 存储数据库用存储以下状态：
|
|||
|
||||
下图是 Cilium 的组件示意图，Cilium 是位于 Linux kernel 与容器编排系统的中间层。向上可以为容器配置网络，向下可以向 Linux 内核生成 BPF 程序来控制容器的安全性和转发行为。
|
||||
|
||||
|
||||
|
||||
|
||||
管理员通过 Cilium CLI 配置策略信息，这些策略信息将存储在 KV 数据库里，Cilium 使用插件（如 CNI）与容器编排调度系统交互，来实现容器间的联网和容器分配 IP 地址分配，同时 Cilium 还可以获得容器的各种元数据和流量信息，提供监控 API。
|
||||
|
||||
|
|
@ -109,7 +109,7 @@ Available Commands:
|
|||
|
||||
将该配置保存成 JSON 文件，在使用 `cilium policy import` 命令即可应用到 Cilium 网络中。
|
||||
|
||||
|
||||
|
||||
|
||||
如图所示，此时 `id` 标签为其他值的容器就无法访问 `id=app1` 容器，策略配置中的 `toPorts` 中还可以配置 HTTP `method` 和 `path`，实现更细粒度的访问策略控制，详见 [Cilium 官方文档](https://cilium.readthedocs.io/en/stable/gettingstarted/docker/)。
|
||||
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ Cilium是一个纯开源软件，没有哪家公司提供商业化支持，也
|
|||
|
||||
Cilium的基础是一种名为BPF的新Linux内核技术，它可以在Linux本身动态插入强大的安全可见性和控制逻辑。由于BPF在Linux内核中运行，因此可以应用和更新Cilium安全策略，而无需对应用程序代码或容器配置进行任何更改。
|
||||
|
||||
|
||||
|
||||
|
||||
基于微服务的应用程序分为小型独立服务，这些服务使用**HTTP**、**gRPC**、**Kafka**等轻量级协议通过API相互通信。但是，现有的Linux网络安全机制（例如iptables）仅在网络和传输层（即IP地址和端口）上运行，并且缺乏对微服务层的可见性。
|
||||
|
||||
|
|
|
|||
|
|
@ -1,5 +1,7 @@
|
|||
# Kubernetes的设计理念
|
||||
|
||||
这一章将介绍 Kubernetes 的设计理念及基本概念。
|
||||
|
||||
### Kubernetes设计理念与分布式系统
|
||||
|
||||
分析和理解Kubernetes的设计理念可以使我们更深入地了解Kubernetes系统，更好地利用它管理分布式部署的云原生应用，另一方面也可以让我们借鉴其在分布式系统设计方面的经验。
|
||||
|
|
@ -8,7 +10,7 @@
|
|||
|
||||
Kubernetes设计理念和功能其实就是一个类似Linux的分层架构，如下图所示
|
||||
|
||||
|
||||
|
||||
|
||||
* 核心层：Kubernetes最核心的功能，对外提供API构建高层的应用，对内提供插件式应用执行环境
|
||||
* 应用层：部署（无状态应用、有状态应用、批处理任务、集群应用等）和路由（服务发现、DNS解析等）
|
||||
|
|
@ -52,7 +54,7 @@ Kubernetes中所有的配置都是通过API对象的spec去设置的，也就是
|
|||
|
||||
Kubernetes有很多技术概念，同时对应很多API对象，最重要的也是最基础的是Pod。Pod是在Kubernetes集群中运行部署应用或服务的最小单元，它是可以支持多容器的。Pod的设计理念是支持多个容器在一个Pod中共享网络地址和文件系统，可以通过进程间通信和文件共享这种简单高效的方式组合完成服务。Pod对多容器的支持是K8最基础的设计理念。比如你运行一个操作系统发行版的软件仓库，一个Nginx容器用来发布软件，另一个容器专门用来从源仓库做同步，这两个容器的镜像不太可能是一个团队开发的，但是他们一块儿工作才能提供一个微服务；这种情况下，不同的团队各自开发构建自己的容器镜像，在部署的时候组合成一个微服务对外提供服务。
|
||||
|
||||
Pod是Kubernetes集群中所有业务类型的基础，可以看作运行在K8集群中的小机器人，不同类型的业务就需要不同类型的小机器人去执行。目前Kubernetes中的业务主要可以分为长期伺服型（long-running）、批处理型（batch）、节点后台支撑型（node-daemon）和有状态应用型（stateful application）；分别对应的小机器人控制器为Deployment、Job、DaemonSet和StatefulSet，本文后面会一一介绍。
|
||||
Pod是Kubernetes集群中所有业务类型的基础，可以看作运行在Kubernetes集群中的小机器人，不同类型的业务就需要不同类型的小机器人去执行。目前Kubernetes中的业务主要可以分为长期伺服型（long-running）、批处理型（batch）、节点后台支撑型（node-daemon）和有状态应用型（stateful application）；分别对应的小机器人控制器为Deployment、Job、DaemonSet和StatefulSet，本文后面会一一介绍。
|
||||
|
||||
### 副本控制器（Replication Controller，RC）
|
||||
|
||||
|
|
@ -80,7 +82,7 @@ Job是Kubernetes用来控制批处理型任务的API对象。批处理业务与
|
|||
|
||||
### 有状态服务集（StatefulSet）
|
||||
|
||||
Kubernetes在1.3版本里发布了Alpha版的PetSet功能，在1.5版本里将PetSet功能升级到了Beta版本，并重新命名为StatefulSet，最终在1.9版本里成为正式GA版本。在云原生应用的体系里，有下面两组近义词；第一组是无状态（stateless）、牲畜（cattle）、无名（nameless）、可丢弃（disposable）；第二组是有状态（stateful）、宠物（pet）、有名（having name）、不可丢弃（non-disposable）。RC和RS主要是控制提供无状态服务的，其所控制的Pod的名字是随机设置的，一个Pod出故障了就被丢弃掉，在另一个地方重启一个新的Pod，名字变了、名字和启动在哪儿都不重要，重要的只是Pod总数；而StatefulSet是用来控制有状态服务，StatefulSet中的每个Pod的名字都是事先确定的，不能更改。StatefulSet中Pod的名字的作用，并不是《千与千寻》的人性原因，而是关联与该Pod对应的状态。
|
||||
Kubernetes在1.3版本里发布了Alpha版的PetSet功能，在1.5版本里将PetSet功能升级到了Beta版本，并重新命名为StatefulSet，最终在1.9版本里成为正式GA版本。在云原生应用的体系里，有下面两组近义词；第一组是无状态（stateless）、牲畜（cattle）、无名（nameless）、可丢弃（disposable）；第二组是有状态（stateful）、宠物（pet）、有名（having name）、不可丢弃（non-disposable）。RC和RS主要是控制提供无状态服务的，其所控制的Pod的名字是随机设置的，一个Pod出故障了就被丢弃掉，在另一个地方重启一个新的Pod，名字变了。名字和启动在哪儿都不重要，重要的只是Pod总数；而StatefulSet是用来控制有状态服务，StatefulSet中的每个Pod的名字都是事先确定的，不能更改。StatefulSet中Pod的名字的作用，并不是《千与千寻》的人性原因，而是关联与该Pod对应的状态。
|
||||
|
||||
对于RC和RS中的Pod，一般不挂载存储或者挂载共享存储，保存的是所有Pod共享的状态，Pod像牲畜一样没有分别（这似乎也确实意味着失去了人性特征）；对于StatefulSet中的Pod，每个Pod挂载自己独立的存储，如果一个Pod出现故障，从其他节点启动一个同样名字的Pod，要挂载上原来Pod的存储继续以它的状态提供服务。
|
||||
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@
|
|||
|
||||
## ConfigMap概览
|
||||
|
||||
**ConfigMap API**资源用来保存**key-value pair**配置数据，这个数据可以在**pods**里使用，或者被用来为像**controller**一样的系统组件存储配置数据。虽然ConfigMap跟[Secrets](https://kubernetes.io/docs/user-guide/secrets/)类似，但是ConfigMap更方便的处理不含敏感信息的字符串。 注意：ConfigMaps不是属性配置文件的替代品。ConfigMaps只是作为多个properties文件的引用。你可以把它理解为Linux系统中的`/etc`目录，专门用来存储配置文件的目录。下面举个例子，使用ConfigMap配置来创建Kuberntes Volumes，ConfigMap中的每个data项都会成为一个新文件。
|
||||
**ConfigMap API**资源用来保存**key-value pair**配置数据，这个数据可以在**pods**里使用，或者被用来为像**controller**一样的系统组件存储配置数据。虽然ConfigMap跟[Secrets](https://kubernetes.io/docs/user-guide/secrets/)类似，但是ConfigMap更方便的处理不含敏感信息的字符串。 注意：ConfigMaps不是属性配置文件的替代品。ConfigMaps只是作为多个properties文件的引用。你可以把它理解为Linux系统中的`/etc`目录，专门用来存储配置文件的目录。下面举个例子，使用ConfigMap配置来创建Kubernetes Volumes，ConfigMap中的每个data项都会成为一个新文件。
|
||||
|
||||
```yaml
|
||||
kind: ConfigMap
|
||||
|
|
@ -54,7 +54,7 @@ kubectl create configmap
|
|||
|
||||
### 使用目录创建
|
||||
|
||||
比如我们已经有个了包含一些配置文件，其中包含了我们想要设置的ConfigMap的值：
|
||||
比如我们已经有了一些配置文件，其中包含了我们想要设置的ConfigMap的值：
|
||||
|
||||
```bash
|
||||
$ ls docs/user-guide/configmap/kubectl/
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
|
||||
本文是如何创建 CRD 来扩展 Kubernetes API 的教程。CRD 是用来扩展 Kubernetes 最常用的方式，在 Service Mesh 和 Operator 中也被大量使用。因此读者如果想在 Kubernetes 上做扩展和开发的话，是十分有必要了解 CRD 的。
|
||||
|
||||
在阅读本文前您需要先了解[使用自定义资源扩展 API](custom-resource.md)， 以下内容译自 [Kubernetes 官方文档](https://kubernetes.io/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/)，有删改，
|
||||
在阅读本文前您需要先了解[使用自定义资源扩展 API](custom-resource.md)， 以下内容译自 [Kubernetes 官方文档](https://kubernetes.io/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/)，有删改，推荐阅读[如何从零开始编写一个 Kubernetes CRD](https://www.servicemesher.com/blog/kubernetes-crd-quick-start/)。
|
||||
|
||||
## 创建 CRD（CustomResourceDefinition）
|
||||
|
||||
|
|
@ -11,7 +11,7 @@
|
|||
参考下面的 CRD，将其配置保存在 `resourcedefinition.yaml` 文件中：
|
||||
|
||||
```yaml
|
||||
apiVersion: apiextensions.k8s.io/v1beta1
|
||||
apiVersion: apiextensions.k8s.io/v1
|
||||
kind: CustomResourceDefinition
|
||||
metadata:
|
||||
# 名称必须符合下面的格式：<plural>.<group>
|
||||
|
|
@ -20,7 +20,25 @@ spec:
|
|||
# REST API使用的组名称：/apis/<group>/<version>
|
||||
group: stable.example.com
|
||||
# REST API使用的版本号：/apis/<group>/<version>
|
||||
version: v1
|
||||
versions:
|
||||
- name: v1
|
||||
# 可以通过 served 来开关每个 version
|
||||
served: true
|
||||
# 有且仅有一个 version 开启存储
|
||||
storage: true
|
||||
schema:
|
||||
openAPIV3Schema:
|
||||
type: object
|
||||
properties:
|
||||
spec:
|
||||
type: object
|
||||
properties:
|
||||
cronSpec:
|
||||
type: string
|
||||
image:
|
||||
type: string
|
||||
replicas:
|
||||
type: integer
|
||||
# Namespaced或Cluster
|
||||
scope: Namespaced
|
||||
names:
|
||||
|
|
@ -35,6 +53,8 @@ spec:
|
|||
- ct
|
||||
```
|
||||
|
||||
> 此处使用的 apiVersion 版本是 `apiextensions.k8s.io/v1`，跟上一版 `apiextensions.k8s.io/v1beta1` 的最主要区别是改用了 [OpenAPI v3.0 validation schema](https://kubernetes.io/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#validation)。
|
||||
|
||||
创建该 CRD：
|
||||
|
||||
```bash
|
||||
|
|
@ -55,7 +75,7 @@ kubectl create -f resourcedefinition.yaml
|
|||
|
||||
创建 CustomResourceDefinition 对象后，您可以创建自定义对象。自定义对象可包含自定义字段。这些字段可以包含任意 JSON。在以下示例中， `cronSpec` 和 `image` 自定义字段在自定义对象中设置 `CronTab`。`CronTab` 类型来自您在上面创建的 CustomResourceDefinition 对象的规范。
|
||||
|
||||
如果您将以下 YAML 保存到`my-crontab.yaml`：
|
||||
如果您将以下 YAML 保存到 `my-crontab.yaml`：
|
||||
|
||||
```yaml
|
||||
apiVersion: "stable.example.com/v1"
|
||||
|
|
@ -286,7 +306,7 @@ crontab "my-new-cron-object" created
|
|||
|
||||
从 Kubernetes 1.11 开始，kubectl 使用服务器端打印。服务器决定 `kubectl get` 命令显示哪些列。您可以使用 CustomResourceDefinition 自定义这些列。下面的示例将输出 `Spec`、`Replicas` 和 `Age` 列。
|
||||
|
||||
1. 将 CustomResourceDefinition保存到 `resourcedefinition.yaml`。
|
||||
1. 将 CustomResourceDefinition 保存到 `resourcedefinition.yaml`。
|
||||
|
||||
```yaml
|
||||
apiVersion: apiextensions.k8s.io/v1beta1
|
||||
|
|
@ -596,4 +616,5 @@ crontabs/my-new-cron-object 3s
|
|||
|
||||
## 参考
|
||||
|
||||
- [Extend the Kubernetes API with CustomResourceDefinitions - kubernetes.io](Extend the Kubernetes API with CustomResourceDefinitions)
|
||||
- [Extend the Kubernetes API with CustomResourceDefinitions - kubernetes.io](https://kubernetes.io/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/)
|
||||
- [如何从零开始编写一个Kubernetes CRD - servicemesher.com](https://www.servicemesher.com/blog/kubernetes-crd-quick-start/)
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
# CRI - Container Runtime Interface（容器运行时接口）
|
||||
|
||||
CRI中定义了**容器**和**镜像**的服务的接口，因为容器运行时与镜像的生命周期是彼此隔离的，因此需要定义两个服务。该接口使用[Protocol Buffer](https://developers.google.com/protocol-buffers/)，基于[gRPC](https://grpc.io/)，在Kubernetes v1.10+版本中是在[pkg/kubelet/apis/cri/runtime/v1alpha2](https://github.com/kubernetes/kubernetes/tree/master/pkg/kubelet/apis/cri/runtime/v1alpha2)的`api.proto`中定义的。
|
||||
CRI中定义了**容器**和**镜像**的服务的接口，因为容器运行时与镜像的生命周期是彼此隔离的，因此需要定义两个服务。该接口使用[Protocol Buffer](https://developers.google.com/protocol-buffers/)，基于[gRPC](https://grpc.io/)，在Kubernetes v1.10+版本中是在`pkg/kubelet/apis/cri/runtime/v1alpha2`的`api.proto`中定义的。
|
||||
|
||||
## CRI架构
|
||||
|
||||
|
|
@ -14,8 +14,6 @@ Container Runtime实现了CRI gRPC Server，包括`RuntimeService`和`ImageServi
|
|||
|
||||
要想启用CRI只需要在kubelet的启动参数重传入此参数：`--container-runtime-endpoint`远程运行时服务的端点。当前Linux上支持unix socket，windows上支持tcp。例如：`unix:///var/run/dockershim.sock`、 `tcp://localhost:373`，默认是`unix:///var/run/dockershim.sock`，即默认使用本地的docker作为容器运行时。
|
||||
|
||||
关于CRI的详细进展请参考[CRI: the Container Runtime Interface](https://github.com/kubernetes/community/blob/master/contributors/devel/container-runtime-interface.md)。
|
||||
|
||||
## CRI接口
|
||||
|
||||
Kubernetes 1.9中的CRI接口在`api.proto`中的定义如下：
|
||||
|
|
@ -124,7 +122,7 @@ service ImageService {
|
|||
|
||||
- [cri-o](https://github.com/kubernetes-incubator/cri-o)：cri-o是Kubernetes的CRI标准的实现，并且允许Kubernetes间接使用OCI兼容的容器运行时，可以把cri-o看成Kubernetes使用OCI兼容的容器运行时的中间层。
|
||||
- [cri-containerd](https://github.com/containerd/cri-containerd)：基于[Containerd](https://github.com/containerd/containerd)的Kubernetes CRI 实现
|
||||
- [rkt](https://coreos.com/rkt/)：由于CoreOS主推的用来跟docker抗衡的容器运行时
|
||||
- [rkt](https://coreos.com/rkt/)：由CoreOS主推的用来跟docker抗衡的容器运行时
|
||||
- [frakti](https://github.com/kubernetes/frakti)：基于hypervisor的CRI
|
||||
- [docker](https://www.docker.com)：kuberentes最初就开始支持的容器运行时，目前还没完全从kubelet中解耦，docker公司同时推广了[OCI](https://www.opencontainers.org/)标准
|
||||
|
||||
|
|
|
|||
|
|
@ -59,7 +59,7 @@ spec:
|
|||
restartPolicy: OnFailure
|
||||
```
|
||||
|
||||
```Bash
|
||||
```bash
|
||||
$ kubectl create -f cronjob.yaml
|
||||
cronjob "hello" created
|
||||
```
|
||||
|
|
|
|||
|
|
@ -116,15 +116,22 @@ Kubernetes 尽可能少地指定 CSI Volume 驱动程序的打包和部署规范
|
|||
|
||||
监听 Kubernetes PersistentVolumeClaim 对象的 sidecar 容器，并触发对 CSI 端点的 CreateVolume 和DeleteVolume 操作；
|
||||
|
||||
- [Driver-registrar](https://github.com/kubernetes-csi/driver-registrar)
|
||||
- [Driver-registrar](https://github.com/kubernetes-csi/driver-registrar)(DEPRECATED)
|
||||
|
||||
使用 Kubelet（将来）注册 CSI 驱动程序的 sidecar 容器，并将 `NodeId` （通过 `GetNodeID` 调用检索到 CSI endpoint）添加到 Kubernetes Node API 对象的 annotation 里面。
|
||||
|
||||
- [Cluster Driver Registrar](https://github.com/kubernetes-csi/cluster-driver-registrar)
|
||||
|
||||
创建 CSIDriver 这个集群范围的 CRD 对象。
|
||||
|
||||
- [Node Driver Registrar](https://github.com/kubernetes-csi/node-driver-registrar)
|
||||
|
||||
替代 Driver-registrar。
|
||||
|
||||
存储供应商完全可以使用这些组件来为其插件构建 Kubernetes Deployment，同时让它们的 CSI 驱动程序完全意识不到 Kubernetes 的存在。
|
||||
|
||||
另外 CSI 驱动完全是由第三方存储供应商自己维护的，在 kubernetes 1.9 版本中 CSI 还处于 alpha 版本。
|
||||
|
||||
## 参考
|
||||
|
||||
- [Introducing Container Storage Interface (CSI) Alpha for Kubernetes](http://blog.kubernetes.io/2018/01/introducing-container-storage-interface.html)
|
||||
- [Container Storage Interface (CSI)](https://github.com/container-storage-interface/spec/blob/master/spec.md)
|
||||
|
|
|
|||
|
|
@ -20,7 +20,7 @@ Kubernetes1.6版本中包含一个内建的资源叫做TPR（ThirdPartyResource
|
|||
|
||||
- 你的API是否属于[声明式的](https://kubernetes.io/docs/concepts/api-extension/custom-resources/#declarative-apis)
|
||||
- 是否想使用kubectl命令来管理
|
||||
- 是否要作为kubenretes中的对象类型来管理，同时显示在kuberetes dashboard上
|
||||
- 是否要作为kubenretes中的对象类型来管理，同时显示在kubernetes dashboard上
|
||||
- 是否可以遵守kubernetes的API规则限制，例如URL和API group、namespace限制
|
||||
- 是否可以接受该API只能作用于集群或者namespace范围
|
||||
- 想要复用kubernetes API的公共功能，比如CRUD、watch、内置的认证和授权等
|
||||
|
|
@ -130,8 +130,6 @@ metadata:
|
|||
|
||||
详情参考：[Extend the Kubernetes API with CustomResourceDefinitions](https://kubernetes.io/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/)
|
||||
|
||||
使用kubernetes1.7及以上版本请参考[Migrate a ThirdPartyResource to CustomResourceDefinition](https://kubernetes.io/docs/tasks/access-kubernetes-api/migrate-third-party-resource/)。
|
||||
|
||||
## 自定义控制器
|
||||
|
||||
单纯设置了自定义资源，并没有什么用，只有跟自定义控制器结合起来，才能将资源对象中的声明式API翻译成用户所期望的状态。自定义控制器可以用来管理任何资源类型，但是一般是跟自定义资源结合使用。
|
||||
|
|
@ -140,7 +138,7 @@ metadata:
|
|||
|
||||
## API server聚合
|
||||
|
||||
Aggregated（聚合的）API server是为了将原来的API server这个巨石（monolithic）应用给拆分成，为了方便用户开发自己的API server集成进来，而不用直接修改kubernetes官方仓库的代码，这样一来也能将API server解耦，方便用户使用实验特性。这些API server可以跟core API server无缝衔接，试用kubectl也可以管理它们。
|
||||
Aggregated（聚合的）API server是为了将原来的API server这个巨石（monolithic）应用给拆分成，为了方便用户开发自己的API server集成进来，而不用直接修改kubernetes官方仓库的代码，这样一来也能将API server解耦，方便用户使用实验特性。这些API server可以跟core API server无缝衔接，使用kubectl也可以管理它们。
|
||||
|
||||
详情参考[Aggregated API Server](aggregated-api-server.md)。
|
||||
|
||||
|
|
|
|||
|
|
@ -17,9 +17,9 @@
|
|||
|
||||
### 必需字段
|
||||
|
||||
和其它所有 Kubernetes 配置一样，DaemonSet 需要 `apiVersion`、`kind` 和 `metadata`字段。有关配置文件的通用信息，详见文档 [部署应用](https://kubernetes.io/docs/user-guide/deploying-applications/)、[配置容器](https://kubernetes.io/docs/user-guide/configuring-containers/) 和 [资源管理](https://kubernetes.io/docs/concepts/tools/kubectl/object-management-overview/) 。
|
||||
和其它所有 Kubernetes 配置一样，DaemonSet 需要 `apiVersion`、`kind` 和 `metadata`字段。有关配置文件的通用信息，详见文档 [部署应用](https://kubernetes.io/docs/user-guide/deploying-applications/)、[配置容器](https://kubernetes.io/docs/user-guide/configuring-containers/) 和资源管理。
|
||||
|
||||
DaemonSet 也需要一个 [`.spec`](https://git.k8s.io/community/contributors/devel/api-conventions.md#spec-and-status) 配置段。
|
||||
DaemonSet 也需要一个 `.spec`配置段。
|
||||
|
||||
### Pod 模板
|
||||
|
||||
|
|
@ -34,7 +34,7 @@ Pod 除了必须字段外，在 DaemonSet 中的 Pod 模板必须指定合理的
|
|||
|
||||
### Pod Selector
|
||||
|
||||
`.spec.selector` 字段表示 Pod Selector，它与 [Job](https://kubernetes.io/docs/concepts/jobs/run-to-completion-finite-workloads/) 或其它资源的 `.sper.selector` 的原理是相同的。
|
||||
`.spec.selector` 字段表示 Pod Selector，它与 [Job](https://kubernetes.io/docs/concepts/jobs/run-to-completion-finite-workloads/) 或其它资源的 `.spec.selector` 的原理是相同的。
|
||||
|
||||
`spec.selector` 表示一个对象，它由如下两个字段组成：
|
||||
|
||||
|
|
|
|||
|
|
@ -483,7 +483,7 @@ nginx-deployment-618515232 11 11 11 7m
|
|||
|
||||
## 暂停和恢复Deployment
|
||||
|
||||
您可以在发出一次或多次更新前暂停一个 Deployment，然后再恢复它。这样您就能多次暂停和恢复 Deployment，在此期间进行一些修复工作，而不会发出不必要的 rollout。
|
||||
您可以在发出一次或多次更新前暂停一个 Deployment，然后再恢复它。这样您就能在Deployment暂停期间进行多次修复工作，而不会发出不必要的 rollout。
|
||||
|
||||
例如使用刚刚创建 Deployment：
|
||||
|
||||
|
|
@ -669,7 +669,7 @@ status:
|
|||
unavailableReplicas: 2
|
||||
```
|
||||
|
||||
最终，一旦超过 Deployment 进程的 deadline，kuberentes 会更新状态和导致 Progressing 状态的原因：
|
||||
最终，一旦超过 Deployment 进程的 deadline，kubernetes 会更新状态和导致 Progressing 状态的原因：
|
||||
|
||||
```bash
|
||||
Conditions:
|
||||
|
|
@ -692,7 +692,7 @@ Conditions:
|
|||
|
||||
```
|
||||
|
||||
`Type=Available`、 `Status=True` 以为这您的Deployment有最小可用性。 最小可用性是在Deployment策略中指定的参数。`Type=Progressing` 、 `Status=True`意味着您的Deployment 或者在部署过程中，或者已经成功部署，达到了期望的最少的可用replica数量（查看特定状态的Reason——在我们的例子中`Reason=NewReplicaSetAvailable` 意味着Deployment已经完成）。
|
||||
`Type=Available`、 `Status=True` 意味着您的Deployment有最小可用性。 最小可用性是在Deployment策略中指定的参数。`Type=Progressing` 、 `Status=True`意味着您的Deployment 或者在部署过程中，或者已经成功部署，达到了期望的最少的可用replica数量（查看特定状态的Reason——在我们的例子中`Reason=NewReplicaSetAvailable` 意味着Deployment已经完成）。
|
||||
|
||||
您可以使用`kubectl rollout status`命令查看Deployment进程是否失败。当Deployment过程超过了deadline，`kubectl rollout status`将返回非0的exit code。
|
||||
|
||||
|
|
@ -722,7 +722,7 @@ $ echo $?
|
|||
|
||||
## 编写 Deployment Spec
|
||||
|
||||
在所有的 Kubernetes 配置中，Deployment 也需要`apiVersion`，`kind`和`metadata`这些配置项。配置文件的通用使用说明查看 [部署应用](https://kubernetes.io/docs/tasks/run-application/run-stateless-application-deployment/)，配置容器，和 [使用 kubectl 管理资源 ](https://kubernetes.io/docs/tutorials/object-management-kubectl/object-management/) 文档。
|
||||
在所有的 Kubernetes 配置中，Deployment 也需要`apiVersion`，`kind`和`metadata`这些配置项。配置文件的通用使用说明查看 [部署应用](https://kubernetes.io/docs/tasks/run-application/run-stateless-application-deployment/)，配置容器，和使用 kubectl 管理资源文档。
|
||||
|
||||
### Pod Template
|
||||
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
### Kubernetes中的网络解析——以flannel为例
|
||||
# Kubernetes中的网络解析——以flannel为例
|
||||
|
||||
我们当初使用[kubernetes-vagrant-centos-cluster](https://github.com/rootsongjc/kubernetes-vagrant-centos-cluster)安装了拥有三个节点的kubernetes集群，节点的状态如下所述。
|
||||
|
||||
|
|
@ -382,13 +382,12 @@ Chain KUBE-SERVICES (2 references)
|
|||
target prot opt source destination
|
||||
```
|
||||
|
||||
从上面的iptables中可以看到注入了很多Kuberentes service的规则，请参考[iptables 规则](https://www.cnyunwei.cc/archives/393)获取更多详细信息。
|
||||
从上面的iptables中可以看到注入了很多Kuberentes service的规则。
|
||||
|
||||
## 参考
|
||||
|
||||
- [coreos/flannel - github.com](https://github.com/coreos/flannel)
|
||||
- [linux 网络虚拟化： network namespace 简介](http://cizixs.com/2017/02/10/network-virtualization-network-namespace)
|
||||
- [Linux虚拟网络设备之veth](https://segmentfault.com/a/1190000009251098)
|
||||
- [iptables 规则](https://www.cnyunwei.cc/archives/393)
|
||||
- [flannel host-gw network](http://hustcat.github.io/flannel-host-gw-network/)
|
||||
- [flannel - openshift.com](https://docs.openshift.com/container-platform/3.4/architecture/additional_concepts/flannel.html)
|
||||
|
|
|
|||
|
|
@ -88,6 +88,8 @@ metadata:
|
|||
|
||||
对很多 Controller 资源，包括 ReplicationController、ReplicaSet、StatefulSet、DaemonSet 和 Deployment，默认的垃圾收集策略是 `orphan`。因此，除非指定其它的垃圾收集策略，否则所有 Dependent 对象使用的都是 `orphan` 策略。
|
||||
|
||||
**注意**：本段所指的默认值是指 REST API 的默认值，并非 kubectl 命令的默认值，kubectl 默认为级联删除，后面会讲到。
|
||||
|
||||
下面是一个在后台删除 Dependent 对象的例子：
|
||||
|
||||
```bash
|
||||
|
|
@ -119,7 +121,7 @@ kubectl 也支持级联删除。 通过设置 `--cascade` 为 true，可以使
|
|||
|
||||
下面是一个例子，使一个 ReplicaSet 的 Dependent 对象成为孤儿 Dependent：
|
||||
|
||||
```Bash
|
||||
```bash
|
||||
kubectl delete replicaset my-repset --cascade=false
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -13,7 +13,7 @@ Kubernetes自1.2版本引入HPA机制，到1.6版本之前一直是通过kubelet
|
|||
|
||||
## HPA解析
|
||||
|
||||
Horizontal Pod Autoscaling仅适用于Deployment和ReplicaSet，在V1版本中仅支持根据Pod的CPU利用率扩所容，在v1alpha版本中，支持根据内存和用户自定义的metric扩缩容。
|
||||
Horizontal Pod Autoscaling仅适用于Deployment和ReplicaSet，在v1版本中仅支持根据Pod的CPU利用率扩缩容，在v1alpha版本中，支持根据内存和用户自定义的metric扩缩容。
|
||||
|
||||
如果你不想看下面的文章可以直接看下面的示例图，组件交互、组件的配置、命令示例，都画在图上了。
|
||||
|
||||
|
|
|
|||
|
|
@ -39,9 +39,9 @@ Ingress是授权入站连接到达集群服务的规则集合。
|
|||
|
||||
在使用Ingress resource之前，有必要先了解下面几件事情。Ingress是beta版本的resource，在kubernetes1.1之前还没有。你需要一个`Ingress Controller`来实现`Ingress`，单纯的创建一个`Ingress`没有任何意义。
|
||||
|
||||
GCE/GKE会在master节点上部署一个ingress controller。你可以在一个pod中部署任意个自定义的ingress controller。你必须正确地annotate每个ingress，比如 [运行多个ingress controller](https://git.k8s.io/ingress#running-multiple-ingress-controllers) 和 [关闭glbc](https://git.k8s.io/ingress-gce/BETA_LIMITATIONS.md#disabling-glbc).
|
||||
GCE/GKE会在master节点上部署一个ingress controller。你可以在一个pod中部署任意个自定义的ingress controller。你必须正确地annotate每个ingress，比如 [运行多个ingress controller](https://git.k8s.io/ingress#running-multiple-ingress-controllers) 和 关闭glbc。
|
||||
|
||||
确定你已经阅读了Ingress controller的[beta版本限制](https://github.com/kubernetes/ingress-gce/blob/master/BETA_LIMITATIONS.md#glbc-beta-limitations)。在非GCE/GKE的环境中，你需要在pod中[部署一个controller](https://git.k8s.io/ingress-nginx/README.md)。
|
||||
确定你已经阅读了Ingress controller的 beta版本限制。在非GCE/GKE的环境中，你需要在pod中[部署一个controller](https://git.k8s.io/ingress-nginx/README.md)。
|
||||
|
||||
## Ingress Resource
|
||||
|
||||
|
|
@ -66,9 +66,9 @@ GCE/GKE会在master节点上部署一个ingress controller。你可以在一个p
|
|||
|
||||
**配置说明**
|
||||
|
||||
**1-4行**：跟Kubernetes的其他配置一样，ingress的配置也需要`apiVersion`，`kind`和`metadata`字段。配置文件的详细说明请查看[部署应用](https://kubernetes.io/docs/user-guide/deploying-applications), [配置容器](https://kubernetes.io/docs/user-guide/configuring-containers)和 [使用resources](https://kubernetes.io/docs/user-guide/working-with-resources).
|
||||
**1-4行**：跟Kubernetes的其他配置一样，ingress的配置也需要`apiVersion`，`kind`和`metadata`字段。配置文件的详细说明请查看[部署应用](https://kubernetes.io/docs/user-guide/deploying-applications), [配置容器](https://kubernetes.io/docs/user-guide/configuring-containers)和使用resources。
|
||||
|
||||
**5-7行**: Ingress [spec](https://github.com/kubernetes/community/blob/master/contributors/devel/api-conventions.md#spec-and-status) 中包含配置一个loadbalancer或proxy server的所有信息。最重要的是，它包含了一个匹配所有入站请求的规则列表。目前ingress只支持http规则。
|
||||
**5-7行**: Ingress spec 中包含配置一个loadbalancer或proxy server的所有信息。最重要的是，它包含了一个匹配所有入站请求的规则列表。目前ingress只支持http规则。
|
||||
|
||||
**8-9行**：每条http规则包含以下信息：一个`host`配置项（比如for.bar.com，在这个例子中默认是*），`path`列表（比如：/testpath），每个path都关联一个`backend`(比如test:80)。在loadbalancer将流量转发到backend之前，所有的入站请求都要先匹配host和path。
|
||||
|
||||
|
|
@ -83,7 +83,7 @@ GCE/GKE会在master节点上部署一个ingress controller。你可以在一个p
|
|||
- F5（公司）[支持并维护](https://support.f5.com/csp/article/K86859508) [F5 BIG-IP Controller for Kubernetes](http://clouddocs.f5.com/products/connectors/k8s-bigip-ctlr/latest).
|
||||
- [Kong](https://konghq.com/) 同时支持并维护[社区版](https://discuss.konghq.com/c/kubernetes)与[企业版](https://konghq.com/api-customer-success/)的 [Kong Ingress Controller for Kubernetes](https://konghq.com/blog/kubernetes-ingress-controller-for-kong/).
|
||||
- [Traefik](https://github.com/containous/traefik) 是功能齐全的 ingress controller([Let’s Encrypt](https://letsencrypt.org/), secrets, http2, websocket…), [Containous](https://containo.us/services) 也对其提供商业支持。
|
||||
- [Istio](https://istio.io/zh) 使用CRD Gateway来[控制Ingress流量](https://istio.io/zh/docs/tasks/traffic-management/ingress/)。
|
||||
- [Istio](https://istio.io) 使用CRD Gateway来[控制Ingress流量](https://istio.io/docs/tasks/traffic-management/ingress/)。
|
||||
|
||||
|
||||
## 在你开始前
|
||||
|
|
@ -122,7 +122,7 @@ test-ingress - testsvc:80 107.178.254.228
|
|||
|
||||
### 简单展开
|
||||
|
||||
如前面描述的那样，kubernete pod中的IP只在集群网络内部可见，我们需要在边界设置一个东西，让它能够接收ingress的流量并将它们转发到正确的端点上。这个东西一般是高可用的loadbalancer。使用Ingress能够允许你将loadbalancer的个数降低到最少，例如，假如你想要创建这样的一个设置：
|
||||
如前面描述的那样，kubernetes pod中的IP只在集群网络内部可见，我们需要在边界设置一个东西，让它能够接收ingress的流量并将它们转发到正确的端点上。这个东西一般是高可用的loadbalancer。使用Ingress能够允许你将loadbalancer的个数降低到最少，例如，假如你想要创建这样的一个设置：
|
||||
|
||||
```
|
||||
foo.bar.com -> 178.91.123.132 -> / foo s1:80
|
||||
|
|
@ -240,7 +240,7 @@ Ingress controller启动时附带一些适用于所有Ingress的负载平衡策
|
|||
|
||||
假如你想要向已有的ingress中增加一个新的Host，你可以编辑和更新该ingress：
|
||||
|
||||
```Bash
|
||||
```bash
|
||||
$ kubectl get ing
|
||||
NAME RULE BACKEND ADDRESS
|
||||
test - 178.91.123.132
|
||||
|
|
@ -287,7 +287,7 @@ test - 178.91.123.132
|
|||
|
||||
## 跨可用域故障
|
||||
|
||||
在不通云供应商之间，跨故障域的流量传播技术有所不同。 有关详细信息，请查看相关Ingress controller的文档。 有关在federation集群中部署Ingress的详细信息，请参阅federation文档。
|
||||
在不同云供应商之间，跨故障域的流量传播技术有所不同。 有关详细信息，请查看相关Ingress controller的文档。 有关在federation集群中部署Ingress的详细信息，请参阅federation文档。
|
||||
|
||||
## 未来计划
|
||||
|
||||
|
|
@ -314,6 +314,3 @@ test - 178.91.123.132
|
|||
- [使用 NGINX 和 NGINX Plus 的 Ingress Controller 进行 Kubernetes 的负载均衡](http://www.cnblogs.com/276815076/p/6407101.html)
|
||||
- [Kubernetes : Ingress Controller with Træfɪk and Let's Encrypt](https://blog.osones.com/en/kubernetes-ingress-controller-with-traefik-and-lets-encrypt.html)
|
||||
- [Kubernetes : Træfɪk and Let's Encrypt at scale](https://blog.osones.com/en/kubernetes-traefik-and-lets-encrypt-at-scale.html)
|
||||
- [Kubernetes Ingress Controller-Træfɪk](https://docs.traefik.io/user-guide/kubernetes/)
|
||||
- [Kubernetes 1.2 and simplifying advanced networking with Ingress](http://blog.kubernetes.io/2016/03/Kubernetes-1.2-and-simplifying-advanced-networking-with-Ingress.html)
|
||||
- [使用Istio控制Ingress流量](https://istio.io/zh/docs/tasks/traffic-management/ingress/)
|
||||
|
|
@ -186,7 +186,7 @@ $ kubectl logs myapp-pod -c init-mydb # Inspect the second init container
|
|||
|
||||
一旦我们启动了 `mydb` 和 `myservice` 这两个 Service，我们能够看到 Init 容器完成，并且 `myapp-pod` 被创建：
|
||||
|
||||
```Bash
|
||||
```bash
|
||||
$ kubectl create -f services.yaml
|
||||
service "myservice" created
|
||||
service "mydb" created
|
||||
|
|
|
|||
|
|
@ -1,10 +1,12 @@
|
|||
# Network Policy
|
||||
|
||||
网络策略说明一组 `Pod` 之间是如何被允许互相通信，以及如何与其它网络 Endpoint 进行通信。 `NetworkPolicy` 资源使用标签来选择 `Pod`，并定义了一些规则，这些规则指明允许什么流量进入到选中的 `Pod` 上。
|
||||
网络策略说明一组 `Pod` 之间是如何被允许互相通信，以及如何与其它网络 Endpoint 进行通信。 `NetworkPolicy` 资源使用标签来选择 `Pod`，并定义了一些规则，这些规则指明允许什么流量进入到选中的 `Pod` 上。关于 Network Policy 的详细用法请参考 [Kubernetes 官网](https://kubernetes.io/docs/concepts/services-networking/network-policies/)。
|
||||
|
||||
Network Policy 的作用对象是 Pod，也可以应用到 Namespace 和集群的 Ingress、Egress 流量。Network Policy 是作用在 L3/4 层的，即限制的是对 IP 地址和端口的访问，如果需要对应用层做访问限制需要使用如 [Istio](https://istio.io) 这类 Service Mesh。
|
||||
|
||||
## 前提条件
|
||||
|
||||
网络策略通过网络插件来实现，所以必须使用一种支持 `NetworkPolicy` 的网络方案 —— 非 Controller 创建的资源，是不起作用的。
|
||||
网络策略通过网络插件来实现，所以必须使用一种支持 `NetworkPolicy` 的网络方案（如 [calico](https://www.projectcalico.org/)）—— 非 Controller 创建的资源，是不起作用的。
|
||||
|
||||
## 隔离的与未隔离的 Pod
|
||||
|
||||
|
|
@ -12,8 +14,6 @@
|
|||
|
||||
## `NetworkPolicy` 资源
|
||||
|
||||
查看 [API参考](https://kubernetes.io/docs/api-reference/v1.7/#networkpolicy-v1-networking) 可以获取该资源的完整定义。
|
||||
|
||||
下面是一个 `NetworkPolicy` 的例子：
|
||||
|
||||
```yaml
|
||||
|
|
@ -26,8 +26,15 @@ spec:
|
|||
podSelector:
|
||||
matchLabels:
|
||||
role: db
|
||||
policyTypes:
|
||||
- Ingress
|
||||
- Egress
|
||||
ingress:
|
||||
- from:
|
||||
- ipBlock:
|
||||
cidr: 172.17.0.0/16
|
||||
except:
|
||||
- 172.17.1.0/24
|
||||
- namespaceSelector:
|
||||
matchLabels:
|
||||
project: myproject
|
||||
|
|
@ -37,25 +44,34 @@ spec:
|
|||
ports:
|
||||
- protocol: TCP
|
||||
port: 6379
|
||||
egress:
|
||||
- to:
|
||||
- ipBlock:
|
||||
cidr: 10.0.0.0/24
|
||||
ports:
|
||||
- protocol: TCP
|
||||
port: 5978
|
||||
```
|
||||
|
||||
*将上面配置 POST 到 API Server 将不起任何作用，除非选择的网络方案支持网络策略。*
|
||||
|
||||
**必选字段**：像所有其它 Kubernetes 配置一样， `NetworkPolicy` 需要 `apiVersion`、`kind` 和 `metadata` 这三个字段，关于如何使用配置文件的基本信息，可以查看 [这里](https://kubernetes.io/docs/user-guide/configuring-containers) 和 [这里](https://kubernetes.io/docs/user-guide/working-with-resources)。
|
||||
**必选字段**：像所有其它 Kubernetes 配置一样， `NetworkPolicy` 需要 `apiVersion`、`kind` 和 `metadata` 这三个字段，关于如何使用配置文件的基本信息，可以查看 [这里](https://kubernetes.io/docs/user-guide/configuring-containers)。
|
||||
|
||||
**spec**：`NetworkPolicy` [spec](https://git.k8s.io/community/contributors/devel/api-conventions.md#spec-and-status) 具有在给定 Namespace 中定义特定网络的全部信息。
|
||||
**spec**：`NetworkPolicy` spec 具有在给定 Namespace 中定义特定网络的全部信息。
|
||||
|
||||
**podSelector**：每个 `NetworkPolicy` 包含一个 `podSelector`，它可以选择一组应用了网络策略的 Pod。由于 `NetworkPolicy` 当前只支持定义 `ingress` 规则，这个 `podSelector` 实际上为该策略定义了一组 “目标Pod”。示例中的策略选择了标签为 “role=db” 的 Pod。一个空的 `podSelector` 选择了该 Namespace 中的所有 Pod。
|
||||
|
||||
**ingress**：每个`NetworkPolicy` 包含了一个白名单 `ingress` 规则列表。每个规则只允许能够匹配上 `from` 和 `ports`配置段的流量。示例策略包含了单个规则，它从这两个源中匹配在单个端口上的流量，第一个是通过`namespaceSelector` 指定的，第二个是通过 `podSelector` 指定的。
|
||||
|
||||
**egress**：每个`NetworkPolicy` 包含了一个白名单 `ingress` 规则列表。每个规则只允许能够匹配上 `to` 和 `ports`配置段的流量。示例策略包含了单个规则，它匹配目的地 `10.0.0.0/24` 单个端口的流量。
|
||||
|
||||
因此，上面示例的 NetworkPolicy：
|
||||
|
||||
1. 在 “default” Namespace中 隔离了标签 “role=db” 的 Pod（如果他们还没有被隔离）
|
||||
2. 在 “default” Namespace中，允许任何具有 “role=frontend” 的 Pod，连接到标签为 “role=db” 的 Pod 的 TCP 端口 6379
|
||||
3. 允许在 Namespace 中任何具有标签 “project=myproject” 的 Pod，连接到 “default” Namespace 中标签为 “role=db” 的 Pod 的 TCP 端口 6379
|
||||
2. 在 “default” Namespace中，允许任何具有 “role=frontend” 的 Pod，IP 范围在 172.17.0.0–172.17.0.255 和 172.17.2.0–172.17.255.255（整个 172.17.0.0/16 段， 172.17.1.0/24 除外）连接到标签为 “role=db” 的 Pod 的 TCP 端口 6379
|
||||
3. 允许在 Namespace 中任何具有标签 “project=myproject” ，IP范围在10.0.0.0/24段的 Pod，连接到 “default” Namespace 中标签为 “role=db” 的 Pod 的 TCP 端口 5978
|
||||
|
||||
查看 [NetworkPolicy 入门指南](https://kubernetes.io/docs/getting-started-guides/network-policy/walkthrough) 给出的更进一步的例子。
|
||||
查看 [NetworkPolicy 入门指南](https://kubernetes.io/docs/getting-started-guides/network-policy/walkthrough)给出的更进一步的例子。
|
||||
|
||||
## 默认策略
|
||||
|
||||
|
|
@ -84,6 +100,7 @@ spec:
|
|||
ingress:
|
||||
- {}
|
||||
```
|
||||
原文地址：https://k8smeetup.github.io/docs/concepts/services-networking/network-policies/
|
||||
## 参考
|
||||
|
||||
译者：[shirdrn](https://github.com/shirdrn)
|
||||
- [Network Policies - k8smeetup.github.io](https://k8smeetup.github.io/docs/concepts/services-networking/network-policies/)
|
||||
- [Network Policies - kubernetes.io](https://kubernetes.io/docs/concepts/services-networking/network-policies/)
|
||||
|
|
|
|||
|
|
@ -13,8 +13,8 @@ Node包括如下状态信息：
|
|||
- Condition
|
||||
- OutOfDisk：磁盘空间不足时为`True`
|
||||
- Ready：Node controller 40秒内没有收到node的状态报告为`Unknown`，健康为`True`，否则为`False`。
|
||||
- MemoryPressure：当node没有内存压力时为`True`，否则为`False`。
|
||||
- DiskPressure：当node没有磁盘压力时为`True`，否则为`False`。
|
||||
- MemoryPressure：当node有内存压力时为`True`，否则为`False`。
|
||||
- DiskPressure：当node有磁盘压力时为`True`，否则为`False`。
|
||||
- Capacity
|
||||
- CPU
|
||||
- 内存
|
||||
|
|
|
|||
|
|
@ -47,7 +47,7 @@
|
|||
|
||||
Kubernetes 对象是 “目标性记录” —— 一旦创建对象，Kubernetes 系统将持续工作以确保对象存在。通过创建对象，可以有效地告知 Kubernetes 系统，所需要的集群工作负载看起来是什么样子的，这就是 Kubernetes 集群的 **期望状态**。
|
||||
|
||||
与 Kubernetes 对象工作 —— 是否创建、修改，或者删除 —— 需要使用 [Kubernetes API](https://git.k8s.io/community/contributors/devel/api-conventions.md)。当使用 `kubectl` 命令行接口时，比如，CLI 会使用必要的 Kubernetes API 调用，也可以在程序中直接使用 Kubernetes API。为了实现该目标，Kubernetes 当前提供了一个 `golang` [客户端库](https://github.com/kubernetes/client-go) ，其它语言库（例如[Python](https://github.com/kubernetes-incubator/client-python)）也正在开发中。
|
||||
与 Kubernetes 对象工作 —— 是否创建、修改，或者删除 —— 需要使用 Kubernetes API。当使用 `kubectl` 命令行接口时，比如，CLI 会使用必要的 Kubernetes API 调用，也可以在程序中直接使用 Kubernetes API。为了实现该目标，Kubernetes 当前提供了一个 `golang` [客户端库](https://github.com/kubernetes/client-go) ，其它语言库（例如[Python](https://github.com/kubernetes-incubator/client-python)）也正在开发中。
|
||||
|
||||
### 对象 Spec 与状态
|
||||
|
||||
|
|
@ -55,7 +55,7 @@ Kubernetes 对象是 “目标性记录” —— 一旦创建对象，Kubernete
|
|||
|
||||
例如，Kubernetes Deployment 对象能够表示运行在集群中的应用。当创建 Deployment 时，可能需要设置 Deployment 的 spec，以指定该应用需要有 3 个副本在运行。Kubernetes 系统读取 Deployment spec，启动我们所期望的该应用的 3 个实例 —— 更新状态以与 spec 相匹配。如果那些实例中有失败的（一种状态变更），Kubernetes 系统通过修正来响应 spec 和状态之间的不一致 —— 这种情况，启动一个新的实例来替换。
|
||||
|
||||
关于对象 spec、status 和 metadata 更多信息，查看 [Kubernetes API Conventions](https://git.k8s.io/community/contributors/devel/api-conventions.md)。
|
||||
关于对象 spec、status 和 metadata 更多信息，查看 [Kubernetes API Conventions]( https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md)。
|
||||
|
||||
### 描述 Kubernetes 对象
|
||||
|
||||
|
|
|
|||
|
|
@ -34,7 +34,7 @@ PV 属于集群中的资源。PVC 是对这些资源的请求，也作为对资
|
|||
|
||||
### 绑定
|
||||
|
||||
再动态配置的情况下，用户创建或已经创建了具有特定存储量的 `PersistentVolumeClaim` 以及某些访问模式。master 中的控制环路监视新的 PVC，寻找匹配的 PV（如果可能），并将它们绑定在一起。如果为新的 PVC 动态调配 PV，则该环路将始终将该 PV 绑定到 PVC。否则，用户总会得到他们所请求的存储，但是容量可能超出要求的数量。一旦 PV 和 PVC 绑定后，`PersistentVolumeClaim` 绑定是排他性的，不管它们是如何绑定的。 PVC 跟 PV 绑定是一对一的映射。
|
||||
在动态配置的情况下，用户创建或已经创建了具有特定存储量的 `PersistentVolumeClaim` 以及某些访问模式。master 中的控制环路监视新的 PVC，寻找匹配的 PV（如果可能），并将它们绑定在一起。如果为新的 PVC 动态调配 PV，则该环路将始终将该 PV 绑定到 PVC。否则，用户总会得到他们所请求的存储，但是容量可能超出要求的数量。一旦 PV 和 PVC 绑定后，`PersistentVolumeClaim` 绑定是排他性的，不管它们是如何绑定的。 PVC 跟 PV 绑定是一对一的映射。
|
||||
|
||||
如果没有匹配的卷，声明将无限期地保持未绑定状态。随着匹配卷的可用，声明将被绑定。例如，配置了许多 50Gi PV的集群将不会匹配请求 100Gi 的PVC。将100Gi PV 添加到群集时，可以绑定 PVC。
|
||||
|
||||
|
|
|
|||
|
|
@ -63,7 +63,7 @@ PDB 不能阻止[非自愿中断](https://kubernetes.io/docs/concepts/workloads/
|
|||
|
||||
由于应用程序的滚动升级而被删除或不可用的 Pod 确实会计入中断预算，但控制器（如 Deployment 和 StatefulSet）在进行滚动升级时不受 PDB 的限制——在应用程序更新期间的故障处理是在控制器的规格（spec）中配置（了解[更新 Deployment](https://kubernetes.io/docs/concepts/cluster-administration/manage-deployment/#updating-your-application-without-a-service-outage)）。
|
||||
|
||||
使用驱逐 API 驱逐 pod 时，pod 会被优雅地终止（请参阅 PodSpec） 中的 `terminationGracePeriodSeconds`）。
|
||||
使用驱逐 API 驱逐 pod 时，pod 会被优雅地终止（请参阅 PodSpec 中的 `terminationGracePeriodSeconds`）。
|
||||
|
||||
## PDB 示例
|
||||
|
||||
|
|
|
|||
|
|
@ -33,7 +33,7 @@ spec:
|
|||
|
||||
## 调试hook
|
||||
|
||||
Hook调用的日志没有暴露个给Pod的event，所以只能通过`describe`命令来获取，如果有错误将可以看到`FailedPostStartHook`或`FailedPreStopHook`这样的event。
|
||||
Hook调用的日志没有暴露给Pod的event，所以只能通过`describe`命令来获取，如果有错误将可以看到`FailedPostStartHook`或`FailedPreStopHook`这样的event。
|
||||
|
||||
## 参考
|
||||
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
|
||||
## Pod phase
|
||||
|
||||
Pod 的 `status` 在信息保存在 PodStatus 中定义，其中有一个 `phase` 字段。
|
||||
Pod 的 `status` 字段是一个 PodStatus 对象，PodStatus中有一个 `phase` 字段。
|
||||
|
||||
Pod 的相位（phase）是 Pod 在其生命周期中的简单宏观概述。该阶段并不是对容器或 Pod 的综合汇总，也不是为了做为综合状态机。
|
||||
|
||||
|
|
@ -22,7 +22,7 @@ Pod 相位的数量和含义是严格指定的。除了本文档中列举的状
|
|||
|
||||
## Pod 状态
|
||||
|
||||
Pod 有一个 PodStatus 对象，其中包含一个 PodCondition 数组。 PodCondition 数组的每个元素都有一个 `type` 字段和一个 `status` 字段。`type` 字段是字符串，可能的值有 PodScheduled、Ready、Initialized 和 Unschedulable。`status` 字段是一个字符串，可能的值有 True、False 和 Unknown。
|
||||
Pod 有一个 PodStatus 对象，其中包含一个 PodCondition 数组。 PodCondition 数组的每个元素都有一个 `type` 字段和一个 `status` 字段。`type` 字段是字符串，可能的值有 PodScheduled、Ready、Initialized、Unschedulable和ContainersReady。`status` 字段是一个字符串，可能的值有 True、False 和 Unknown。
|
||||
|
||||
## 容器探针
|
||||
|
||||
|
|
|
|||
|
|
@ -2,22 +2,22 @@
|
|||
|
||||
## 理解Pod
|
||||
|
||||
Pod是kubernetes中你可以创建和部署的最小也是最简的单位。一个Pod代表着集群中运行的一个进程。
|
||||
Pod是kubernetes中你可以创建和部署的最小也是最简的单位。Pod代表着集群中运行的进程。
|
||||
|
||||
Pod中封装着应用的容器（有的情况下是好几个容器），存储、独立的网络IP，管理容器如何运行的策略选项。Pod代表着部署的一个单位：kubernetes中应用的一个实例，可能由一个或者多个容器组合在一起共享资源。
|
||||
|
||||
> [Docker](https://www.docker.com)是kubernetes中最常用的容器运行时，但是Pod也支持其他容器运行时。
|
||||
|
||||
|
||||
在Kubrenetes集群中Pod有如下两种使用方式：
|
||||
在Kubernetes集群中Pod有如下两种使用方式：
|
||||
|
||||
- **一个Pod中运行一个容器**。“每个Pod中一个容器”的模式是最常见的用法；在这种使用方式中，你可以把Pod想象成是单个容器的封装，kuberentes管理的是Pod而不是直接管理容器。
|
||||
- **在一个Pod中同时运行多个容器**。一个Pod中也可以同时封装几个需要紧密耦合互相协作的容器，它们之间共享资源。这些在同一个Pod中的容器可以互相协作成为一个service单位——一个容器共享文件，另一个“sidecar”容器来更新这些文件。Pod将这些容器的存储资源作为一个实体来管理。
|
||||
|
||||
[Kubernetes Blog](http://blog.kubernetes.io) 有关于Pod用例的详细信息，查看：
|
||||
|
||||
- [The Distributed System Toolkit: Patterns for Composite Containers](http://blog.kubernetes.io/2015/06/the-distributed-system-toolkit-patterns.html)
|
||||
- [Container Design Patterns](http://blog.kubernetes.io/2016/06/container-design-patterns.html)
|
||||
- [The Distributed System Toolkit: Patterns for Composite Containers](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns/)
|
||||
- [Container Design Patterns](https://kubernetes.io/blog/2016/06/container-design-patterns/)
|
||||
|
||||
每个Pod都是应用的一个实例。如果你想平行扩展应用的话（运行多个实例），你应该运行多个Pod，每个Pod都是一个应用实例。在Kubernetes中，这通常被称为replication。
|
||||
|
||||
|
|
@ -37,11 +37,11 @@ Pod中可以共享两种资源：网络和存储。
|
|||
|
||||
#### 存储
|
||||
|
||||
可以Pod指定多个共享的Volume。Pod中的所有容器都可以访问共享的volume。Volume也可以用来持久化Pod中的存储资源，以防容器重启后文件丢失。
|
||||
可以为一个Pod指定多个共享的Volume。Pod中的所有容器都可以访问共享的volume。Volume也可以用来持久化Pod中的存储资源，以防容器重启后文件丢失。
|
||||
|
||||
## 使用Pod
|
||||
|
||||
你很少会直接在kubernetes中创建单个Pod。因为Pod的生命周期是短暂的，用后即焚的实体。当Pod被创建后（不论是由你直接创建还是被其他Controller），都会被Kuberentes调度到集群的Node上。直到Pod的进程终止、被删掉、因为缺少资源而被驱逐、或者Node故障之前这个Pod都会一直保持在那个Node上。
|
||||
你很少会直接在kubernetes中创建单个Pod。因为Pod的生命周期是短暂的，用后即焚的实体。当Pod被创建后（不论是由你直接创建还是被其他Controller），都会被Kubernetes调度到集群的Node上。直到Pod的进程终止、被删掉、因为缺少资源而被驱逐、或者Node故障之前这个Pod都会一直保持在那个Node上。
|
||||
|
||||
> 注意：重启Pod中的容器跟重启Pod不是一回事。Pod只提供容器的运行环境并保持容器的运行状态，重启容器不会造成Pod重启。
|
||||
|
||||
|
|
|
|||
|
|
@ -45,7 +45,3 @@ Kubernetes 提供了一个准入控制器（`PodPreset`），当其启用时，P
|
|||
## 更多资料
|
||||
|
||||
- [使用 PodPreset 向 Pod 中注入数据](https://kubernetes.io/docs/tasks/inject-data-application/podpreset)
|
||||
|
||||
本文为 Kubernetes 官方中文文档，地址：https://kubernetes.io/cn/docs/concepts/workloads/pods/podpreset/
|
||||
|
||||
翻译: [rootsongjc](https://github.com/rootsongjc)
|
||||
|
|
@ -54,7 +54,7 @@ Pod也可以用于垂直应用栈（例如LAMP），这样使用的主要动机
|
|||
|
||||
通常单个pod中不会同时运行一个应用的多个实例。
|
||||
|
||||
详细说明请看： [The Distributed System ToolKit: Patterns for Composite Containers](http://blog.kubernetes.io/2015/06/the-distributed-system-toolkit-patterns.html).
|
||||
详细说明请看： [The Distributed System ToolKit: Patterns for Composite Containers](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns/).
|
||||
|
||||
## 其他替代选择
|
||||
|
||||
|
|
@ -90,7 +90,7 @@ Pod 原语有利于：
|
|||
|
||||
## Pod的终止
|
||||
|
||||
因为Pod作为在集群的节点上运行的进程，所以在不再需要的时候能够优雅的终止掉是十分必要的（比起使用发送KILL信号这种暴力的方式）。用户需要能够放松删除请求，并且知道它们何时会被终止，是否被正确的删除。用户想终止程序时发送删除pod的请求，在pod可以被强制删除前会有一个宽限期，会发送一个TERM请求到每个容器的主进程。一旦超时，将向主进程发送KILL信号并从API server中删除。如果kubelet或者container manager在等待进程终止的过程中重启，在重启后仍然会重试完整的宽限期。
|
||||
因为Pod作为在集群的节点上运行的进程，所以在不再需要的时候能够优雅的终止掉是十分必要的（比起使用发送KILL信号这种暴力的方式）。用户需要能够发起一个删除 Pod 的请求，并且知道它们何时会被终止，是否被正确的删除。用户想终止程序时发送删除pod的请求，在pod可以被强制删除前会有一个宽限期，会发送一个TERM请求到每个容器的主进程。一旦超时，将向主进程发送KILL信号并从API server中删除。如果kubelet或者container manager在等待进程终止的过程中重启，在重启后仍然会重试完整的宽限期。
|
||||
|
||||
示例流程如下：
|
||||
|
||||
|
|
@ -102,9 +102,10 @@ Pod 原语有利于：
|
|||
2. 向Pod中的进程发送TERM信号；
|
||||
5. 跟第三步同时，该Pod将从该service的端点列表中删除，不再是replication controller的一部分。关闭的慢的pod将继续处理load balancer转发的流量；
|
||||
6. 过了宽限期后，将向Pod中依然运行的进程发送SIGKILL信号而杀掉进程。
|
||||
7. Kublete会在API server中完成Pod的的删除，通过将优雅周期设置为0（立即删除）。Pod在API中消失，并且在客户端也不可见。
|
||||
7. Kubelet会在API server中完成Pod的的删除，通过将优雅周期设置为0（立即删除）。Pod在API中消失，并且在客户端也不可见。
|
||||
|
||||
删除宽限期默认是30秒。 `kubectl delete`命令支持 `—grace-period=<seconds>` 选项，允许用户设置自己的宽限期。如果设置为0将强制删除pod。在kubectl>=1.5版本的命令中，你必须同时使用 `--force` 和 `--grace-period=0` 来强制删除pod。
|
||||
在 yaml 文件中可以通过 `{{ .spec.spec.terminationGracePeriodSeconds }}` 来修改此值。
|
||||
|
||||
### 强制删除Pod
|
||||
|
||||
|
|
@ -114,7 +115,7 @@ Pod的强制删除是通过在集群和etcd中将其定义为删除状态。当
|
|||
|
||||
## Pod中容器的特权模式
|
||||
|
||||
从Kubernetes1.1版本开始，pod中的容器就可以开启previleged模式，在容器定义文件的 `SecurityContext` 下使用 `privileged` flag。 这在使用Linux的网络操作和访问设备的能力时是很有用的。容器内进程可获得近乎等同于容器外进程的权限。在不需要修改和重新编译kubelet的情况下就可以使用pod来开发节点的网络和存储插件。
|
||||
从Kubernetes1.1版本开始，pod中的容器就可以开启privileged模式，在容器定义文件的 `SecurityContext` 下使用 `privileged` flag。 这在使用Linux的网络操作和访问设备的能力时是很有用的。容器内进程可获得近乎等同于容器外进程的权限。在不需要修改和重新编译kubelet的情况下就可以使用pod来开发节点的网络和存储插件。
|
||||
|
||||
如果master节点运行的是kuberentes1.1或更高版本，而node节点的版本低于1.1版本，则API server将也可以接受新的特权模式的pod，但是无法启动，pod将处于pending状态。
|
||||
|
||||
|
|
|
|||
|
|
@ -8,5 +8,5 @@ Kubernetes中的众多资源类型，例如Deployment、DaemonSet、StatefulSet
|
|||
|
||||
考虑以下两种情况：
|
||||
|
||||
- 集群中有新增节点，想要让集群中的节点的资源利用率比较均衡一些，想要将一些高负载的节点上的pod驱逐到新增节点上，这是kuberentes的scheduer所不支持的，需要使用如[rescheduler](https://github.com/kubernetes-incubator/descheduler)这样的插件来实现。
|
||||
- 想要运行一些大数据应用，设计到资源分片，pod需要与数据分布达到一致均衡，避免个别节点处理大量数据，而其它节点闲置导致整个作业延迟，这时候可以考虑使用[kube-arbitritor](https://github.com/kubernetes-incubator/kube-arbitrator)。
|
||||
- 集群中有新增节点，想要让集群中的节点的资源利用率比较均衡一些，想要将一些高负载的节点上的pod驱逐到新增节点上，这是kuberentes的scheduler所不支持的，需要使用如[descheduler](https://github.com/kubernetes-incubator/descheduler)这样的插件来实现。
|
||||
- 想要运行一些大数据应用，设计到资源分片，pod需要与数据分布达到一致均衡，避免个别节点处理大量数据，而其它节点闲置导致整个作业延迟，这时候可以考虑使用[kube-batch](https://github.com/kubernetes-incubator/kube-batch)。
|
||||
|
|
|
|||
|
|
@ -195,7 +195,7 @@ spec:
|
|||
## 选择自己的 IP 地址
|
||||
|
||||
在 `Service` 创建的请求中，可以通过设置 `spec.clusterIP` 字段来指定自己的集群 IP 地址。
|
||||
比如，希望替换一个已经已存在的 DNS 条目，或者遗留系统已经配置了一个固定的 IP 且很难重新配置。
|
||||
比如，希望替换一个已经存在的 DNS 条目，或者遗留系统已经配置了一个固定的 IP 且很难重新配置。
|
||||
用户选择的 IP 地址必须合法，并且这个 IP 地址在 `service-cluster-ip-range` CIDR 范围内，这对 API Server 来说是通过一个标识来指定的。
|
||||
如果 IP 地址不合法，API Server 会返回 HTTP 状态码 422，表示值不合法。
|
||||
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ Service Account为Pod中的进程提供身份信息。
|
|||
|
||||
**注意**：**本文是关于 Service Account 的用户指南，管理指南另见 Service Account 的集群管理指南 。**
|
||||
|
||||
> 本文档描述的关于 Serivce Account 的行为只有当您按照 Kubernetes 项目建议的方式搭建起集群的情况下才有效。您的集群管理员可能在您的集群中有自定义配置，这种情况下该文档可能并不适用。
|
||||
> 本文档描述的关于 Service Account 的行为只有当您按照 Kubernetes 项目建议的方式搭建起集群的情况下才有效。您的集群管理员可能在您的集群中有自定义配置，这种情况下该文档可能并不适用。
|
||||
|
||||
当您（真人用户）访问集群（例如使用`kubectl`命令）时，apiserver 会将您认证为一个特定的 User Account（目前通常是`admin`，除非您的系统管理员自定义了集群配置）。Pod 容器中的进程也可以与 apiserver 联系。 当它们在联系 apiserver 的时候，它们会被认证为一个特定的 Service Account（例如`default`）。
|
||||
|
||||
|
|
|
|||
|
|
@ -491,7 +491,7 @@ kubectl expose po zk-1 --port=2181 --target-port=2181 --name=zk-1 --selector=zkI
|
|||
|
||||
查看`zk-0`这个service可以看到如下结果：
|
||||
|
||||
```
|
||||
```bash
|
||||
NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE
|
||||
zk-0 10.254.98.14 <nodes> 2181:31693/TCP 5m
|
||||
```
|
||||
|
|
@ -500,6 +500,6 @@ zk-0 10.254.98.14 <nodes> 2181:31693/TCP 5m
|
|||
|
||||
## 参考
|
||||
|
||||
https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/
|
||||
- https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/
|
||||
|
||||
[kubernetes contrib - statefulsets](https://github.com/kubernetes/contrib/tree/master/statefulsets)
|
||||
- [kubernetes contrib - statefulsets](https://github.com/kubernetes/contrib/tree/master/statefulsets)
|
||||
|
|
@ -58,8 +58,3 @@ upstream docGenerate {
|
|||
```
|
||||
|
||||
172.20.0.119是我们的边缘节点的VIP，见[边缘节点配置](../practice/edge-node-configuration.md)。
|
||||
|
||||
## 参考
|
||||
|
||||
- [Kubernetes Ingress Backend - traefik.io](https://docs.traefik.io/configuration/backends/kubernetes/)
|
||||
- [Kubernetes Ingress Controller - traefik.io](http://docs.traefik.io/user-guide/kubernetes/)
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@
|
|||
|
||||
Docker 中也有一个 [volume](https://docs.docker.com/engine/admin/volumes/) 的概念，尽管它稍微宽松一些，管理也很少。在 Docker 中，卷就像是磁盘或是另一个容器中的一个目录。它的生命周期不受管理，直到最近才有了 local-disk-backed 卷。Docker 现在提供了卷驱动程序，但是功能还非常有限（例如Docker1.7只允许每个容器使用一个卷驱动，并且无法给卷传递参数）。
|
||||
|
||||
另一方面，Kubernetes 中的卷有明确的寿命——与封装它的 Pod 相同。所以，卷的生命比 Pod 中的所有容器都长，当这个容器重启时数据仍然得以保存。当然，当 Pod 不再存在时，卷也将不复存在。也许更重要的是，Kubernetes 支持多种类型的卷，Pod 可以同时使用任意数量的卷。
|
||||
另一方面，Kubernetes 中的卷有明确的寿命——与封装它的 Pod 相同。所f以，卷的生命比 Pod 中的所有容器都长，当这个容器重启时数据仍然得以保存。当然，当 Pod 不再存在时，卷也将不复存在。也许更重要的是，Kubernetes 支持多种类型的卷，Pod 可以同时使用任意数量的卷。
|
||||
|
||||
卷的核心是目录，可能还包含了一些数据，可以通过 pod 中的容器来访问。该目录是如何形成的、支持该目录的介质以及其内容取决于所使用的特定卷类型。
|
||||
|
||||
|
|
@ -107,8 +107,6 @@ spec:
|
|||
|
||||
**重要提示**：您必须先拥有自己的 Ceph 服务器，然后才能使用它。
|
||||
|
||||
有关更多详细信息，请参见[CephFS示例](https://github.com/kubernetes/examples/tree/master/staging/volumes/cephfs/)。
|
||||
|
||||
### csi
|
||||
|
||||
CSI 代表[容器存储接口](https://github.com/container-storage-interface/spec/blob/master/spec.md)，CSI 试图建立一个行业标准接口的规范，借助 CSI 容器编排系统（CO）可以将任意存储系统暴露给自己的容器工作负载。有关详细信息，请查看[设计方案](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/container-storage-interface.md)。
|
||||
|
|
@ -253,8 +251,6 @@ spec:
|
|||
|
||||
**重要提示**：您必须先自行安装 GlusterFS，才能使用它。
|
||||
|
||||
有关更多详细信息，请参阅 [GlusterFS](https://github.com/kubernetes/examples/tree/master/staging/volumes/glusterfs) 示例。
|
||||
|
||||
### hostPath
|
||||
|
||||
`hostPath` 卷将主机节点的文件系统中的文件或目录挂载到集群中。该功能大多数 Pod 都用不到，但它为某些应用程序提供了一个强大的解决方法。
|
||||
|
|
@ -597,7 +593,7 @@ spec:
|
|||
|
||||
### vsphereVolume
|
||||
|
||||
**先决条件**：配置了 vSphere Cloud Provider 的 Kubernetes。有关云提供商的配置，请参阅 [vSphere 入门指南](https://kubernetes.io/docs/getting-started-guides/vsphere/)。
|
||||
**先决条件**：配置了 vSphere Cloud Provider 的 Kubernetes。有关云提供商的配置，请参阅 [vSphere 入门指南](https://vmware.github.io/vsphere-storage-for-kubernetes/documentation/)。
|
||||
|
||||
`vsphereVolume` 用于将 vSphere VMDK 卷挂载到 Pod 中。卷的内容在卸载时会被保留。支持 VMFS 和 VSAN 数据存储。
|
||||
|
||||
|
|
@ -689,8 +685,6 @@ spec:
|
|||
|
||||
`FlexVolume`使用户能够将供应商卷挂载到容器中。供应商插件是使用驱动程序实现的，该驱动程序支持由 `FlexVolume` API定义的一系列卷命令。驱动程序必须安装在每个节点的预定义卷插件路径中。
|
||||
|
||||
更多细节可以在[这里](https://github.com/kubernetes/community/blob/master/contributors/devel/flexvolume.md)找到。
|
||||
|
||||
## 挂载传播
|
||||
|
||||
**注意**：挂载传播是 Kubernetes 1.8 中的一个 alpha 特性，在将来的版本中可能会重新设计甚至删除。
|
||||
|
|
|
|||
|
|
@ -33,7 +33,7 @@
|
|||
在设置以下资源之前，请检查这是否属于您组织的集群管理员的责任。
|
||||
|
||||
- **Horizontal Pod Autoscaler (HPA)** ：这些资源是在CPU使用率或其他[自定义度量](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/custom-metrics-api.md)标准“秒杀”时自动化扩展应用程序的好方法。*[查看示例](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/)*以了解如何设置HPA。
|
||||
- **联合集群对象**：如果使用 *federation* 在多个 Kubernetes 集群上运行应用程序，则需要部署标准 Kubernetes API 对象的联合版本。有关参考，请查看设置 [联合 ConfigMap](https://kubernetes.io/docs/tasks/administer-federation/configmap/) 和[联合 Deployment](https://kubernetes.io/docs/tasks/administer-federation/deployment/) 的指南。
|
||||
- **联合集群对象**：如果使用 *federation* 在多个 Kubernetes 集群上运行应用程序，则需要部署标准 Kubernetes API 对象的联合版本。
|
||||
|
||||
## 扩展 Kubernetes API
|
||||
|
||||
|
|
|
|||
|
|
@ -16,7 +16,7 @@
|
|||
|
||||
代码如下：
|
||||
|
||||
```Go
|
||||
```go
|
||||
package main
|
||||
|
||||
import (
|
||||
|
|
@ -154,7 +154,7 @@ New image -> harbor-001.jimmysong.io/library/analytics-docker-test:Build_9
|
|||
|
||||
查看Deployment的event。
|
||||
|
||||
```Bash
|
||||
```bash
|
||||
$ kubectl describe deployment filebeat-test
|
||||
Name: filebeat-test
|
||||
Namespace: default
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@
|
|||
|
||||
## 安装依赖
|
||||
|
||||
```
|
||||
```bash
|
||||
brew install gnu-tar
|
||||
```
|
||||
|
||||
|
|
@ -18,16 +18,10 @@ Docker环境，至少需要给容器分配4G内存，在低于3G内存的时候
|
|||
|
||||
需要用的的docker镜像：
|
||||
|
||||
```
|
||||
```bash
|
||||
gcr.io/google_containers/kube-cross:v1.7.5-2
|
||||
```
|
||||
|
||||
我将该镜像备份到时速云上了，可供大家使用：
|
||||
|
||||
```
|
||||
index.tenxcloud.com/jimmy/kube-cross:v1.7.5-2
|
||||
```
|
||||
|
||||
该镜像基于Ubuntu构建，大小2.15G，编译环境中包含以下软件：
|
||||
|
||||
- Go1.7.5
|
||||
|
|
|
|||
|
|
@ -2,8 +2,6 @@
|
|||
|
||||
Kubebuilder 是一个基于 [CRD](../concepts/crd.md) 来构建 Kubernetes API 的框架，可以使用 CRD 来构建 API、Controller 和 Admission Webhook。
|
||||
|
||||
请参考 [Kubebuilder quick start](https://book.kubebuilder.io/quick_start.html) 来安装 kubebuilder。
|
||||
|
||||
## 动机
|
||||
|
||||
目前扩展 Kubernetes 的 API 的方式有创建 [CRD](../concepts/crd.md)、使用 [Operator](operator.md) SDK 等方式，都需要写很多的样本文件（boilerplate），使用起来十分麻烦。为了能够更方便构建 Kubernetes API 和工具，就需要一款能够事半功倍的工具，与其他 Kubernetes API 扩展方案相比，kubebuilder 更加简单易用，并获得了社区的广泛支持。
|
||||
|
|
@ -30,5 +28,4 @@ Kubebuilder 提供基于简洁的精心设计的示例 godoc 来提供整洁的
|
|||
|
||||
## 参考
|
||||
|
||||
- [Kubebuilder quick start - book.kubebuilder.io](https://book.kubebuilder.io/quick_start.html)
|
||||
- [kubebuilder - github.com](https://github.com/kubernetes-sigs/kubebuilder/)
|
||||
|
|
@ -8,23 +8,41 @@ Operator是将运维人员对软件操作的知识给代码化，同时利用Kub
|
|||
|
||||
Operator使用了Kubernetes的自定义资源扩展API机制，如使用[CRD](../concepts/custom-resource.md)（CustomResourceDefinition）来创建。Operator通过这种机制来创建、配置和管理应用程序。
|
||||
|
||||
当前CoreOS提供的以下四种Operator：
|
||||
|
||||
- [etcd](https://coreos.com/operators/etcd/docs/latest/)：创建etcd集群
|
||||
- [Rook](https://github.com/rook/rook)：云原生环境下的文件、块、对象存储服务
|
||||
- [Prometheus](https://coreos.com/operators/prometheus/docs/latest/)：创建Prometheus监控实例
|
||||
- [Tectonic](https://coreos.com/tectonic/)：部署Kubernetes集群
|
||||
|
||||
以上为CoreOS官方提供的Operator，另外还有很多很多其他开源的Operator实现。
|
||||
当前CoreOS依靠社区力量创建了众多的 Operator，见：<https://operatorhub.io/>。
|
||||
|
||||
Operator基于Kubernetes的以下两个概念构建：
|
||||
|
||||
- 资源：对象的状态定义
|
||||
- 控制器：观测、分析和行动，以调节资源的分布
|
||||
|
||||
## Operator 用途
|
||||
|
||||
若您有以下需求，可能会需要用到 Operator：
|
||||
|
||||
- 按需部署一个应用程序
|
||||
- 需要备份和恢复应用程序的状态（如数据库）
|
||||
- 处理应用程序代码的升级以及相关更改，例如数据库架构或额外的配置设置
|
||||
- 发布一个服务，要让不支持Kubernetes API的应用程序能够发现
|
||||
- 模拟整个或部分集群中的故障以测试其弹性
|
||||
- 在没有内部成员选举程序的情况下为分布式应用程序选择领导者
|
||||
|
||||
## 一个Operator用途的详细示例
|
||||
|
||||
下面是一个使用 Operator 的详细示例。
|
||||
|
||||
- 一个名为SampleDB的自定义资源，您可以将其配置到集群中。
|
||||
- 确保正在运行的Deployment的Pod中包含Operator的控制器部分。
|
||||
- Operator代码的容器镜像。
|
||||
- 查询控制平面以找出配置了哪些SampleDB资源的控制器代码。
|
||||
- Operator的核心是告诉API Server如何使现实与代码里已配置的资源匹配。
|
||||
- 如果添加新的SampleDB，Operator将设置PersistentVolumeClaims以提供持久的数据库存储，设置StatefulSet以运行SampleDB，并设置Job来处理初始配置。
|
||||
- 如果删除它，Operator将建立快照，然后确保删除了StatefulSet和卷。
|
||||
- Operator还管理常规数据库备份。对于每个SampleDB资源，Operator确定何时创建可以连接到数据库并进行备份的Pod。这些Pod将依赖于ConfigMap和/或具有数据库连接详细信息和凭据的Secret。
|
||||
- 由于Operator旨在为其管理的资源提供强大的自动化功能，因此会有其他支持代码。对于此示例，代码将检查数据库是否正在运行旧版本，如果是，则创建Job对象为您升级数据库。
|
||||
|
||||
## 创建Operator
|
||||
|
||||
Operator本质上是与应用息息相关的，因为这是特定领域的知识的编码结果，这其中包括了资源配置的控制逻辑。下面是创建Operator的基本套路：
|
||||
Operator本质上是与应用息息相关的，因为这是特定领域的知识的编码结果，这其中包括了资源配置的控制逻辑。下面是创建Operator的基本步骤：
|
||||
|
||||
1. 在单个Deployment中定义Operator，如：https://coreos.com/operators/etcd/latest/deployment.yaml
|
||||
2. 需要为Operator创建一个新的自定义类型[CRD](../concepts/custom-resource.md)，这样用户就可以使用该对象来创建实例
|
||||
|
|
@ -34,9 +52,18 @@ Operator本质上是与应用息息相关的，因为这是特定领域的知识
|
|||
6. Operator应该让用户能够根据版本声明来选择所需版本和编排应用程序升级。不升级软件是操作错误和安全问题的常见来源，Operator可以帮助用户更加自信地解决这一问题。
|
||||
7. Operator应该进行“Chaos Monkey”测试，以模拟Pod、配置和网络故障的情况下的行为。
|
||||
|
||||
## OperatorHub
|
||||
|
||||
我们都知道在 Kubernetes 上安装应用可以使用 Helm 直接安装各种打包成 Chart 形式的 Kubernetes 应用，但随着 Kubernetes Operator 的流行，Kubernetes 社区又推出了 [OperatorHub](https://www.operatorhub.io/)，你可以在这里分享或安装 Operator：<https://www.operatorhub.io>。
|
||||
|
||||
另外，[awesome-operators](https://github.com/operator-framework/awesome-operators) 中罗列了目前已知的 Operator。
|
||||
|
||||
## 参考
|
||||
|
||||
- [Operators - coreos.com](https://coreos.com/operators)
|
||||
- [awesome-operators - github.com](https://github.com/operator-framework/awesome-operators)
|
||||
- [OperatorHub - operatorhub.io](https://www.operatorhub.io)
|
||||
- [Writing a Kubernetes Operator in Golang](https://medium.com/@mtreacher/writing-a-kubernetes-operator-a9b86f19bfb9)
|
||||
- [Introducing Operators: Putting Operational Knowledge into Software](https://coreos.com/blog/introducing-operators.html)
|
||||
- [Automating Kubernetes Cluster Operations with Operators](https://thenewstack.io/automating-kubernetes-cluster-operations-operators/)
|
||||
- [Introducing Operators: Putting Operational Knowledge into Software - coreos.com](https://coreos.com/blog/introducing-operators.html)
|
||||
- [Automating Kubernetes Cluster Operations with Operators - thenewstack.io](https://thenewstack.io/automating-kubernetes-cluster-operations-operators/)
|
||||
- [Operator pattern - kubernetes.io](https://kubernetes.io/docs/concepts/extend-kubernetes/operator)
|
||||
|
|
|
|||
|
|
@ -199,8 +199,4 @@ kubectl get pods nginx-4263166205-ggst4 -o template '--template={{if (exists . "
|
|||
|
||||
## 参考文档
|
||||
|
||||
* [Kubernetes testing](https://github.com/kubernetes/community/blob/master/contributors/devel/testing.md)
|
||||
* [End-to-End Testing](https://github.com/kubernetes/community/blob/master/contributors/devel/e2e-tests.md)
|
||||
* [Node e2e test](https://github.com/kubernetes/community/blob/master/contributors/devel/e2e-node-tests.md)
|
||||
* [How to write e2e test](https://github.com/kubernetes/community/blob/master/contributors/devel/writing-good-e2e-tests.md)
|
||||
* https://github.com/kubernetes/test-infra
|
||||
|
|
|
|||
|
|
@ -288,5 +288,4 @@ rm -rf .vagrant
|
|||
- [Kubernetes handbook - jimmysong.io](https://jimmysong.io/kubernetes-handbook)
|
||||
- [duffqiu/centos-vagrant](https://github.com/duffqiu/centos-vagrant)
|
||||
- [kubernetes-vagrant-centos-cluster](https://github.com/rootsongjc/kubernetes-vagrant-centos-cluster)
|
||||
- [vagrant网络配置](https://blog.hedzr.com/2017/05/02/vagrant-%E7%BD%91%E7%BB%9C%E9%85%8D%E7%BD%AE/)
|
||||
- [Kubernetes 1.8 kube-proxy 开启 ipvs](https://mritd.me/2017/10/10/kube-proxy-use-ipvs-on-kubernetes-1.8/#%E4%B8%80%E7%8E%AF%E5%A2%83%E5%87%86%E5%A4%87)
|
||||
|
|
@ -1,10 +1,10 @@
|
|||
## 访问集群
|
||||
# 访问集群
|
||||
|
||||
### 第一次使用 kubectl 访问
|
||||
## 第一次使用 kubectl 访问
|
||||
|
||||
如果您是第一次访问 Kubernetes API 的话，我们建议您使用 Kubernetes 命令行工具：`kubectl`。
|
||||
|
||||
为了访问集群，您需要知道集群的地址，并且需要有访问它的凭证。通常，如果您完成了 [入门指南](https://kubernetes.io/docs/getting-started-guides) 那么这些将会自动设置，或者其他人为您部署的集群提供并给您凭证和集群地址。
|
||||
为了访问集群，您需要知道集群的地址，并且需要有访问它的凭证。通常，如果您完成了入门指南那么这些将会自动设置，或者其他人为您部署的集群提供并给您凭证和集群地址。
|
||||
|
||||
使用下面的命令检查 kubectl 已知的集群的地址和凭证：
|
||||
|
||||
|
|
@ -12,7 +12,7 @@
|
|||
$ kubectl config view
|
||||
```
|
||||
|
||||
### 直接访问 REST API
|
||||
## 直接访问 REST API
|
||||
|
||||
Kubectl 处理对 apiserver 的定位和认证。如果您想直接访问 REST API，可以使用像 curl、wget 或浏览器这样的 http 客户端，有以下几种方式来定位和认证：
|
||||
|
||||
|
|
@ -27,7 +27,7 @@ Kubectl 处理对 apiserver 的定位和认证。如果您想直接访问 REST A
|
|||
- 适用于通过使用代理而混淆的某些类型的客户端代码。
|
||||
- 需要将根证书导入浏览器以防止 MITM。
|
||||
|
||||
#### 使用 kubectl proxy
|
||||
### 使用 kubectl proxy
|
||||
|
||||
以下命令作为反向代理的模式运行 kubectl。 它处理对 apiserver 的定位并进行认证。
|
||||
|
||||
|
|
@ -48,7 +48,7 @@ $ curl http://localhost:8080/api/
|
|||
}
|
||||
```
|
||||
|
||||
#### 不使用 kubectl proxy（1.3.x 以前版本）
|
||||
### 不使用 kubectl proxy（1.3.x 以前版本）
|
||||
|
||||
通过将认证 token 直接传递给 apiserver 的方式，可以避免使用 kubectl proxy，如下所示：
|
||||
|
||||
|
|
@ -63,7 +63,7 @@ $ curl $APISERVER/api --header "Authorization: Bearer $TOKEN" --insecure
|
|||
}
|
||||
```
|
||||
|
||||
#### 不使用 kubectl proxy（1.3.x 以后版本）
|
||||
### 不使用 kubectl proxy（1.3.x 以后版本）
|
||||
|
||||
在 Kubernetes 1.3 或更高版本中，`kubectl config view` 不再显示 token。 使用 `kubectl describe secret …` 获取 default service account 的 token，如下所示：
|
||||
|
||||
|
|
@ -89,11 +89,11 @@ $ curl $APISERVER/api --header "Authorization: Bearer $TOKEN" --insecure
|
|||
|
||||
对于某些群集，apiserver 可能不需要身份验证；可以选择在本地主机上服务，或者使用防火墙保护。 对此还没有一个标准。[配置对API的访问](https://kubernetes.io/docs/admin/accessing-the-api) 描述了群集管理员如何配置此操作。 这种方法可能与未来的高可用性支持相冲突。
|
||||
|
||||
### 编程访问 API
|
||||
## 编程访问 API
|
||||
|
||||
Kubernetes 支持 [Go](https://kubernetes.io/docs/tasks/access-application-cluster/access-cluster.md#go-client) 和 [Python](https://kubernetes.io/docs/tasks/access-application-cluster/access-cluster.md#python-client) 客户端库。
|
||||
|
||||
#### Go 客户端
|
||||
### Go 客户端
|
||||
|
||||
- 要获取该库，请运行以下命令：`go get k8s.io/client-go/<version number>/kubernetes` 请参阅 [https://github.com/kubernetes/client-go](https://github.com/kubernetes/client-go) 以查看支持哪些版本。
|
||||
- 使用 client-go 客户端编程。请注意，client-go 定义了自己的 API 对象，因此如果需要，请从 client-go 而不是从主存储库导入 API 定义，例如导入 `k8s.io/client-go/1.4/pkg/api/v1` 是正确的。
|
||||
|
|
@ -102,17 +102,17 @@ Go 客户端可以使用与 kubectl 命令行工具相同的 [kubeconfig 文件]
|
|||
|
||||
如果应用程序在群集中以 Pod 的形式部署，请参考 [下一节](https://kubernetes.io/docs/tasks/access-application-cluster/access-cluster.md#accessing-the-api-from-a-pod)。
|
||||
|
||||
#### Python 客户端
|
||||
### Python 客户端
|
||||
|
||||
要使用 [Python client](https://github.com/kubernetes-incubator/client-python)，请运行以下命令：`pip install kubernetes`。查看 [Python 客户端库页面](https://github.com/kubernetes-incubator/client-python) 获取更多的安装选择。
|
||||
|
||||
Python 客户端可以使用与 kubectl 命令行工具相同的 [kubeconfig 文件](https://kubernetes.io/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig) 来定位和验证 apiserver。参考该 [示例](https://github.com/kubernetes-incubator/client-python/tree/master/examples/example1.py)。
|
||||
Python 客户端可以使用与 kubectl 命令行工具相同的 [kubeconfig 文件](https://kubernetes.io/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig) 来定位和验证 apiserver。
|
||||
|
||||
#### 其他语言
|
||||
### 其他语言
|
||||
|
||||
还有更多的 [客户端库](https://git.k8s.io/community/contributors/devel/client-libraries.md) 可以用来访问 API。有关其他库的验证方式，请参阅文档。
|
||||
还有更多的客户端库可以用来访问 API。有关其他库的验证方式，请参阅文档。
|
||||
|
||||
### 在 Pod 中访问 API
|
||||
## 在 Pod 中访问 API
|
||||
|
||||
在 Pod 中访问 API 时，定位和认证到 API server 的方式有所不同。在 Pod 中找到 apiserver 地址的推荐方法是使用kubernetes DNS 名称，将它解析为服务 IP，后者又将被路由到 apiserver。
|
||||
|
||||
|
|
@ -183,7 +183,7 @@ $ kubectl cluster-info
|
|||
|
||||
如果您没有指定 port 的名字，那么您不必在 URL 里指定 port_name。
|
||||
|
||||
##### 示例
|
||||
#### 示例
|
||||
|
||||
- 要想访问 Elasticsearch 的服务端点 `_search?q=user:kimchy`，您需要使用：`http://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/_search?q=user:kimchy`
|
||||
- 要想访问 Elasticsearch 的集群健康信息 `_cluster/health?pretty=true`，您需要使用：`https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/_cluster/health?pretty=true`
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
# 从外部访问Kubernetes中的Pod
|
||||
|
||||
前面几节讲到如何访问kubneretes集群，本文主要讲解访问kubenretes中的Pod和Serivce的集中方式，包括如下几种：
|
||||
前面几节讲到如何访问kubneretes集群，本文主要讲解访问kubenretes中的Pod和Serivce的几种方式，包括如下几种：
|
||||
|
||||
- hostNetwork
|
||||
- hostPort
|
||||
|
|
|
|||
|
|
@ -266,7 +266,7 @@ users:
|
|||
|
||||
#### 示例文件相关操作命令
|
||||
|
||||
```Bash
|
||||
```bash
|
||||
$ kubectl config set preferences.colors true
|
||||
$ kubectl config set-cluster cow-cluster --server=http://cow.org:8080 --api-version=v1
|
||||
$ kubectl config set-cluster horse-cluster --server=https://horse.org:4443 --certificate-authority=path/to/my/cafile
|
||||
|
|
|
|||
|
|
@ -1,8 +1,8 @@
|
|||
# 配置Pod的liveness和readiness探针
|
||||
|
||||
当你使用kuberentes的时候，有没有遇到过Pod在启动后一会就挂掉然后又重新启动这样的恶性循环？你有没有想过kubernetes是如何检测pod是否还存活？虽然容器已经启动，但是kubernetes如何知道容器的进程是否准备好对外提供服务了呢？让我们通过kuberentes官网的这篇文章[Configure Liveness and Readiness Probes](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/)，来一探究竟。
|
||||
当你使用kubernetes的时候，有没有遇到过Pod在启动后一会就挂掉然后又重新启动这样的恶性循环？你有没有想过kubernetes是如何检测pod是否还存活？虽然容器已经启动，但是kubernetes如何知道容器的进程是否准备好对外提供服务了呢？让我们通过kubernetes官网的这篇文章[Configure Liveness and Readiness Probes](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/)，来一探究竟。
|
||||
|
||||
本文将向展示如何配置容器的存活和可读性探针。
|
||||
本文将展示如何配置容器的存活和可读性探针。
|
||||
|
||||
Kubelet使用liveness probe（存活探针）来确定何时重启容器。例如，当应用程序处于运行状态但无法做进一步操作，liveness探针将捕获到deadlock，重启处于该状态下的容器，使应用程序在存在bug的情况下依然能够继续运行下去（谁的程序还没几个bug呢）。
|
||||
|
||||
|
|
@ -132,12 +132,10 @@ spec:
|
|||
periodSeconds: 3
|
||||
```
|
||||
|
||||
该配置文件只定义了一个容器，`livenessProbe` 指定kubelete需要每隔3秒执行一次liveness probe。`initialDelaySeconds` 指定kubelet在该执行第一次探测之前需要等待3秒钟。该探针将向容器中的server的8080端口发送一个HTTP GET请求。如果server的`/healthz`路径的handler返回一个成功的返回码，kubelet就会认定该容器是活着的并且很健康。如果返回失败的返回码，kubelet将杀掉该容器并重启它。
|
||||
该配置文件只定义了一个容器，`livenessProbe` 指定kubelet需要每隔3秒执行一次liveness probe。`initialDelaySeconds` 指定kubelet在该执行第一次探测之前需要等待3秒钟。该探针将向容器中的server的8080端口发送一个HTTP GET请求。如果server的`/healthz`路径的handler返回一个成功的返回码，kubelet就会认定该容器是活着的并且很健康。如果返回失败的返回码，kubelet将杀掉该容器并重启它。
|
||||
|
||||
任何大于200小于400的返回码都会认定是成功的返回码。其他返回码都会被认为是失败的返回码。
|
||||
|
||||
查看该server的源码：[server.go](https://github.com/kubernetes/kubernetes/blob/master/test/images/liveness/server.go).
|
||||
|
||||
最开始的10秒该容器是活着的， `/healthz` handler返回200的状态码。这之后将返回500的返回码。
|
||||
|
||||
```go
|
||||
|
|
|
|||
|
|
@ -4,13 +4,13 @@ Service account 为 Pod 中的进程提供身份信息。
|
|||
|
||||
*本文是关于 Service Account 的用户指南，管理指南另见 Service Account 的集群管理指南 。*
|
||||
|
||||
*注意：本文档描述的关于 Serivce Account 的行为只有当您按照 Kubernetes 项目建议的方式搭建起集群的情况下才有效。您的集群管理员可能在您的集群中有自定义配置，这种情况下该文档可能并不适用。*
|
||||
*注意：本文档描述的关于 Service Account 的行为只有当您按照 Kubernetes 项目建议的方式搭建起集群的情况下才有效。您的集群管理员可能在您的集群中有自定义配置，这种情况下该文档可能并不适用。*
|
||||
|
||||
当您（真人用户）访问集群（例如使用`kubectl`命令）时，apiserver 会将您认证为一个特定的 User Account（目前通常是`admin`，除非您的系统管理员自定义了集群配置）。Pod 容器中的进程也可以与 apiserver 联系。 当它们在联系 apiserver 的时候，它们会被认证为一个特定的 Service Account（例如`default`）。
|
||||
|
||||
## 使用默认的 Service Account 访问 API server
|
||||
|
||||
当您创建 pod 的时候，如果您没有指定一个 service account，系统会自动得在与该pod 相同的 namespace 下为其指派一个`default` service account。如果您获取刚创建的 pod 的原始 json 或 yaml 信息（例如使用`kubectl get pods/podename -o yaml`命令），您将看到`spec.serviceAccountName`字段已经被设置为 [automatically set](https://kubernetes.io/docs/user-guide/working-with-resources/#resources-are-automatically-modified) 。
|
||||
当您创建 pod 的时候，如果您没有指定一个 service account，系统会自动得在与该pod 相同的 namespace 下为其指派一个`default` service account。如果您获取刚创建的 pod 的原始 json 或 yaml 信息（例如使用`kubectl get pods/podename -o yaml`命令），您将看到`spec.serviceAccountName`字段已经被设置为 automatically 。
|
||||
|
||||
您可以在 pod 中使用自动挂载的 service account 凭证来访问 API，如 [Accessing the Cluster](https://kubernetes.io/docs/user-guide/accessing-the-cluster/#accessing-the-api-from-a-pod) 中所描述。
|
||||
|
||||
|
|
@ -271,7 +271,7 @@ namespace: 7 bytes
|
|||
|
||||
然后，确认已创建。如：
|
||||
|
||||
```Bash
|
||||
```bash
|
||||
$ kubectl get secrets myregistrykey
|
||||
NAME TYPE DATA AGE
|
||||
myregistrykey kubernetes.io/.dockerconfigjson 1 1d
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
# docker用户过度到kubectl命令行指南
|
||||
# docker用户过渡到kubectl命令行指南
|
||||
|
||||
对于没有使用过 kubernetes 的 docker 用户，如何快速掌握 kubectl 命令？
|
||||
|
||||
|
|
@ -257,7 +257,7 @@ WARNING: No swap limit support
|
|||
|
||||
使用 kubectl 命令：
|
||||
|
||||
```Bash
|
||||
```bash
|
||||
$ kubectl cluster-info
|
||||
Kubernetes master is running at https://108.59.85.141
|
||||
KubeDNS is running at https://108.59.85.141/api/v1/namespaces/kube-system/services/kube-dns/proxy
|
||||
|
|
|
|||
|
|
@ -276,7 +276,7 @@ $ kubectl taint nodes foo dedicated=special-user:NoSchedule
|
|||
|
||||
### Kubectl 详细输出和调试
|
||||
|
||||
使用 `-v` 或 `--v` 标志跟着一个整数来指定日志级别。[这里](https://github.com/kubernetes/community/blob/master/contributors/devel/logging.md) 描述了通用的 kubernetes 日志约定和相关的日志级别。
|
||||
使用 `-v` 或 `--v` 标志跟着一个整数来指定日志级别。
|
||||
|
||||
| 详细等级 | 描述 |
|
||||
| ------- | ---------------------------------------- |
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@
|
|||
|
||||
## 概览
|
||||
|
||||
每个Kubernetes集群都有一个集群根证书颁发机构（CA）。 集群中的组件通常使用CA来验证API server的证书，由API服务器验证kubelet客户端证书等。为了支持这一点，CA证书包被分发到集群中的每个节点，并作为一个sercret附加分发到默认service account上。 或者，你的workload可以使用此CA建立信任。 你的应用程序可以使用类似于[ACME草案](https://github.com/ietf-wg-acme/acme/)的协议，使用`certificates.k8s.io` API请求证书签名。
|
||||
每个Kubernetes集群都有一个集群根证书颁发机构（CA）。 集群中的组件通常使用CA来验证API server的证书，由API服务器验证kubelet客户端证书等。为了支持这一点，CA证书包被分发到集群中的每个节点，并作为一个secret附加分发到默认service account上。 或者，你的workload可以使用此CA建立信任。 你的应用程序可以使用类似于[ACME草案](https://github.com/ietf-wg-acme/acme/)的协议，使用`certificates.k8s.io` API请求证书签名。
|
||||
|
||||
## 集群中的TLS信任
|
||||
|
||||
|
|
@ -22,7 +22,7 @@
|
|||
|
||||
通过运行以下命令生成私钥和证书签名请求（或CSR）：
|
||||
|
||||
```Bash
|
||||
```bash
|
||||
$ cat <<EOF | cfssl genkey - | cfssljson -bare server
|
||||
{
|
||||
"hosts": [
|
||||
|
|
@ -42,7 +42,7 @@ EOF
|
|||
|
||||
`172.168.0.24` 是 service 的 cluster IP，`my-svc.my-namespace.svc.cluster.local` 是 service 的 DNS 名称， `10.0.34.2` 是 Pod 的 IP， `my-pod.my-namespace.pod.cluster.local` 是pod 的 DNS 名称，你可以看到以下输出：
|
||||
|
||||
```
|
||||
```ini
|
||||
2017/03/21 06:48:17 [INFO] generate received request
|
||||
2017/03/21 06:48:17 [INFO] received CSR
|
||||
2017/03/21 06:48:17 [INFO] generating key: ecdsa-256
|
||||
|
|
|
|||
|
|
@ -27,7 +27,7 @@
|
|||
|
||||
3. 显示 ReplicaSet 的信息：
|
||||
|
||||
```
|
||||
```bash
|
||||
kubectl get replicasets
|
||||
kubectl describe replicasets
|
||||
|
||||
|
|
@ -35,7 +35,7 @@
|
|||
|
||||
4. 创建一个暴露该 Deployment 的 Service 对象：
|
||||
|
||||
```Bash
|
||||
```bash
|
||||
kubectl expose deployment hello-world --type=NodePort --name=example-service
|
||||
```
|
||||
|
||||
|
|
@ -101,13 +101,13 @@
|
|||
|
||||
要删除 Service，输入以下命令：
|
||||
|
||||
```
|
||||
```bash
|
||||
kubectl delete services example-service
|
||||
```
|
||||
|
||||
删除 Deployment、ReplicaSet 和正运行在 Pod 中的 Hello World 应用程序，输入以下命令：
|
||||
|
||||
```
|
||||
```bash
|
||||
kubectl delete deployment hello-world
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -21,9 +21,11 @@ Token 可以是任意的，但应该可以表示为从安全随机数生成器
|
|||
Token 文件应该类似于以下示例，其中前三个值可以是任何值，引用的组名称应如下所示：
|
||||
|
||||
```bash
|
||||
02b50b05283e98dd0fd71db496ef01e8,kubelet-bootstrap,10001,"system:kubelet-bootstrap"
|
||||
02b50b05283e98dd0fd71db496ef01e8,kubelet-bootstrap,10001,system:kubelet-bootstrap
|
||||
```
|
||||
|
||||
注意：`system:kubelet-bootstrap` 的配置，当只有一个组时，不需要加引号。
|
||||
|
||||
在 kube-apiserver 命令中添加 `--token-auth-file=FILENAME` 标志（可能在您的 systemd unit 文件中）来启用 token 文件。
|
||||
|
||||
查看 [该文档](https://kubernetes.io/docs/admin/authentication/#static-token-file) 获取更多详细信息。
|
||||
|
|
|
|||
|
|
@ -324,4 +324,3 @@ spec:
|
|||
|
||||
- https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/
|
||||
- [kubernetes contrib - statefulsets](https://github.com/kubernetes/contrib/tree/master/statefulsets)
|
||||
- http://blog.kubernetes.io/2017/01/running-mongodb-on-kubernetes-with-statefulsets.html
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 297 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 269 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 167 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 75 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 474 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 73 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 291 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 172 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 537 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 232 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 436 KiB |
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue