diff --git a/umn/source/_static/images/en-us_image_0000001168997466.png b/umn/source/_static/images/en-us_image_0000001168997466.png new file mode 100644 index 0000000..8d3ac2a Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001168997466.png differ diff --git a/umn/source/_static/images/en-us_image_0000001169315996.gif b/umn/source/_static/images/en-us_image_0000001169315996.gif new file mode 100644 index 0000000..3ced28e Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001169315996.gif differ diff --git a/umn/source/_static/images/en-us_image_0000001169475948.png b/umn/source/_static/images/en-us_image_0000001169475948.png new file mode 100644 index 0000000..1a7c01e Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001169475948.png differ diff --git a/umn/source/_static/images/en-us_image_0000001178352608.png b/umn/source/_static/images/en-us_image_0000001178352608.png deleted file mode 100644 index 505b820..0000000 Binary files a/umn/source/_static/images/en-us_image_0000001178352608.png and /dev/null differ diff --git a/umn/source/_static/images/en-us_image_0000001214475863.gif b/umn/source/_static/images/en-us_image_0000001214475863.gif new file mode 100644 index 0000000..7086a09 Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001214475863.gif differ diff --git a/umn/source/_static/images/en-us_image_0000001214635805.png b/umn/source/_static/images/en-us_image_0000001214635805.png new file mode 100644 index 0000000..00ccbf1 Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001214635805.png differ diff --git a/umn/source/_static/images/en-us_image_0000001214717329.gif b/umn/source/_static/images/en-us_image_0000001214717329.gif new file mode 100644 index 0000000..c8fba92 Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001214717329.gif differ diff --git a/umn/source/_static/images/en-us_image_0000001221820189.png b/umn/source/_static/images/en-us_image_0000001221820189.png deleted file mode 100644 index 2af028b..0000000 Binary files a/umn/source/_static/images/en-us_image_0000001221820189.png and /dev/null differ diff --git a/umn/source/_static/images/en-us_image_0000001244128658.png b/umn/source/_static/images/en-us_image_0000001244128658.png new file mode 100644 index 0000000..e456965 Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001244128658.png differ diff --git a/umn/source/_static/images/en-us_image_0000001287883210.png b/umn/source/_static/images/en-us_image_0000001287883210.png deleted file mode 100644 index 2b5990a..0000000 Binary files a/umn/source/_static/images/en-us_image_0000001287883210.png and /dev/null differ diff --git a/umn/source/_static/images/en-us_image_0000001336475537.png b/umn/source/_static/images/en-us_image_0000001336475537.png deleted file mode 100644 index 21a8c0a..0000000 Binary files a/umn/source/_static/images/en-us_image_0000001336475537.png and /dev/null differ diff --git a/umn/source/_static/images/en-us_image_0000001340138373.png b/umn/source/_static/images/en-us_image_0000001340138373.png deleted file mode 100644 index 3b8d9e3..0000000 Binary files a/umn/source/_static/images/en-us_image_0000001340138373.png and /dev/null differ diff --git a/umn/source/_static/images/en-us_image_0000001352090724.png b/umn/source/_static/images/en-us_image_0000001352090724.png new file mode 100644 index 0000000..5333b49 Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001352090724.png differ diff --git a/umn/source/_static/images/en-us_image_0000001352253356.png b/umn/source/_static/images/en-us_image_0000001352253356.png new file mode 100644 index 0000000..424c226 Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001352253356.png differ diff --git a/umn/source/_static/images/en-us_image_0000001352413288.png b/umn/source/_static/images/en-us_image_0000001352413288.png new file mode 100644 index 0000000..7668968 Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001352413288.png differ diff --git a/umn/source/_static/images/en-us_image_0000001352573116.png b/umn/source/_static/images/en-us_image_0000001352573116.png new file mode 100644 index 0000000..bc44aa3 Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001352573116.png differ diff --git a/umn/source/_static/images/en-us_image_0000001402893085.png b/umn/source/_static/images/en-us_image_0000001402893085.png new file mode 100644 index 0000000..8133e72 Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001402893085.png differ diff --git a/umn/source/_static/images/en-us_image_0000001403252957.png b/umn/source/_static/images/en-us_image_0000001403252957.png new file mode 100644 index 0000000..191dafd Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001403252957.png differ diff --git a/umn/source/_static/images/en-us_image_0000001499246158.png b/umn/source/_static/images/en-us_image_0000001499246158.png new file mode 100644 index 0000000..36d4cf8 Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001499246158.png differ diff --git a/umn/source/_static/images/en-us_image_0000001499406022.png b/umn/source/_static/images/en-us_image_0000001499406022.png new file mode 100644 index 0000000..49d22c1 Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001499406022.png differ diff --git a/umn/source/_static/images/en-us_image_0000001499406030.png b/umn/source/_static/images/en-us_image_0000001499406030.png new file mode 100644 index 0000000..c3b27f9 Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001499406030.png differ diff --git a/umn/source/_static/images/en-us_image_0000001499565914.png b/umn/source/_static/images/en-us_image_0000001499565914.png new file mode 100644 index 0000000..ce0d9e1 Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001499565914.png differ diff --git a/umn/source/_static/images/en-us_image_0000001499565934.png b/umn/source/_static/images/en-us_image_0000001499565934.png new file mode 100644 index 0000000..3acce98 Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001499565934.png differ diff --git a/umn/source/_static/images/en-us_image_0000001499598344.png b/umn/source/_static/images/en-us_image_0000001499598344.png new file mode 100644 index 0000000..1b65f72 Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001499598344.png differ diff --git a/umn/source/_static/images/en-us_image_0000001499725850.png b/umn/source/_static/images/en-us_image_0000001499725850.png new file mode 100644 index 0000000..4b7cdaf Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001499725850.png differ diff --git a/umn/source/_static/images/en-us_image_0000001499758236.png b/umn/source/_static/images/en-us_image_0000001499758236.png new file mode 100644 index 0000000..1b65f72 Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001499758236.png differ diff --git a/umn/source/_static/images/en-us_image_0000001244997085.png b/umn/source/_static/images/en-us_image_0000001499758244.png similarity index 100% rename from umn/source/_static/images/en-us_image_0000001244997085.png rename to umn/source/_static/images/en-us_image_0000001499758244.png diff --git a/umn/source/_static/images/en-us_image_0000001499760912.png b/umn/source/_static/images/en-us_image_0000001499760912.png new file mode 100644 index 0000000..7428f0e Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001499760912.png differ diff --git a/umn/source/_static/images/en-us_image_0000001504661902.png b/umn/source/_static/images/en-us_image_0000001504661902.png new file mode 100644 index 0000000..f1ae631 Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001504661902.png differ diff --git a/umn/source/_static/images/en-us_image_0000001504821802.png b/umn/source/_static/images/en-us_image_0000001504821802.png new file mode 100644 index 0000000..4c012a5 Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001504821802.png differ diff --git a/umn/source/_static/images/en-us_image_0000001244101121.png b/umn/source/_static/images/en-us_image_0000001517743364.png similarity index 100% rename from umn/source/_static/images/en-us_image_0000001244101121.png rename to umn/source/_static/images/en-us_image_0000001517743364.png diff --git a/umn/source/_static/images/en-us_image_0000001244141139.png b/umn/source/_static/images/en-us_image_0000001517743372.png similarity index 100% rename from umn/source/_static/images/en-us_image_0000001244141139.png rename to umn/source/_static/images/en-us_image_0000001517743372.png diff --git a/umn/source/_static/images/en-us_image_0000001199501230.png b/umn/source/_static/images/en-us_image_0000001517743380.png similarity index 100% rename from umn/source/_static/images/en-us_image_0000001199501230.png rename to umn/source/_static/images/en-us_image_0000001517743380.png diff --git a/umn/source/_static/images/en-us_image_0000001199501262.png b/umn/source/_static/images/en-us_image_0000001517743384.png similarity index 100% rename from umn/source/_static/images/en-us_image_0000001199501262.png rename to umn/source/_static/images/en-us_image_0000001517743384.png diff --git a/umn/source/_static/images/en-us_image_0258889981.png b/umn/source/_static/images/en-us_image_0000001517743432.png similarity index 100% rename from umn/source/_static/images/en-us_image_0258889981.png rename to umn/source/_static/images/en-us_image_0000001517743432.png diff --git a/umn/source/_static/images/en-us_image_0000001212924318.png b/umn/source/_static/images/en-us_image_0000001517743452.png similarity index 100% rename from umn/source/_static/images/en-us_image_0000001212924318.png rename to umn/source/_static/images/en-us_image_0000001517743452.png diff --git a/umn/source/_static/images/en-us_image_0000001236562704.png b/umn/source/_static/images/en-us_image_0000001517743460.png similarity index 100% rename from umn/source/_static/images/en-us_image_0000001236562704.png rename to umn/source/_static/images/en-us_image_0000001517743460.png diff --git a/umn/source/_static/images/en-us_image_0000001244261103.png b/umn/source/_static/images/en-us_image_0000001517743464.png similarity index 100% rename from umn/source/_static/images/en-us_image_0000001244261103.png rename to umn/source/_static/images/en-us_image_0000001517743464.png diff --git a/umn/source/_static/images/en-us_image_0000001517743496.png b/umn/source/_static/images/en-us_image_0000001517743496.png new file mode 100644 index 0000000..8d6c69b Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001517743496.png differ diff --git a/umn/source/_static/images/en-us_image_0000001243981203.png b/umn/source/_static/images/en-us_image_0000001517743520.png similarity index 100% rename from umn/source/_static/images/en-us_image_0000001243981203.png rename to umn/source/_static/images/en-us_image_0000001517743520.png diff --git a/umn/source/_static/images/en-us_image_0000001249023453.png b/umn/source/_static/images/en-us_image_0000001517743540.png similarity index 100% rename from umn/source/_static/images/en-us_image_0000001249023453.png rename to umn/source/_static/images/en-us_image_0000001517743540.png diff --git a/umn/source/_static/images/en-us_image_0000001244261073.png b/umn/source/_static/images/en-us_image_0000001517743544.png similarity index 100% rename from umn/source/_static/images/en-us_image_0000001244261073.png rename to umn/source/_static/images/en-us_image_0000001517743544.png diff --git a/umn/source/_static/images/en-us_image_0000001199021334.png b/umn/source/_static/images/en-us_image_0000001517743552.png similarity index 100% rename from umn/source/_static/images/en-us_image_0000001199021334.png rename to umn/source/_static/images/en-us_image_0000001517743552.png diff --git a/umn/source/_static/images/en-us_image_0000001464878016.png b/umn/source/_static/images/en-us_image_0000001517743600.png similarity index 100% rename from umn/source/_static/images/en-us_image_0000001464878016.png rename to umn/source/_static/images/en-us_image_0000001517743600.png diff --git a/umn/source/_static/images/en-us_image_0258894622.png b/umn/source/_static/images/en-us_image_0000001517743624.png similarity index 100% rename from umn/source/_static/images/en-us_image_0258894622.png rename to umn/source/_static/images/en-us_image_0000001517743624.png diff --git a/umn/source/_static/images/en-us_image_0258203193.png b/umn/source/_static/images/en-us_image_0000001517743628.png similarity index 100% rename from umn/source/_static/images/en-us_image_0258203193.png rename to umn/source/_static/images/en-us_image_0000001517743628.png diff --git a/umn/source/_static/images/en-us_image_0000001244261071.png b/umn/source/_static/images/en-us_image_0000001517743636.png similarity index 100% rename from umn/source/_static/images/en-us_image_0000001244261071.png rename to umn/source/_static/images/en-us_image_0000001517743636.png diff --git a/umn/source/_static/images/en-us_image_0000001199341268.png b/umn/source/_static/images/en-us_image_0000001517743644.png similarity index 100% rename from umn/source/_static/images/en-us_image_0000001199341268.png rename to umn/source/_static/images/en-us_image_0000001517743644.png diff --git a/umn/source/_static/images/en-us_image_0275445543.png b/umn/source/_static/images/en-us_image_0000001517743652.png similarity index 100% rename from umn/source/_static/images/en-us_image_0275445543.png rename to umn/source/_static/images/en-us_image_0000001517743652.png diff --git a/umn/source/_static/images/en-us_image_0000001531373685.png b/umn/source/_static/images/en-us_image_0000001517743660.png similarity index 100% rename from umn/source/_static/images/en-us_image_0000001531373685.png rename to umn/source/_static/images/en-us_image_0000001517743660.png diff --git a/umn/source/_static/images/en-us_image_0000001244101223.png b/umn/source/_static/images/en-us_image_0000001517743672.png similarity index 100% rename from umn/source/_static/images/en-us_image_0000001244101223.png rename to umn/source/_static/images/en-us_image_0000001517743672.png diff --git a/umn/source/_static/images/en-us_image_0000001199021278.png b/umn/source/_static/images/en-us_image_0000001517902940.png similarity index 100% rename from umn/source/_static/images/en-us_image_0000001199021278.png rename to umn/source/_static/images/en-us_image_0000001517902940.png diff --git a/umn/source/_static/images/en-us_image_0258961458.png b/umn/source/_static/images/en-us_image_0000001517903016.png similarity index 100% rename from umn/source/_static/images/en-us_image_0258961458.png rename to umn/source/_static/images/en-us_image_0000001517903016.png diff --git a/umn/source/_static/images/en-us_image_0000001517903020.png b/umn/source/_static/images/en-us_image_0000001517903020.png new file mode 100644 index 0000000..6887683 Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001517903020.png differ diff --git a/umn/source/_static/images/en-us_image_0000001408895746.png b/umn/source/_static/images/en-us_image_0000001517903028.png similarity index 100% rename from umn/source/_static/images/en-us_image_0000001408895746.png rename to umn/source/_static/images/en-us_image_0000001517903028.png diff --git a/umn/source/_static/images/en-us_image_0000001517903036.png b/umn/source/_static/images/en-us_image_0000001517903036.png new file mode 100644 index 0000000..0bb483b Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001517903036.png differ diff --git a/umn/source/_static/images/en-us_image_0000001199757520.png b/umn/source/_static/images/en-us_image_0000001517903048.png similarity index 100% rename from umn/source/_static/images/en-us_image_0000001199757520.png rename to umn/source/_static/images/en-us_image_0000001517903048.png diff --git a/umn/source/_static/images/en-us_image_0000001517903056.png b/umn/source/_static/images/en-us_image_0000001517903056.png new file mode 100644 index 0000000..c301af9 Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001517903056.png differ diff --git a/umn/source/_static/images/en-us_image_0000001248663503.png b/umn/source/_static/images/en-us_image_0000001517903060.png similarity index 100% rename from umn/source/_static/images/en-us_image_0000001248663503.png rename to umn/source/_static/images/en-us_image_0000001517903060.png diff --git a/umn/source/_static/images/en-us_image_0000001251716033.png b/umn/source/_static/images/en-us_image_0000001517903064.png similarity index 100% rename from umn/source/_static/images/en-us_image_0000001251716033.png rename to umn/source/_static/images/en-us_image_0000001517903064.png diff --git a/umn/source/_static/images/en-us_image_0000001482546084.png b/umn/source/_static/images/en-us_image_0000001517903068.png similarity index 100% rename from umn/source/_static/images/en-us_image_0000001482546084.png rename to umn/source/_static/images/en-us_image_0000001517903068.png diff --git a/umn/source/_static/images/en-us_image_0000001199501276.png b/umn/source/_static/images/en-us_image_0000001517903088.png similarity index 100% rename from umn/source/_static/images/en-us_image_0000001199501276.png rename to umn/source/_static/images/en-us_image_0000001517903088.png diff --git a/umn/source/_static/images/en-us_image_0000001249073211.png b/umn/source/_static/images/en-us_image_0000001517903124.png similarity index 100% rename from umn/source/_static/images/en-us_image_0000001249073211.png rename to umn/source/_static/images/en-us_image_0000001517903124.png diff --git a/umn/source/_static/images/en-us_image_0000001517903128.png b/umn/source/_static/images/en-us_image_0000001517903128.png new file mode 100644 index 0000000..60b60d5 Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001517903128.png differ diff --git a/umn/source/_static/images/en-us_image_0000001465197524.png b/umn/source/_static/images/en-us_image_0000001517903168.png similarity index 100% rename from umn/source/_static/images/en-us_image_0000001465197524.png rename to umn/source/_static/images/en-us_image_0000001517903168.png diff --git a/umn/source/_static/images/en-us_image_0000001243981115.png b/umn/source/_static/images/en-us_image_0000001517903200.png similarity index 100% rename from umn/source/_static/images/en-us_image_0000001243981115.png rename to umn/source/_static/images/en-us_image_0000001517903200.png diff --git a/umn/source/_static/images/en-us_image_0000001531533045.png b/umn/source/_static/images/en-us_image_0000001517903240.png similarity index 100% rename from umn/source/_static/images/en-us_image_0000001531533045.png rename to umn/source/_static/images/en-us_image_0000001517903240.png diff --git a/umn/source/_static/images/en-us_image_0000001517903252.png b/umn/source/_static/images/en-us_image_0000001517903252.png new file mode 100644 index 0000000..2da6ba3 Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001517903252.png differ diff --git a/umn/source/_static/images/en-us_image_0000001325364477.png b/umn/source/_static/images/en-us_image_0000001518062492.png similarity index 100% rename from umn/source/_static/images/en-us_image_0000001325364477.png rename to umn/source/_static/images/en-us_image_0000001518062492.png diff --git a/umn/source/_static/images/en-us_image_0000001518062524.png b/umn/source/_static/images/en-us_image_0000001518062524.png new file mode 100644 index 0000000..65e1184 Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001518062524.png differ diff --git a/umn/source/_static/images/en-us_image_0000001518062540.png b/umn/source/_static/images/en-us_image_0000001518062540.png new file mode 100644 index 0000000..4cff8a7 Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001518062540.png differ diff --git a/umn/source/_static/images/en-us_image_0000001207511384.png b/umn/source/_static/images/en-us_image_0000001518062608.png similarity index 100% rename from umn/source/_static/images/en-us_image_0000001207511384.png rename to umn/source/_static/images/en-us_image_0000001518062608.png diff --git a/umn/source/_static/images/en-us_image_0000001203031716.png b/umn/source/_static/images/en-us_image_0000001518062612.png similarity index 100% rename from umn/source/_static/images/en-us_image_0000001203031716.png rename to umn/source/_static/images/en-us_image_0000001518062612.png diff --git a/umn/source/_static/images/en-us_image_0000001518062624.png b/umn/source/_static/images/en-us_image_0000001518062624.png new file mode 100644 index 0000000..e970982 Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001518062624.png differ diff --git a/umn/source/_static/images/en-us_image_0000001518062636.png b/umn/source/_static/images/en-us_image_0000001518062636.png new file mode 100644 index 0000000..3306881 Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001518062636.png differ diff --git a/umn/source/_static/images/en-us_image_0000001515838557.png b/umn/source/_static/images/en-us_image_0000001518062644.png similarity index 100% rename from umn/source/_static/images/en-us_image_0000001515838557.png rename to umn/source/_static/images/en-us_image_0000001518062644.png diff --git a/umn/source/_static/images/en-us_image_0000001236723668.png b/umn/source/_static/images/en-us_image_0000001518062664.png similarity index 100% rename from umn/source/_static/images/en-us_image_0000001236723668.png rename to umn/source/_static/images/en-us_image_0000001518062664.png diff --git a/umn/source/_static/images/en-us_image_0000001199181230.png b/umn/source/_static/images/en-us_image_0000001518062672.png similarity index 100% rename from umn/source/_static/images/en-us_image_0000001199181230.png rename to umn/source/_static/images/en-us_image_0000001518062672.png diff --git a/umn/source/_static/images/en-us_image_0000001244101107.png b/umn/source/_static/images/en-us_image_0000001518062684.png similarity index 100% rename from umn/source/_static/images/en-us_image_0000001244101107.png rename to umn/source/_static/images/en-us_image_0000001518062684.png diff --git a/umn/source/_static/images/en-us_image_0000001244261119.png b/umn/source/_static/images/en-us_image_0000001518062704.png similarity index 100% rename from umn/source/_static/images/en-us_image_0000001244261119.png rename to umn/source/_static/images/en-us_image_0000001518062704.png diff --git a/umn/source/_static/images/en-us_image_0000001518062756.png b/umn/source/_static/images/en-us_image_0000001518062756.png new file mode 100644 index 0000000..5bfbc6c Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001518062756.png differ diff --git a/umn/source/_static/images/en-us_image_0258871213.png b/umn/source/_static/images/en-us_image_0000001518062772.png similarity index 100% rename from umn/source/_static/images/en-us_image_0258871213.png rename to umn/source/_static/images/en-us_image_0000001518062772.png diff --git a/umn/source/_static/images/en-us_image_0261818893.png b/umn/source/_static/images/en-us_image_0000001518062796.png similarity index 100% rename from umn/source/_static/images/en-us_image_0261818893.png rename to umn/source/_static/images/en-us_image_0000001518062796.png diff --git a/umn/source/_static/images/en-us_image_0000001531533921.png b/umn/source/_static/images/en-us_image_0000001518062808.png similarity index 100% rename from umn/source/_static/images/en-us_image_0000001531533921.png rename to umn/source/_static/images/en-us_image_0000001518062808.png diff --git a/umn/source/_static/images/en-us_image_0000001238225460.png b/umn/source/_static/images/en-us_image_0000001518062812.png similarity index 100% rename from umn/source/_static/images/en-us_image_0000001238225460.png rename to umn/source/_static/images/en-us_image_0000001518062812.png diff --git a/umn/source/_static/images/en-us_image_0000001402494682.png b/umn/source/_static/images/en-us_image_0000001518062816.png similarity index 100% rename from umn/source/_static/images/en-us_image_0000001402494682.png rename to umn/source/_static/images/en-us_image_0000001518062816.png diff --git a/umn/source/_static/images/en-us_image_0000001518222492.png b/umn/source/_static/images/en-us_image_0000001518222492.png new file mode 100644 index 0000000..d09e52e Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001518222492.png differ diff --git a/umn/source/_static/images/en-us_image_0000001199181334.png b/umn/source/_static/images/en-us_image_0000001518222536.png similarity index 100% rename from umn/source/_static/images/en-us_image_0000001199181334.png rename to umn/source/_static/images/en-us_image_0000001518222536.png diff --git a/umn/source/_static/images/en-us_image_0000001518222592.png b/umn/source/_static/images/en-us_image_0000001518222592.png new file mode 100644 index 0000000..f9d93b4 Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001518222592.png differ diff --git a/umn/source/_static/images/en-us_image_0000001201381906.png b/umn/source/_static/images/en-us_image_0000001518222604.png similarity index 100% rename from umn/source/_static/images/en-us_image_0000001201381906.png rename to umn/source/_static/images/en-us_image_0000001518222604.png diff --git a/umn/source/_static/images/en-us_image_0000001244141191.png b/umn/source/_static/images/en-us_image_0000001518222608.png similarity index 100% rename from umn/source/_static/images/en-us_image_0000001244141191.png rename to umn/source/_static/images/en-us_image_0000001518222608.png diff --git a/umn/source/_static/images/en-us_image_0000001205757902.png b/umn/source/_static/images/en-us_image_0000001518222636.png similarity index 100% rename from umn/source/_static/images/en-us_image_0000001205757902.png rename to umn/source/_static/images/en-us_image_0000001518222636.png diff --git a/umn/source/_static/images/en-us_image_0000001518222700.png b/umn/source/_static/images/en-us_image_0000001518222700.png new file mode 100644 index 0000000..603c946 Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001518222700.png differ diff --git a/umn/source/_static/images/en-us_image_0000001518222708.png b/umn/source/_static/images/en-us_image_0000001518222708.png new file mode 100644 index 0000000..226fcf7 Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001518222708.png differ diff --git a/umn/source/_static/images/en-us_image_0258392378.png b/umn/source/_static/images/en-us_image_0000001518222716.png similarity index 100% rename from umn/source/_static/images/en-us_image_0258392378.png rename to umn/source/_static/images/en-us_image_0000001518222716.png diff --git a/umn/source/_static/images/en-us_image_0262051194.png b/umn/source/_static/images/en-us_image_0000001518222732.png similarity index 100% rename from umn/source/_static/images/en-us_image_0262051194.png rename to umn/source/_static/images/en-us_image_0000001518222732.png diff --git a/umn/source/_static/images/en-us_image_0000001199341330.png b/umn/source/_static/images/en-us_image_0000001518222740.png similarity index 100% rename from umn/source/_static/images/en-us_image_0000001199341330.png rename to umn/source/_static/images/en-us_image_0000001518222740.png diff --git a/umn/source/_static/images/en-us_image_0000001520115845.png b/umn/source/_static/images/en-us_image_0000001520115845.png new file mode 100644 index 0000000..13582d7 Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001520115845.png differ diff --git a/umn/source/_static/images/en-us_image_0000001520396937.png b/umn/source/_static/images/en-us_image_0000001520396937.png new file mode 100644 index 0000000..48e6fbe Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001520396937.png differ diff --git a/umn/source/_static/images/en-us_image_0000001550125865.png b/umn/source/_static/images/en-us_image_0000001550125865.png new file mode 100644 index 0000000..dab58aa Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001550125865.png differ diff --git a/umn/source/_static/images/en-us_image_0000001550125873.png b/umn/source/_static/images/en-us_image_0000001550125873.png new file mode 100644 index 0000000..086f270 Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001550125873.png differ diff --git a/umn/source/_static/images/en-us_image_0000001550245853.png b/umn/source/_static/images/en-us_image_0000001550245853.png new file mode 100644 index 0000000..0420d05 Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001550245853.png differ diff --git a/umn/source/_static/images/en-us_image_0000001550245869.png b/umn/source/_static/images/en-us_image_0000001550245869.png new file mode 100644 index 0000000..80fd8a4 Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001550245869.png differ diff --git a/umn/source/_static/images/en-us_image_0000001550365685.png b/umn/source/_static/images/en-us_image_0000001550365685.png new file mode 100644 index 0000000..87c98e3 Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001550365685.png differ diff --git a/umn/source/_static/images/en-us_image_0000001550365705.png b/umn/source/_static/images/en-us_image_0000001550365705.png new file mode 100644 index 0000000..821c26f Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001550365705.png differ diff --git a/umn/source/_static/images/en-us_image_0000001550445737.png b/umn/source/_static/images/en-us_image_0000001550445737.png new file mode 100644 index 0000000..4d7de17 Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001550445737.png differ diff --git a/umn/source/_static/images/en-us_image_0000001550558281.png b/umn/source/_static/images/en-us_image_0000001550558281.png new file mode 100644 index 0000000..7578b2a Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001550558281.png differ diff --git a/umn/source/_static/images/en-us_image_0000001550558289.png b/umn/source/_static/images/en-us_image_0000001550558289.png new file mode 100644 index 0000000..c908664 Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001550558289.png differ diff --git a/umn/source/_static/images/en-us_image_0000001550678257.png b/umn/source/_static/images/en-us_image_0000001550678257.png new file mode 100644 index 0000000..89c31a8 Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001550678257.png differ diff --git a/umn/source/_static/images/en-us_image_0000001550678265.png b/umn/source/_static/images/en-us_image_0000001550678265.png new file mode 100644 index 0000000..c483b45 Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001550678265.png differ diff --git a/umn/source/_static/images/en-us_image_0000001550838141.png b/umn/source/_static/images/en-us_image_0000001550838141.png new file mode 100644 index 0000000..3153ed6 Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001550838141.png differ diff --git a/umn/source/_static/images/en-us_image_0000001199181228.png b/umn/source/_static/images/en-us_image_0000001568822637.png similarity index 100% rename from umn/source/_static/images/en-us_image_0000001199181228.png rename to umn/source/_static/images/en-us_image_0000001568822637.png diff --git a/umn/source/_static/images/en-us_image_0000001243981177.png b/umn/source/_static/images/en-us_image_0000001568822693.png similarity index 100% rename from umn/source/_static/images/en-us_image_0000001243981177.png rename to umn/source/_static/images/en-us_image_0000001568822693.png diff --git a/umn/source/_static/images/en-us_image_0000001201823500.png b/umn/source/_static/images/en-us_image_0000001568822709.png similarity index 100% rename from umn/source/_static/images/en-us_image_0000001201823500.png rename to umn/source/_static/images/en-us_image_0000001568822709.png diff --git a/umn/source/_static/images/en-us_image_0000001199181336.png b/umn/source/_static/images/en-us_image_0000001568822717.png similarity index 100% rename from umn/source/_static/images/en-us_image_0000001199181336.png rename to umn/source/_static/images/en-us_image_0000001568822717.png diff --git a/umn/source/_static/images/en-us_image_0000001199181340.png b/umn/source/_static/images/en-us_image_0000001568822733.png similarity index 100% rename from umn/source/_static/images/en-us_image_0000001199181340.png rename to umn/source/_static/images/en-us_image_0000001568822733.png diff --git a/umn/source/_static/images/en-us_image_0000001244261169.png b/umn/source/_static/images/en-us_image_0000001568822741.png similarity index 100% rename from umn/source/_static/images/en-us_image_0000001244261169.png rename to umn/source/_static/images/en-us_image_0000001568822741.png diff --git a/umn/source/_static/images/en-us_image_0000001199181338.png b/umn/source/_static/images/en-us_image_0000001568822773.png similarity index 100% rename from umn/source/_static/images/en-us_image_0000001199181338.png rename to umn/source/_static/images/en-us_image_0000001568822773.png diff --git a/umn/source/_static/images/en-us_image_0000001533586881.png b/umn/source/_static/images/en-us_image_0000001568822793.png similarity index 100% rename from umn/source/_static/images/en-us_image_0000001533586881.png rename to umn/source/_static/images/en-us_image_0000001568822793.png diff --git a/umn/source/_static/images/en-us_image_0000001244141105.png b/umn/source/_static/images/en-us_image_0000001568822821.png similarity index 100% rename from umn/source/_static/images/en-us_image_0000001244141105.png rename to umn/source/_static/images/en-us_image_0000001568822821.png diff --git a/umn/source/_static/images/en-us_image_0000001568822825.png b/umn/source/_static/images/en-us_image_0000001568822825.png new file mode 100644 index 0000000..d525467 Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001568822825.png differ diff --git a/umn/source/_static/images/en-us_image_0267028603.png b/umn/source/_static/images/en-us_image_0000001568822869.png similarity index 100% rename from umn/source/_static/images/en-us_image_0267028603.png rename to umn/source/_static/images/en-us_image_0000001568822869.png diff --git a/umn/source/_static/images/en-us_image_0000001244261167.png b/umn/source/_static/images/en-us_image_0000001568822905.png similarity index 100% rename from umn/source/_static/images/en-us_image_0000001244261167.png rename to umn/source/_static/images/en-us_image_0000001568822905.png diff --git a/umn/source/_static/images/en-us_image_0000001515917789.png b/umn/source/_static/images/en-us_image_0000001568822917.png similarity index 100% rename from umn/source/_static/images/en-us_image_0000001515917789.png rename to umn/source/_static/images/en-us_image_0000001568822917.png diff --git a/umn/source/_static/images/en-us_image_0000001199501200.png b/umn/source/_static/images/en-us_image_0000001568822925.png similarity index 100% rename from umn/source/_static/images/en-us_image_0000001199501200.png rename to umn/source/_static/images/en-us_image_0000001568822925.png diff --git a/umn/source/_static/images/en-us_image_0261818896.png b/umn/source/_static/images/en-us_image_0000001568822957.png similarity index 100% rename from umn/source/_static/images/en-us_image_0261818896.png rename to umn/source/_static/images/en-us_image_0000001568822957.png diff --git a/umn/source/_static/images/en-us_image_0275445566.png b/umn/source/_static/images/en-us_image_0000001568822961.png similarity index 100% rename from umn/source/_static/images/en-us_image_0275445566.png rename to umn/source/_static/images/en-us_image_0000001568822961.png diff --git a/umn/source/_static/images/en-us_image_0000001199021320.png b/umn/source/_static/images/en-us_image_0000001568822965.png similarity index 100% rename from umn/source/_static/images/en-us_image_0000001199021320.png rename to umn/source/_static/images/en-us_image_0000001568822965.png diff --git a/umn/source/_static/images/en-us_image_0000001378942548.png b/umn/source/_static/images/en-us_image_0000001568902489.png similarity index 100% rename from umn/source/_static/images/en-us_image_0000001378942548.png rename to umn/source/_static/images/en-us_image_0000001568902489.png diff --git a/umn/source/_static/images/en-us_image_0000001568902509.png b/umn/source/_static/images/en-us_image_0000001568902509.png new file mode 100644 index 0000000..30a7eb2 Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001568902509.png differ diff --git a/umn/source/_static/images/en-us_image_0000001244261161.png b/umn/source/_static/images/en-us_image_0000001568902521.png similarity index 100% rename from umn/source/_static/images/en-us_image_0000001244261161.png rename to umn/source/_static/images/en-us_image_0000001568902521.png diff --git a/umn/source/_static/images/en-us_image_0000001568902533.png b/umn/source/_static/images/en-us_image_0000001568902533.png new file mode 100644 index 0000000..b52a62d Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001568902533.png differ diff --git a/umn/source/_static/images/en-us_image_0000001249958645.png b/umn/source/_static/images/en-us_image_0000001568902541.png similarity index 100% rename from umn/source/_static/images/en-us_image_0000001249958645.png rename to umn/source/_static/images/en-us_image_0000001568902541.png diff --git a/umn/source/_static/images/en-us_image_0000001203385342.png b/umn/source/_static/images/en-us_image_0000001568902557.png similarity index 100% rename from umn/source/_static/images/en-us_image_0000001203385342.png rename to umn/source/_static/images/en-us_image_0000001568902557.png diff --git a/umn/source/_static/images/en-us_image_0000001199021308.png b/umn/source/_static/images/en-us_image_0000001568902577.png similarity index 100% rename from umn/source/_static/images/en-us_image_0000001199021308.png rename to umn/source/_static/images/en-us_image_0000001568902577.png diff --git a/umn/source/_static/images/en-us_image_0000001568902601.png b/umn/source/_static/images/en-us_image_0000001568902601.png new file mode 100644 index 0000000..0e6fa61 Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001568902601.png differ diff --git a/umn/source/_static/images/en-us_image_0000001568902637.png b/umn/source/_static/images/en-us_image_0000001568902637.png new file mode 100644 index 0000000..ebc6976 Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001568902637.png differ diff --git a/umn/source/_static/images/en-us_image_0000001568902649.png b/umn/source/_static/images/en-us_image_0000001568902649.png new file mode 100644 index 0000000..ebc6976 Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001568902649.png differ diff --git a/umn/source/_static/images/en-us_image_0000001482796460.png b/umn/source/_static/images/en-us_image_0000001568902653.png similarity index 100% rename from umn/source/_static/images/en-us_image_0000001482796460.png rename to umn/source/_static/images/en-us_image_0000001568902653.png diff --git a/umn/source/_static/images/en-us_image_0000001568902661.png b/umn/source/_static/images/en-us_image_0000001568902661.png new file mode 100644 index 0000000..47324ea Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001568902661.png differ diff --git a/umn/source/_static/images/en-us_image_0000001202103502.png b/umn/source/_static/images/en-us_image_0000001568902669.png similarity index 100% rename from umn/source/_static/images/en-us_image_0000001202103502.png rename to umn/source/_static/images/en-us_image_0000001568902669.png diff --git a/umn/source/_static/images/en-us_image_0261818899.png b/umn/source/_static/images/en-us_image_0000001568902689.png similarity index 100% rename from umn/source/_static/images/en-us_image_0261818899.png rename to umn/source/_static/images/en-us_image_0000001568902689.png diff --git a/umn/source/_static/images/en-us_image_0000001243981141.png b/umn/source/_static/images/en-us_image_0000001569022781.png similarity index 100% rename from umn/source/_static/images/en-us_image_0000001243981141.png rename to umn/source/_static/images/en-us_image_0000001569022781.png diff --git a/umn/source/_static/images/en-us_image_0000001243981147.png b/umn/source/_static/images/en-us_image_0000001569022797.png similarity index 100% rename from umn/source/_static/images/en-us_image_0000001243981147.png rename to umn/source/_static/images/en-us_image_0000001569022797.png diff --git a/umn/source/_static/images/en-us_image_0000001244261055.png b/umn/source/_static/images/en-us_image_0000001569022837.png similarity index 100% rename from umn/source/_static/images/en-us_image_0000001244261055.png rename to umn/source/_static/images/en-us_image_0000001569022837.png diff --git a/umn/source/_static/images/en-us_image_0000001202101148.png b/umn/source/_static/images/en-us_image_0000001569022881.png similarity index 100% rename from umn/source/_static/images/en-us_image_0000001202101148.png rename to umn/source/_static/images/en-us_image_0000001569022881.png diff --git a/umn/source/_static/images/en-us_image_0000001244261173.png b/umn/source/_static/images/en-us_image_0000001569022889.png similarity index 100% rename from umn/source/_static/images/en-us_image_0000001244261173.png rename to umn/source/_static/images/en-us_image_0000001569022889.png diff --git a/umn/source/_static/images/en-us_image_0000001569022901.png b/umn/source/_static/images/en-us_image_0000001569022901.png new file mode 100644 index 0000000..827836e Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001569022901.png differ diff --git a/umn/source/_static/images/en-us_image_0000001533585325.png b/umn/source/_static/images/en-us_image_0000001569022905.png similarity index 100% rename from umn/source/_static/images/en-us_image_0000001533585325.png rename to umn/source/_static/images/en-us_image_0000001569022905.png diff --git a/umn/source/_static/images/en-us_image_0000001247802971.png b/umn/source/_static/images/en-us_image_0000001569022913.png similarity index 100% rename from umn/source/_static/images/en-us_image_0000001247802971.png rename to umn/source/_static/images/en-us_image_0000001569022913.png diff --git a/umn/source/_static/images/en-us_image_0000001397733101.png b/umn/source/_static/images/en-us_image_0000001569022929.png similarity index 100% rename from umn/source/_static/images/en-us_image_0000001397733101.png rename to umn/source/_static/images/en-us_image_0000001569022929.png diff --git a/umn/source/_static/images/en-us_image_0000001244261069.png b/umn/source/_static/images/en-us_image_0000001569022933.png similarity index 100% rename from umn/source/_static/images/en-us_image_0000001244261069.png rename to umn/source/_static/images/en-us_image_0000001569022933.png diff --git a/umn/source/_static/images/en-us_image_0000001199181298.png b/umn/source/_static/images/en-us_image_0000001569022957.png similarity index 100% rename from umn/source/_static/images/en-us_image_0000001199181298.png rename to umn/source/_static/images/en-us_image_0000001569022957.png diff --git a/umn/source/_static/images/en-us_image_0000001244141181.png b/umn/source/_static/images/en-us_image_0000001569022961.png similarity index 100% rename from umn/source/_static/images/en-us_image_0000001244141181.png rename to umn/source/_static/images/en-us_image_0000001569022961.png diff --git a/umn/source/_static/images/en-us_image_0000001276433425.png b/umn/source/_static/images/en-us_image_0000001569022977.png similarity index 100% rename from umn/source/_static/images/en-us_image_0000001276433425.png rename to umn/source/_static/images/en-us_image_0000001569022977.png diff --git a/umn/source/_static/images/en-us_image_0000001569023013.png b/umn/source/_static/images/en-us_image_0000001569023013.png new file mode 100644 index 0000000..ebc6976 Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001569023013.png differ diff --git a/umn/source/_static/images/en-us_image_0000001569023025.png b/umn/source/_static/images/en-us_image_0000001569023025.png new file mode 100644 index 0000000..ebc6976 Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001569023025.png differ diff --git a/umn/source/_static/images/en-us_image_0000001569023029.png b/umn/source/_static/images/en-us_image_0000001569023029.png new file mode 100644 index 0000000..9b7e01f Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001569023029.png differ diff --git a/umn/source/_static/images/en-us_image_0258095884.png b/umn/source/_static/images/en-us_image_0000001569023033.png similarity index 100% rename from umn/source/_static/images/en-us_image_0258095884.png rename to umn/source/_static/images/en-us_image_0000001569023033.png diff --git a/umn/source/_static/images/en-us_image_0000001243981117.png b/umn/source/_static/images/en-us_image_0000001569023045.png similarity index 100% rename from umn/source/_static/images/en-us_image_0000001243981117.png rename to umn/source/_static/images/en-us_image_0000001569023045.png diff --git a/umn/source/_static/images/en-us_image_0275452681.png b/umn/source/_static/images/en-us_image_0000001569023069.png similarity index 100% rename from umn/source/_static/images/en-us_image_0275452681.png rename to umn/source/_static/images/en-us_image_0000001569023069.png diff --git a/umn/source/_static/images/en-us_image_0000001569023085.png b/umn/source/_static/images/en-us_image_0000001569023085.png new file mode 100644 index 0000000..ff8087b Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001569023085.png differ diff --git a/umn/source/_static/images/en-us_image_0000001244141141.gif b/umn/source/_static/images/en-us_image_0000001569182497.gif similarity index 100% rename from umn/source/_static/images/en-us_image_0000001244141141.gif rename to umn/source/_static/images/en-us_image_0000001569182497.gif diff --git a/umn/source/_static/images/en-us_image_0000001199341250.png b/umn/source/_static/images/en-us_image_0000001569182505.png similarity index 100% rename from umn/source/_static/images/en-us_image_0000001199341250.png rename to umn/source/_static/images/en-us_image_0000001569182505.png diff --git a/umn/source/_static/images/en-us_image_0000001199021298.png b/umn/source/_static/images/en-us_image_0000001569182513.png similarity index 100% rename from umn/source/_static/images/en-us_image_0000001199021298.png rename to umn/source/_static/images/en-us_image_0000001569182513.png diff --git a/umn/source/_static/images/en-us_image_0000001244261171.png b/umn/source/_static/images/en-us_image_0000001569182549.png similarity index 100% rename from umn/source/_static/images/en-us_image_0000001244261171.png rename to umn/source/_static/images/en-us_image_0000001569182549.png diff --git a/umn/source/_static/images/en-us_image_0000001199501290.png b/umn/source/_static/images/en-us_image_0000001569182553.png similarity index 100% rename from umn/source/_static/images/en-us_image_0000001199501290.png rename to umn/source/_static/images/en-us_image_0000001569182553.png diff --git a/umn/source/_static/images/en-us_image_0000001256348238.jpg b/umn/source/_static/images/en-us_image_0000001569182569.jpg similarity index 100% rename from umn/source/_static/images/en-us_image_0000001256348238.jpg rename to umn/source/_static/images/en-us_image_0000001569182569.jpg diff --git a/umn/source/_static/images/en-us_image_0000001225747980.png b/umn/source/_static/images/en-us_image_0000001569182589.png similarity index 100% rename from umn/source/_static/images/en-us_image_0000001225747980.png rename to umn/source/_static/images/en-us_image_0000001569182589.png diff --git a/umn/source/_static/images/en-us_image_0000001199181266.png b/umn/source/_static/images/en-us_image_0000001569182621.png similarity index 100% rename from umn/source/_static/images/en-us_image_0000001199181266.png rename to umn/source/_static/images/en-us_image_0000001569182621.png diff --git a/umn/source/_static/images/en-us_image_0000001569182625.png b/umn/source/_static/images/en-us_image_0000001569182625.png new file mode 100644 index 0000000..ebc6976 Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001569182625.png differ diff --git a/umn/source/_static/images/en-us_image_0000001199181232.png b/umn/source/_static/images/en-us_image_0000001569182645.png similarity index 100% rename from umn/source/_static/images/en-us_image_0000001199181232.png rename to umn/source/_static/images/en-us_image_0000001569182645.png diff --git a/umn/source/_static/images/en-us_image_0000001206876656.png b/umn/source/_static/images/en-us_image_0000001569182673.png similarity index 100% rename from umn/source/_static/images/en-us_image_0000001206876656.png rename to umn/source/_static/images/en-us_image_0000001569182673.png diff --git a/umn/source/_static/images/en-us_image_0000001243981181.png b/umn/source/_static/images/en-us_image_0000001569182677.png similarity index 100% rename from umn/source/_static/images/en-us_image_0000001243981181.png rename to umn/source/_static/images/en-us_image_0000001569182677.png diff --git a/umn/source/_static/images/en-us_image_0000001569182741.png b/umn/source/_static/images/en-us_image_0000001569182741.png new file mode 100644 index 0000000..ca9934b Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001569182741.png differ diff --git a/umn/source/_static/images/en-us_image_0000001244141217.png b/umn/source/_static/images/en-us_image_0000001569182773.png similarity index 100% rename from umn/source/_static/images/en-us_image_0000001244141217.png rename to umn/source/_static/images/en-us_image_0000001569182773.png diff --git a/umn/source/_static/images/en-us_image_0000001192028618.png b/umn/source/_static/images/en-us_image_0000001569182781.png similarity index 100% rename from umn/source/_static/images/en-us_image_0000001192028618.png rename to umn/source/_static/images/en-us_image_0000001569182781.png diff --git a/umn/source/_static/images/en-us_image_0000001578443828.png b/umn/source/_static/images/en-us_image_0000001578443828.png new file mode 100644 index 0000000..0819970 Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001578443828.png differ diff --git a/umn/source/_static/images/en-us_image_0000001579008782.png b/umn/source/_static/images/en-us_image_0000001579008782.png new file mode 100644 index 0000000..bbd7fce Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001579008782.png differ diff --git a/umn/source/_static/images/en-us_image_0000001626725269.png b/umn/source/_static/images/en-us_image_0000001626725269.png new file mode 100644 index 0000000..6dd1e58 Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001626725269.png differ diff --git a/umn/source/_static/images/en-us_image_0000001628843805.png b/umn/source/_static/images/en-us_image_0000001628843805.png new file mode 100644 index 0000000..6bc88c9 Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001628843805.png differ diff --git a/umn/source/_static/images/en-us_image_0000001629186693.png b/umn/source/_static/images/en-us_image_0000001629186693.png new file mode 100644 index 0000000..59c35f2 Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001629186693.png differ diff --git a/umn/source/_static/images/en-us_image_0000001528627005.png b/umn/source/_static/images/en-us_image_0000001629926113.png similarity index 100% rename from umn/source/_static/images/en-us_image_0000001528627005.png rename to umn/source/_static/images/en-us_image_0000001629926113.png diff --git a/umn/source/_static/images/en-us_image_0091280734.png b/umn/source/_static/images/en-us_image_0091280734.png new file mode 100644 index 0000000..9f288ee Binary files /dev/null and b/umn/source/_static/images/en-us_image_0091280734.png differ diff --git a/umn/source/_static/images/en-us_image_0091292713.png b/umn/source/_static/images/en-us_image_0091292713.png new file mode 100644 index 0000000..e76121b Binary files /dev/null and b/umn/source/_static/images/en-us_image_0091292713.png differ diff --git a/umn/source/_static/images/en-us_image_0166039537.png b/umn/source/_static/images/en-us_image_0166039537.png new file mode 100644 index 0000000..2975726 Binary files /dev/null and b/umn/source/_static/images/en-us_image_0166039537.png differ diff --git a/umn/source/_static/images/en-us_image_0259557735.png b/umn/source/_static/images/en-us_image_0259557735.png deleted file mode 100644 index f872413..0000000 Binary files a/umn/source/_static/images/en-us_image_0259557735.png and /dev/null differ diff --git a/umn/source/_static/images/en-us_image_0259558489.png b/umn/source/_static/images/en-us_image_0259558489.png deleted file mode 100644 index b3c7032..0000000 Binary files a/umn/source/_static/images/en-us_image_0259558489.png and /dev/null differ diff --git a/umn/source/_static/images/en-us_image_0261301557.png b/umn/source/_static/images/en-us_image_0261301557.png new file mode 100644 index 0000000..35845e1 Binary files /dev/null and b/umn/source/_static/images/en-us_image_0261301557.png differ diff --git a/umn/source/_static/images/en-us_image_0264626618.png b/umn/source/_static/images/en-us_image_0264626618.png new file mode 100644 index 0000000..3aa8ffe Binary files /dev/null and b/umn/source/_static/images/en-us_image_0264626618.png differ diff --git a/umn/source/_static/images/en-us_image_0271457115.png b/umn/source/_static/images/en-us_image_0271457115.png new file mode 100644 index 0000000..0385dfa Binary files /dev/null and b/umn/source/_static/images/en-us_image_0271457115.png differ diff --git a/umn/source/_static/images/en-us_image_0271463079.png b/umn/source/_static/images/en-us_image_0271463079.png new file mode 100644 index 0000000..ed2fe21 Binary files /dev/null and b/umn/source/_static/images/en-us_image_0271463079.png differ diff --git a/umn/source/_static/images/en-us_image_0271466158.png b/umn/source/_static/images/en-us_image_0271466158.png new file mode 100644 index 0000000..82576d0 Binary files /dev/null and b/umn/source/_static/images/en-us_image_0271466158.png differ diff --git a/umn/source/_static/images/en-us_image_0271466198.png b/umn/source/_static/images/en-us_image_0271466198.png new file mode 100644 index 0000000..b5d2ca2 Binary files /dev/null and b/umn/source/_static/images/en-us_image_0271466198.png differ diff --git a/umn/source/_static/images/en-us_image_0271466320.png b/umn/source/_static/images/en-us_image_0271466320.png new file mode 100644 index 0000000..d9b35cd Binary files /dev/null and b/umn/source/_static/images/en-us_image_0271466320.png differ diff --git a/umn/source/_static/images/en-us_image_0271466336.png b/umn/source/_static/images/en-us_image_0271466336.png new file mode 100644 index 0000000..a84cdae Binary files /dev/null and b/umn/source/_static/images/en-us_image_0271466336.png differ diff --git a/umn/source/_static/images/en-us_image_0271466402.png b/umn/source/_static/images/en-us_image_0271466402.png new file mode 100644 index 0000000..5ca5f9a Binary files /dev/null and b/umn/source/_static/images/en-us_image_0271466402.png differ diff --git a/umn/source/_static/images/en-us_image_0271466430.png b/umn/source/_static/images/en-us_image_0271466430.png new file mode 100644 index 0000000..88ea1be Binary files /dev/null and b/umn/source/_static/images/en-us_image_0271466430.png differ diff --git a/umn/source/_static/images/en-us_image_0271467350.png b/umn/source/_static/images/en-us_image_0271467350.png new file mode 100644 index 0000000..245b77a Binary files /dev/null and b/umn/source/_static/images/en-us_image_0271467350.png differ diff --git a/umn/source/_static/images/en-us_image_0271467469.png b/umn/source/_static/images/en-us_image_0271467469.png new file mode 100644 index 0000000..4d46baa Binary files /dev/null and b/umn/source/_static/images/en-us_image_0271467469.png differ diff --git a/umn/source/add-ons/autoscaler.rst b/umn/source/add-ons/autoscaler.rst index edb2c9d..14e5c30 100644 --- a/umn/source/add-ons/autoscaler.rst +++ b/umn/source/add-ons/autoscaler.rst @@ -77,6 +77,9 @@ Installing the Add-on | | - **HA200**: The add-on is deployed with two pods, serving a cluster with 50 nodes and ensuring high availability. Each pod uses more resources than those of the **HA50** specification. | | | - **Custom**: You can customize the number of pods and specifications as required. | +-----------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | Multi AZ | - **Preferred**: Deployment pods of the add-on are preferentially scheduled to nodes in different AZs. If the nodes in the cluster do not meet the requirements of multiple AZs, the pods are scheduled to a single AZ. | + | | - **Required**: Deployment pods of the add-on are forcibly scheduled to nodes in different AZs. If the nodes in the cluster do not meet the requirements of multiple AZs, not all pods can run. | + +-----------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ .. table:: **Table 2** Parameter configuration diff --git a/umn/source/add-ons/coredns_system_resource_add-on_mandatory.rst b/umn/source/add-ons/coredns_system_resource_add-on_mandatory.rst index 812cbf8..3fd0f80 100644 --- a/umn/source/add-ons/coredns_system_resource_add-on_mandatory.rst +++ b/umn/source/add-ons/coredns_system_resource_add-on_mandatory.rst @@ -49,6 +49,9 @@ This add-on has been installed by default. If it is uninstalled due to some reas +-----------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Pods | Number of pods that will be created to match the selected add-on specifications. | +-----------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | Multi AZ | - **Preferred**: Deployment pods of the add-on are preferentially scheduled to nodes in different AZs. If the nodes in the cluster do not meet the requirements of multiple AZs, the pods are scheduled to a single AZ. | + | | - **Required**: Deployment pods of the add-on are forcibly scheduled to nodes in different AZs. If the nodes in the cluster do not meet the requirements of multiple AZs, not all pods can run. | + +-----------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Containers | CPU and memory quotas of the container allowed for the selected add-on specifications. | +-----------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Parameters | - **parameterSyncStrategy**: indicates whether to configure consistency check when an add-on is upgraded. | @@ -194,7 +197,7 @@ DNS policies can be set on a per-pod basis. Currently, Kubernetes supports four - Names that do not match the suffix (for example, **widget.com**): The request is forwarded to the upstream DNS. -.. figure:: /_static/images/en-us_image_0000001199021308.png +.. figure:: /_static/images/en-us_image_0000001568902577.png :alt: **Figure 1** Routing **Figure 1** Routing diff --git a/umn/source/add-ons/everest_system_resource_add-on_mandatory.rst b/umn/source/add-ons/everest_system_resource_add-on_mandatory.rst index cef0210..472ff66 100644 --- a/umn/source/add-ons/everest_system_resource_add-on_mandatory.rst +++ b/umn/source/add-ons/everest_system_resource_add-on_mandatory.rst @@ -45,6 +45,11 @@ This add-on has been installed by default. If it is uninstalled due to some reas If you select **Custom**, it is recommended that the **everest-csi-driver** memory limit be greater than or equal to 300 MiB. If the value is too small, the add-on container cannot be started and the add-on is unavailable. +#. Whether to deploy the add-on instance across multiple AZs. + + - **Preferred**: Deployment pods of the add-on are preferentially scheduled to nodes in different AZs. If the nodes in the cluster do not meet the requirements of multiple AZs, the pods are scheduled to a single AZ. + - **Required**: Deployment pods of the add-on are forcibly scheduled to nodes in different AZs. If the nodes in the cluster do not meet the requirements of multiple AZs, not all pods can run. + #. Set related parameters. In everest 1.2.26 or later, the performance of attaching a large number of EVS volumes is optimized. The following three parameters are provided: diff --git a/umn/source/add-ons/gpu-beta.rst b/umn/source/add-ons/gpu-beta.rst index 75ac615..9803358 100644 --- a/umn/source/add-ons/gpu-beta.rst +++ b/umn/source/add-ons/gpu-beta.rst @@ -68,7 +68,7 @@ Obtaining the Driver Link from Public Network .. _cce_10_0141__fig11696366517: - .. figure:: /_static/images/en-us_image_0000001531533921.png + .. figure:: /_static/images/en-us_image_0000001518062808.png :alt: **Figure 1** Setting parameters **Figure 1** Setting parameters @@ -77,7 +77,7 @@ Obtaining the Driver Link from Public Network .. _cce_10_0141__fig7873421145213: - .. figure:: /_static/images/en-us_image_0000001531373685.png + .. figure:: /_static/images/en-us_image_0000001517743660.png :alt: **Figure 2** Driver information **Figure 2** Driver information @@ -90,9 +90,9 @@ Obtaining the Driver Link from Public Network .. _cce_10_0141__fig5901194614534: - .. figure:: /_static/images/en-us_image_0000001531533045.png + .. figure:: /_static/images/en-us_image_0000001517903240.png :alt: **Figure 3** Obtaining the link **Figure 3** Obtaining the link -.. |image1| image:: /_static/images/en-us_image_0000001238225460.png +.. |image1| image:: /_static/images/en-us_image_0000001518062812.png diff --git a/umn/source/add-ons/metrics-server.rst b/umn/source/add-ons/metrics-server.rst index e3af12a..5212d15 100644 --- a/umn/source/add-ons/metrics-server.rst +++ b/umn/source/add-ons/metrics-server.rst @@ -17,4 +17,14 @@ Installing the Add-on --------------------- #. Log in to the CCE console and access the cluster console. Choose **Add-ons** in the navigation pane, locate **metrics-server** on the right, and click **Install**. -#. Select **Single** or **HA** for **Add-on Specifications**, and click **Install**. +#. Select **Single**, **Custom**, or **HA** for **Add-on Specifications**. + + - **Pods**: Set the number of pods based on service requirements. + - **Multi AZ**: + + - **Preferred**: Deployment pods of the add-on are preferentially scheduled to nodes in different AZs. If the nodes in the cluster do not meet the requirements of multiple AZs, the pods are scheduled to a single AZ. + - **Required**: Deployment pods of the add-on are forcibly scheduled to nodes in different AZs. If the nodes in the cluster do not meet the requirements of multiple AZs, not all pods can run. + + - **Containers**: Set a proper container quota based on service requirements. + +#. Click **Install**. diff --git a/umn/source/add-ons/npd.rst b/umn/source/add-ons/npd.rst index 10d233e..d4d1401 100644 --- a/umn/source/add-ons/npd.rst +++ b/umn/source/add-ons/npd.rst @@ -31,18 +31,16 @@ In addition, CCE mitigates risks according to the least privilege principle. Onl Installing the Add-on --------------------- -#. Log in to the CCE console, click the cluster name, and access the cluster console. Choose **Add-ons** in the navigation pane, locate **npd** on the right, and click **Install**. +#. Log in to the CCE console and access the cluster console. Choose **Add-ons** in the navigation pane, locate **npd** on the right, and click **Install**. #. On the **Install Add-on** page, select the add-on specifications and set related parameters. - **Pods**: Set the number of pods based on service requirements. - **Containers**: Select a proper container quota based on service requirements. -#. Set the parameters according to the following table and click **Install**. +#. Set the npd parameters and click **Install**. - Only 1.16.0 and later versions support the configurations. - - **npc.enable**: indicates whether to enable :ref:`Node-problem-controller `. + The parameters are configurable only in 1.16.0 and later versions. For details, see :ref:`Table 7 `. npd Check Items --------------- @@ -59,224 +57,255 @@ Check items cover events and statuses. .. table:: **Table 1** Event-related check items - +-----------------------+-------------------------------------------------------+-----------------------+ - | Check Item | Function | Description | - +=======================+=======================================================+=======================+ - | OOMKilling | Check whether OOM events occur and are reported. | Warning event | - +-----------------------+-------------------------------------------------------+-----------------------+ - | TaskHung | Check whether taskHung events occur and are reported. | Warning event | - +-----------------------+-------------------------------------------------------+-----------------------+ - | KernelOops | Check kernel nil pointer panic errors. | Warning event | - +-----------------------+-------------------------------------------------------+-----------------------+ - | ConntrackFull | Check whether the conntrack table is full. | Warning event | - | | | | - | | | Interval: 30 seconds | - | | | | - | | | Threshold: 80% | - +-----------------------+-------------------------------------------------------+-----------------------+ + +-----------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-------------------------------------------------------------------------------------------------------+ + | Check Item | Function | Description | + +=======================+==============================================================================================================================================================================================================================================================+=======================================================================================================+ + | OOMKilling | Listen to the kernel logs and check whether OOM events occur and are reported. | Warning event | + | | | | + | | Typical scenario: When the memory usage of a process in a container exceeds the limit, OOM is triggered and the process is terminated. | Listening object: **/dev/kmsg** | + | | | | + | | | Matching rule: "Killed process \\\\d+ (.+) total-vm:\\\\d+kB, anon-rss:\\\\d+kB, file-rss:\\\\d+kB.*" | + +-----------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-------------------------------------------------------------------------------------------------------+ + | TaskHung | Listen to the kernel logs and check whether taskHung events occur and are reported. | Warning event | + | | | | + | | Typical scenario: Disk I/O suspension causes process suspension. | Listening object: **/dev/kmsg** | + | | | | + | | | Matching rule: "task \\\\S+:\\\\w+ blocked for more than \\\\w+ seconds\\\\." | + +-----------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-------------------------------------------------------------------------------------------------------+ + | ReadonlyFilesystem | Check whether the **Remount root filesystem read-only** error occurs in the system kernel by listening to the kernel logs. | Warning event | + | | | | + | | Typical scenario: A user detaches a data disk from a node by mistake on the ECS, and applications continuously write data to the mount point of the data disk. As a result, an I/O error occurs in the kernel and the disk is remounted as a read-only disk. | Listening object: **/dev/kmsg** | + | | | | + | | | Matching rule: **Remounting filesystem read-only** | + +-----------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-------------------------------------------------------------------------------------------------------+ - Status-related - For status-related check items, when a problem occurs, npd reports an event to the API server and changes the node status synchronously. This function can be used together with :ref:`Node-problem-controller fault isolation ` to isolate nodes. + For status-related check items, when a problem occurs, npd reports an event to the API server and changes the node status synchronously. This function can be used together with :ref:`Node-problem-controller fault isolation ` to isolate nodes. **If the check period is not specified in the following check items, the default period is 30 seconds.** - .. table:: **Table 2** Application and OS check items + .. table:: **Table 2** Checking system components - +---------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------+ - | Check Item | Function | Description | - +===========================+===============================================================================================================================================================+============================================================================================================================================================+ - | FrequentKubeletRestart | Check whether kubelet restarts frequently by listening to journald logs. | - Interval: 5 minutes | - | | | | - | | | - Backtracking: 10 minutes | - | | | | - | | | - Threshold: 10 times | - | | | | - | | | If the system restarts for 10 times within the backtracking period, it indicates that the system restarts frequently and a fault alarm is generated. | - | | | | - | | | - Listening object: logs in the **/run/log/journal** directory | - | | | | - | | | .. note:: | - | | | | - | | | The Ubuntu OS does not support the preceding check items due to incompatible log formats. | - +---------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------+ - | FrequentDockerRestart | Check whether Docker restarts frequently by listening to journald logs. | | - +---------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------+ - | FrequentContainerdRestart | Check whether containerd restarts frequently by listening to journald logs. | | - +---------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------+ - | CRIProblem | Check the CRI component status. | Check object: Docker or containerd | - +---------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------+ - | KUBELETProblem | Check the kubelet status. | None | - +---------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------+ - | NTPProblem | Check the NTP and Chrony service status. | Threshold of the clock offset: 8000 ms | - | | | | - | | Check whether the node clock offsets. | | - +---------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------+ - | PIDProblem | Check whether PIDs are sufficient. | - Threshold: 90% | - | | | - Usage: nr_threads in /proc/loadavg | - | | | - Maximum value: smaller value between **/proc/sys/kernel/pid_max** and **/proc/sys/kernel/threads-max**. | - +---------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------+ - | FDProblem | Check whether file handles are sufficient. | - Threshold: 90% | - | | | - Usage: the first value in **/proc/sys/fs/file-nr** | - | | | - Maximum value: the third value in **/proc/sys/fs/file-nr** | - +---------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------+ - | MemoryProblem | Check whether the overall node memory is sufficient. | - Threshold: 90% | - | | | - Usage: **MemTotal-MemAvailable** in **/proc/meminfo** | - | | | - Maximum value: **MemTotal** in **/proc/meminfo** | - +---------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------+ - | ResolvConfFileProblem | Check whether the ResolvConf file is lost. | Object: **/etc/resolv.conf** | - | | | | - | | Check whether the ResolvConf file is normal. | | - | | | | - | | Exception definition: No upstream domain name resolution server (nameserver) is included. | | - +---------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------+ - | ProcessD | Check whether there is a process D on the node. | Source: | - | | | | - | | | - /proc/{PID}/stat | - | | | - Alternately, you can run **ps aux**. | - | | | | - | | | Exception scenario: ProcessD ignores the resident processes (heartbeat and update) that are in the D state that the SDI driver on the BMS node depends on. | - +---------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------+ - | ProcessZ | Check whether the node has processes in Z state. | | - +---------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------+ - | ScheduledEvent | Check whether host plan events exist on the node. | Source: | - | | | | - | | Typical scenario: The host is faulty, for example, the fan is damaged or the disk has bad sectors. As a result, cold and live migration is triggered for VMs. | - http://169.254.169.254/meta-data/latest/events/scheduled | - | | | | - | | | This check item is an Alpha feature and is disabled by default. | - +---------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------+ + +-----------------------------------+-----------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------+ + | Check Item | Function | Description | + +===================================+===========================================================================================================+=========================================================================================================================================+ + | Container network component error | Check the status of the CNI components (container network components). | None | + | | | | + | CNIProblem | | | + +-----------------------------------+-----------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------+ + | Container runtime component error | Check the status of Docker and containerd of the CRI components (container runtime components). | Check object: Docker or containerd | + | | | | + | CRIProblem | | | + +-----------------------------------+-----------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------+ + | Frequent restarts of Kubelet | Periodically backtrack system logs to check whether the key component Kubelet restarts frequently. | - Default threshold: 10 restarts within 10 minutes | + | | | | + | FrequentKubeletRestart | | If Kubelet restarts for 10 times within 10 minutes, it indicates that the system restarts frequently and a fault alarm is generated. | + | | | | + | | | - Listening object: logs in the **/run/log/journal** directory | + +-----------------------------------+-----------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------+ + | Frequent restarts of Docker | Periodically backtrack system logs to check whether the container runtime Docker restarts frequently. | | + | | | | + | FrequentDockerRestart | | | + +-----------------------------------+-----------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------+ + | Frequent restarts of containerd | Periodically backtrack system logs to check whether the container runtime containerd restarts frequently. | | + | | | | + | FrequentContainerdRestart | | | + +-----------------------------------+-----------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------+ + | kubelet error | Check the status of the key component Kubelet. | None | + | | | | + | KubeletProblem | | | + +-----------------------------------+-----------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------+ + | kube-proxy error | Check the status of the key component kube-proxy. | None | + | | | | + | KubeProxyProblem | | | + +-----------------------------------+-----------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------+ - .. table:: **Table 3** Network connection check items + .. table:: **Table 3** Checking system metrics - +------------------+------------------------------------------------------+-------------+ - | Check Item | Function | Description | - +==================+======================================================+=============+ - | CNIProblem | Check whether the CNI component is running properly. | None | - +------------------+------------------------------------------------------+-------------+ - | KUBEPROXYProblem | Check whether kube-proxy is running properly. | None | - +------------------+------------------------------------------------------+-------------+ + +--------------------------------+------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------+ + | Check Item | Function | Description | + +================================+==============================================================================================================================+============================================================================================================+ + | Conntrack table full | Check whether the conntrack table is full. | - Default threshold: 90% | + | | | | + | ConntrackFullProblem | | - Usage: **nf_conntrack_count** | + | | | - Maximum value: **nf_conntrack_max** | + +--------------------------------+------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------+ + | Insufficient disk resources | Check the usage of the system disk and CCE data disks (including the CRI logical disk and kubelet logical disk) on the node. | - Default threshold: 90% | + | | | | + | DiskProblem | | - Source: | + | | | | + | | | .. code-block:: | + | | | | + | | | df -h | + | | | | + | | | Currently, additional data disks are not supported. | + +--------------------------------+------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------+ + | Insufficient file handles | Check whether FD file handles are used up. | - Default threshold: 90% | + | | | - Usage: the first value in **/proc/sys/fs/file-nr** | + | FDProblem | | - Maximum value: the third value in **/proc/sys/fs/file-nr** | + +--------------------------------+------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------+ + | Insufficient node memory | Check whether memory is used up. | - Default threshold: 80% | + | | | - Usage: **MemTotal-MemAvailable** in **/proc/meminfo** | + | MemoryProblem | | - Maximum value: **MemTotal** in **/proc/meminfo** | + +--------------------------------+------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------+ + | Insufficient process resources | Check whether PID process resources are exhausted. | - Default threshold: 90% | + | | | - Usage: **nr_threads in /proc/loadavg** | + | PIDProblem | | - Maximum value: smaller value between **/proc/sys/kernel/pid_max** and **/proc/sys/kernel/threads-max**. | + +--------------------------------+------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------+ - .. table:: **Table 4** Storage check items + .. table:: **Table 4** Checking the storage - +--------------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ - | Check Item | Function | Description | - +================================+====================================================================================================================================================================================================================================================================================================================================================================================================+====================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================+ - | ReadonlyFilesystem | Check whether the **Remount root filesystem read-only** error occurs in the system kernel by listening to the kernel logs. | Listening object: **/dev/kmsg** | - | | | | - | | Typical scenario: A user detaches a data disk from a node by mistake on the ECS, and applications continuously write data to the mount point of the data disk. As a result, an I/O error occurs in the kernel and the disk is reattached as a read-only disk. | Matching rule: **Remounting filesystem read-only** | - +--------------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ - | DiskReadonly | Check whether the system disk, Docker disk, and kubelet disk are read-only. | Detection paths: | - | | | | - | | | - /mnt/paas/kubernetes/kubelet/ | - | | | - /var/lib/docker/ | - | | | - /var/lib/containerd/ | - | | | - /var/paas/sys/log/cceaddon-npd/ | - | | | | - | | | The temporary file **npd-disk-write-ping** is generated in the detection path. | - | | | | - | | | Currently, additional data disks are not supported. | - +--------------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ - | DiskProblem | Check the usage of the system disk, Docker disk, and kubelet disk. | - Threshold: 80% | - | | | | - | | | - Source: | - | | | | - | | | .. code-block:: | - | | | | - | | | df -h | - | | | | - | | | Currently, additional data disks are not supported. | - +--------------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ - | EmptyDirVolumeGroupStatusError | Check whether the ephemeral volume group on the node is normal. | - Detection period: 60s | - | | | | - | | Impact: The pod that depends on the storage pool cannot write data to the temporary volume. The temporary volume is remounted as a read-only file system by the kernel due to an I/O error. | - Source: | - | | | | - | | Typical scenario: When creating a node, a user configures two data disks as a temporary volume storage pool. The user deletes some data disks by mistake. As a result, the storage pool becomes abnormal. | .. code-block:: | - | | | | - | | | vgs -o vg_name, vg_attr | - | | | | - | | | - Principle: Check whether the VG (storage pool) is in the P state. If yes, some PVs (data disks) are lost. | - | | | | - | | | - Joint scheduling: The scheduler can automatically identify an abnormal node and prevent pods that depend on the storage pool from being scheduled to the node. | - | | | | - | | | - Exception scenario: The npd add-on cannot detect the loss of all PVs (data disks), resulting in the loss of VGs (storage pools). In this case, kubelet automatically isolates the node, detects the loss of VGs (storage pools), and updates the corresponding resources in **nodestatus.allocatable** to **0**. This prevents pods that depend on the storage pool from being scheduled to the node. The damage of a single PV cannot be detected. In this case, the ReadonlyFilesystem detection is abnormal. | - +--------------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ - | LocalPvVolumeGroupStatusError | Check the PV group on the node. | | - | | | | - | | Impact: Pods that depend on the storage pool cannot write data to the persistent volume. The persistent volume is remounted as a read-only file system by the kernel due to an I/O error. | | - | | | | - | | Typical scenario: When creating a node, a user configures two data disks as a persistent volume storage pool. Some data disks are deleted by mistake. | | - +--------------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ - | MountPointProblem | Check the mount point on the node. | Alternatively, you can run the following command: | - | | | | - | | Exception definition: You cannot access the mount point by running the **cd** command. | .. code-block:: | - | | | | - | | Typical scenario: Network File System (NFS), for example, obsfs and s3fs is mounted to a node. When the connection is abnormal due to network or peer NFS server exceptions, all processes that access the mount point are suspended. For example, during a cluster upgrade, a kubelet is restarted, and all mount points are scanned. If the abnormal mount point is detected, the upgrade fails. | for dir in `df -h | grep -v "Mounted on" | awk "{print \\$NF}"`;do cd $dir; done && echo "ok" | - +--------------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ - | DiskHung | Check whether I/O faults occur on the disk of the node. | - Check object: all data disks | - | | | | - | | Definition of I/O faults: The system does not respond to disk I/O requests, and some processes are in the D state. | - Source: | - | | | | - | | Typical Scenario: Disks cannot respond due to abnormal OS hard disk drivers or severe faults on the underlying network. | /proc/diskstat | - | | | | - | | | Alternatively, you can run the following command: | - | | | | - | | | .. code-block:: | - | | | | - | | | iostat -xmt 1 | - | | | | - | | | - Threshold: | - | | | | - | | | - Average usage. The value of ioutil is greater than or equal to 0.99. | - | | | - Average I/O queue length. avgqu-sz >=1 | - | | | - Average I/O transfer volume, iops (w/s) + ioth (wMB/s) < = 1 | - | | | | - | | | .. note:: | - | | | | - | | | In some OSs, no data changes during I/O. In this case, calculate the CPU I/O time usage. The value of iowait is greater than 0.8. | - +--------------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ - | DiskSlow | Check whether slow I/O occurs on the disk of the node. | - Check object: all data disks | - | | | | - | | Definition of slow I/O: The average response time exceeds the threshold. | - Source: | - | | | | - | | Typical scenario: EVS disks have slow I/Os due to network fluctuation. | /proc/diskstat | - | | | | - | | | Alternatively, you can run the following command: | - | | | | - | | | .. code-block:: | - | | | | - | | | iostat -xmt 1 | - | | | | - | | | - Threshold: | - | | | | - | | | Average I/O latency: await > = 5000 ms | - | | | | - | | | .. note:: | - | | | | - | | | If I/O requests are not responded and the **await** data is not updated. In this case, this check item is invalid. | - +--------------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + +--------------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | Check Item | Function | Description | + +================================+====================================================================================================================================================================================================================================================================================================================================================================================================+=======================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================+ + | Disk read-only | Periodically perform read and write tests on the system disk and CCE data disks (including the CRI logical disk and Kubelet logical disk) of the node to check the availability of key disks. | Detection paths: | + | | | | + | DiskReadonly | | - /mnt/paas/kubernetes/kubelet/ | + | | | - /var/lib/docker/ | + | | | - /var/lib/containerd/ | + | | | - /var/paas/sys/log/cceaddon-npd/ | + | | | | + | | | The temporary file **npd-disk-write-ping** is generated in the detection path. | + | | | | + | | | Currently, additional data disks are not supported. | + +--------------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | Insufficient disk resources | Check the usage of the system disk and CCE data disks (including the CRI logical disk and kubelet logical disk) on the node. | - Default threshold: 90% | + | | | | + | DiskProblem | | - Source: | + | | | | + | | | .. code-block:: | + | | | | + | | | df -h | + | | | | + | | | Currently, additional data disks are not supported. | + +--------------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | emptyDir storage pool error | Check whether the ephemeral volume group on the node is normal. | - Detection period: 30s | + | | | | + | EmptyDirVolumeGroupStatusError | Impact: The pod that depends on the storage pool cannot write data to the temporary volume. The temporary volume is remounted as a read-only file system by the kernel due to an I/O error. | - Source: | + | | | | + | | Typical scenario: When creating a node, a user configures two data disks as a temporary volume storage pool. The user deletes some data disks by mistake. As a result, the storage pool becomes abnormal. | .. code-block:: | + | | | | + | | | vgs -o vg_name, vg_attr | + | | | | + | | | - Principle: Check whether the VG (storage pool) is in the P state. If yes, some PVs (data disks) are lost. | + | | | | + | | | - Joint scheduling: The scheduler can automatically identify a PV storage pool error and prevent pods that depend on the storage pool from being scheduled to the node. | + | | | | + | | | - Exceptional scenario: The npd add-on cannot detect the loss of all PVs (data disks), resulting in the loss of VGs (storage pools). In this case, kubelet automatically isolates the node, detects the loss of VGs (storage pools), and updates the corresponding resources in **nodestatus.allocatable** to **0**. This prevents pods that depend on the storage pool from being scheduled to the node. The damage of a single PV cannot be detected by this check item, but by the ReadonlyFilesystem check item. | + +--------------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | PV storage pool error | Check the PV group on the node. | | + | | | | + | LocalPvVolumeGroupStatusError | Impact: Pods that depend on the storage pool cannot write data to the persistent volume. The persistent volume is remounted as a read-only file system by the kernel due to an I/O error. | | + | | | | + | | Typical scenario: When creating a node, a user configures two data disks as a persistent volume storage pool. Some data disks are deleted by mistake. | | + +--------------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | Mount point error | Check the mount point on the node. | Alternatively, you can run the following command: | + | | | | + | MountPointProblem | Exceptional definition: You cannot access the mount point by running the **cd** command. | .. code-block:: | + | | | | + | | Typical scenario: Network File System (NFS), for example, obsfs and s3fs is mounted to a node. When the connection is abnormal due to network or peer NFS server exceptions, all processes that access the mount point are suspended. For example, during a cluster upgrade, a kubelet is restarted, and all mount points are scanned. If the abnormal mount point is detected, the upgrade fails. | for dir in `df -h | grep -v "Mounted on" | awk "{print \\$NF}"`;do cd $dir; done && echo "ok" | + +--------------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | Suspended disk I/O | Check whether I/O suspension occurs on all disks on the node, that is, whether I/O read and write operations are not responded. | - Check object: all data disks | + | | | | + | DiskHung | Definition of I/O suspension: The system does not respond to disk I/O requests, and some processes are in the D state. | - Source: | + | | | | + | | Typical scenario: Disks cannot respond due to abnormal OS hard disk drivers or severe faults on the underlying network. | /proc/diskstat | + | | | | + | | | Alternatively, you can run the following command: | + | | | | + | | | .. code-block:: | + | | | | + | | | iostat -xmt 1 | + | | | | + | | | - Threshold: | + | | | | + | | | - Average usage: ioutil >= 0.99 | + | | | - Average I/O queue length: avgqu-sz >= 1 | + | | | - Average I/O transfer volume: iops (w/s) + ioth (wMB/s) <= 1 | + | | | | + | | | .. note:: | + | | | | + | | | In some OSs, no data changes during I/O. In this case, calculate the CPU I/O time usage. The value of iowait should be greater than 0.8. | + +--------------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | Slow disk I/O | Check whether all disks on the node have slow I/Os, that is, whether I/Os respond slowly. | - Check object: all data disks | + | | | | + | DiskSlow | Typical scenario: EVS disks have slow I/Os due to network fluctuation. | - Source: | + | | | | + | | | /proc/diskstat | + | | | | + | | | Alternatively, you can run the following command: | + | | | | + | | | .. code-block:: | + | | | | + | | | iostat -xmt 1 | + | | | | + | | | - Default threshold: | + | | | | + | | | Average I/O latency: await >= 5000 ms | + | | | | + | | | .. note:: | + | | | | + | | | If I/O requests are not responded and the **await** data is not updated, this check item is invalid. | + +--------------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + + .. table:: **Table 5** Other check items + + +--------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------+ + | Check Item | Function | Description | + +==========================+=========================================================================================================================================================================================================+=========================================================================================================================================+ + | Abnormal NTP | Check whether the node clock synchronization service ntpd or chronyd is running properly and whether a system time drift is caused. | Default clock offset threshold: 8000 ms | + | | | | + | NTPProblem | | | + +--------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------+ + | Process D error | Check whether there is a process D on the node. | Default threshold: 10 abnormal processes detected for three consecutive times | + | | | | + | ProcessD | | Source: | + | | | | + | | | - /proc/{PID}/stat | + | | | - Alternately, you can run the **ps aux** command. | + | | | | + | | | Exceptional scenario: ProcessD ignores the resident D processes (heartbeat and update) on which the SDI driver on the BMS node depends. | + +--------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------+ + | Process Z error | Check whether the node has processes in Z state. | | + | | | | + | ProcessZ | | | + +--------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------+ + | ResolvConf error | Check whether the ResolvConf file is lost. | Object: **/etc/resolv.conf** | + | | | | + | ResolvConfFileProblem | Check whether the ResolvConf file is normal. | | + | | | | + | | Exceptional definition: No upstream domain name resolution server (nameserver) is included. | | + +--------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------+ + | Existing scheduled event | Check whether scheduled live migration events exist on the node. A live migration plan event is usually triggered by a hardware fault and is an automatic fault rectification method at the IaaS layer. | Source: | + | | | | + | ScheduledEvent | Typical scenario: The host is faulty. For example, the fan is damaged or the disk has bad sectors. As a result, live migration is triggered for VMs. | - http://169.254.169.254/meta-data/latest/events/scheduled | + | | | | + | | | This check item is an Alpha feature and is disabled by default. | + +--------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------+ The kubelet component has the following default check items, which have bugs or defects. You can fix them by upgrading the cluster or using npd. - .. table:: **Table 5** Default kubelet check items + .. table:: **Table 6** Default kubelet check items - +-----------------------+------------------------------------------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ - | Check Item | Function | Description | - +=======================+========================================================================+==========================================================================================================================================================================================================================================================================================================================+ - | PIDPressure | Check whether PIDs are sufficient. | - Interval: 10 seconds | - | | | - Threshold: 90% | - | | | - Defect: In community version 1.23.1 and earlier versions, this check item becomes invalid when over 65535 PIDs are used. For details, see `issue 107107 `__. In community version 1.24 and earlier versions, thread-max is not considered in this check item. | - +-----------------------+------------------------------------------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ - | MemoryPressure | Check whether the allocable memory for the containers is sufficient. | - Interval: 10 seconds | - | | | - Threshold: Max. 100 MiB | - | | | - Allocable = Total memory of a node - Reserved memory of a node | - | | | - Defect: This check item checks only the memory consumed by containers, and does not consider that consumed by other elements on the node. | - +-----------------------+------------------------------------------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ - | DiskPressure | Check the disk usage and inodes usage of the kubelet and Docker disks. | Interval: 10 seconds | - | | | | - | | | Threshold: 90% | - +-----------------------+------------------------------------------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + +-----------------------------+------------------------------------------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | Check Item | Function | Description | + +=============================+========================================================================+==========================================================================================================================================================================================================================================================================================================================+ + | Insufficient PID resources | Check whether PIDs are sufficient. | - Interval: 10 seconds | + | | | - Threshold: 90% | + | PIDPressure | | - Defect: In community version 1.23.1 and earlier versions, this check item becomes invalid when over 65535 PIDs are used. For details, see `issue 107107 `__. In community version 1.24 and earlier versions, thread-max is not considered in this check item. | + +-----------------------------+------------------------------------------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | Insufficient memory | Check whether the allocable memory for the containers is sufficient. | - Interval: 10 seconds | + | | | - Threshold: max. 100 MiB | + | MemoryPressure | | - Allocable = Total memory of a node - Reserved memory of a node | + | | | - Defect: This check item checks only the memory consumed by containers, and does not consider that consumed by other elements on the node. | + +-----------------------------+------------------------------------------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | Insufficient disk resources | Check the disk usage and inodes usage of the kubelet and Docker disks. | - Interval: 10 seconds | + | | | - Threshold: 90% | + | DiskPressure | | | + +-----------------------------+------------------------------------------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ -.. _cce_10_0132__section1471610580474: +.. _cce_10_0132__en-us_topic_0000001244261007_section1471610580474: Node-problem-controller Fault Isolation --------------------------------------- @@ -285,76 +314,30 @@ Node-problem-controller Fault Isolation Fault isolation is supported only by add-ons of 1.16.0 and later versions. - When installing the npd add-on, set **npc.enable** to **true** to deploy dual Node-problem-controller (NPC). You can deploy NPC as single-instance but such NPC does not ensure high availability. - - By default, if multiple nodes become faulty, NPC adds taints to only one node. You can set **npc.maxTaintedNode** to increase the threshold. When the fault is rectified, NPC is not running and taints remain. You need to manually clear the taints or start NPC. + By default, if multiple nodes become faulty, NPC adds taints to up to 10% of the nodes. You can set **npc.maxTaintedNode** to increase the threshold. The open source NPD plug-in provides fault detection but not fault isolation. CCE enhances the node-problem-controller (NPC) based on the open source NPD. This component is implemented based on the Kubernetes `node controller `__. For faults reported by NPD, NPC automatically adds taints to nodes for node fault isolation. -You can modify **add-onnpc.customConditionToTaint** according to the following table to configure fault isolation rules. +.. _cce_10_0132__en-us_topic_0000001244261007_table205378534248: -.. table:: **Table 6** Parameters +.. table:: **Table 7** Parameters - +--------------------------------+---------------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------+ - | Parameter | Description | Default | - +================================+=========================================================+=========================================================================================================================================+ - | npc.enable | Whether to enable NPC | true | - +--------------------------------+---------------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------+ - | npc.customCondtionToTaint | Fault isolation rules | See :ref:`Table 7 `. | - +--------------------------------+---------------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------+ - | npc.customConditionToTaint[i] | Fault isolation rule items | N/A | - +--------------------------------+---------------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------+ - | npc.customConditionToTaint[i]. | Fault status | true | - | | | | - | condition.status | | | - +--------------------------------+---------------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------+ - | npc.customConditionToTaint[i]. | Fault type | N/A | - | | | | - | condition.type | | | - +--------------------------------+---------------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------+ - | npc.customConditionToTaint[i]. | Whether to enable the fault isolation rule. | false | - | | | | - | enable | | | - +--------------------------------+---------------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------+ - | npc.customConditionToTaint[i]. | Fault isolation effect | NoSchedule | - | | | | - | .taint.effect | NoSchedule, PreferNoSchedule, or NoExecute | Value options: **NoSchedule**, **PreferNoSchedule**, and **NoExecute** | - +--------------------------------+---------------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------+ - | npc. maxTaintedNode | Number of nodes in a cluster that can be tainted by NPC | 1 | - | | | | - | | The int format and percentage format are supported. | Values: | - | | | | - | | | - The value is in int format and ranges from 1 to infinity. | - | | | - The value ranges from 1% to 100%, in percentage. The minimum value of this parameter multiplied by the number of cluster nodes is 1. | - +--------------------------------+---------------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------+ - | Npc.affinity | Node affinity of the controller | N/A | - +--------------------------------+---------------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------+ - -.. _cce_10_0132__table147438134911: - -.. table:: **Table 7** Fault isolation rule configuration - - +---------------------------+---------------------------------------------------------------------+--------------------------------------+ - | Fault | Fault Details | Taint | - +===========================+=====================================================================+======================================+ - | DiskReadonly | Disk read-only | **NoSchedule**: No new pods allowed. | - +---------------------------+---------------------------------------------------------------------+--------------------------------------+ - | DiskProblem | The disk space is insufficient, and key logical disks are detached. | **NoSchedule**: No new pods allowed. | - +---------------------------+---------------------------------------------------------------------+--------------------------------------+ - | FrequentKubeletRestart | kubelet restarts frequently. | **NoSchedule**: No new pods allowed. | - +---------------------------+---------------------------------------------------------------------+--------------------------------------+ - | FrequentDockerRestart | Docker restarts frequently. | **NoSchedule**: No new pods allowed. | - +---------------------------+---------------------------------------------------------------------+--------------------------------------+ - | FrequentContainerdRestart | containerd restarts frequently. | **NoSchedule**: No new pods allowed. | - +---------------------------+---------------------------------------------------------------------+--------------------------------------+ - | KUBEPROXYProblem | kube-proxy is abnormal. | **NoSchedule**: No new pods allowed. | - +---------------------------+---------------------------------------------------------------------+--------------------------------------+ - | PIDProblem | Insufficient PIDs | **NoSchedule**: No new pods allowed. | - +---------------------------+---------------------------------------------------------------------+--------------------------------------+ - | FDProblem | Insufficient file handles | **NoSchedule**: No new pods allowed. | - +---------------------------+---------------------------------------------------------------------+--------------------------------------+ - | MemoryProblem | Insufficient node memory | **NoSchedule**: No new pods allowed. | - +---------------------------+---------------------------------------------------------------------+--------------------------------------+ + +-----------------------+--------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------+ + | Parameter | Description | Default | + +=======================+====================================================================================================================+=========================================================================================================================================+ + | npc.enable | Whether to enable NPC | true | + | | | | + | | NPC cannot be disabled in 1.18.0 or later versions. | | + +-----------------------+--------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------+ + | npc. maxTaintedNode | Check how many nodes can npc add taints to for mitigating the impact when a single fault occurs on multiple nodes. | 10% | + | | | | + | | The int format and percentage format are supported. | Value range: | + | | | | + | | | - The value is in int format and ranges from 1 to infinity. | + | | | - The value ranges from 1% to 100%, in percentage. The minimum value of this parameter multiplied by the number of cluster nodes is 1. | + +-----------------------+--------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------+ + | npc.affinity | Node affinity of the controller | N/A | + +-----------------------+--------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------+ Collecting Prometheus Metrics ----------------------------- diff --git a/umn/source/add-ons/overview.rst b/umn/source/add-ons/overview.rst index ce588ac..cdb5d04 100644 --- a/umn/source/add-ons/overview.rst +++ b/umn/source/add-ons/overview.rst @@ -7,6 +7,10 @@ Overview CCE provides multiple types of add-ons to extend cluster functions and meet feature requirements. You can install add-ons as required. +.. important:: + + CCE uses Helm templates to deploy add-ons. To modify or upgrade an add-on, perform operations on the **Add-ons** page or use open APIs. Do not directly modify resources related to add-ons in the background. Otherwise, add-on exceptions or other unexpected problems may occur. + .. table:: **Table 1** Add-on list +-------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ diff --git a/umn/source/add-ons/volcano.rst b/umn/source/add-ons/volcano.rst index 34772c3..0c7352d 100644 --- a/umn/source/add-ons/volcano.rst +++ b/umn/source/add-ons/volcano.rst @@ -48,11 +48,16 @@ Installing the Add-on | 400/4w | 2500 | 4000 | 4500 | 5500 | +--------------------+----------------+--------------+--------------------+------------------+ +#. Select whether to deploy the add-on pods across multiple AZs. + + - **Preferred**: Deployment pods of the add-on are preferentially scheduled to nodes in different AZs. If the nodes in the cluster do not meet the requirements of multiple AZs, the pods are scheduled to a single AZ. + - **Required**: Deployment pods of the add-on are forcibly scheduled to nodes in different AZs. If the nodes in the cluster do not meet the requirements of multiple AZs, not all pods can run. + #. Parameters of the volcano default scheduler. For details, see :ref:`Table 2 `. .. code-block:: - ca_cert: '' + colocation_enable: '' default_scheduler_conf: actions: 'allocate, backfill' tiers: @@ -73,8 +78,6 @@ Installing the Add-on - name: 'nodeemptydirvolume' - name: 'nodeCSIscheduling' - name: 'networkresource' - server_cert: '' - server_key: '' .. _cce_10_0193__table562185146: @@ -83,10 +86,10 @@ Installing the Add-on +----------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+--------------------------------------------------------------------------------------------------------------------------+-------------------------------------------------------------+ | Add-on | Function | Description | Demonstration | +============================+=============================================================================================================================================================================================================================+==========================================================================================================================+=============================================================+ - | binpack | The binpack plugin schedules pods to nodes with high resource utilization to reduce resource fragments. | - **binpack.weight**: Weight of the binpack plugin. | .. code-block:: | - | | | - **binpack.cpu**: Ratio of CPU resources to all resources. Defaults to **1**. | | + | binpack | Schedules pods to nodes with high resource utilization to reduce resource fragments. | - **binpack.weight**: Weight of the binpack plugin. | .. code-block:: | + | | | - **binpack.cpu**: ratio of CPU resources to all resources. Defaults to **1**. | | | | | - **binpack.memory**: Ratio of memory resources to all resources. Defaults to **1**. | - plugins: | - | | | - binpack.resources: | - name: binpack | + | | | - **binpack.resources**: resource type. | - name: binpack | | | | | arguments: | | | | | binpack.weight: 10 | | | | | binpack.cpu: 1 | diff --git a/umn/source/auto_scaling/scaling_a_node/creating_a_node_scaling_policy.rst b/umn/source/auto_scaling/scaling_a_node/creating_a_node_scaling_policy.rst index aa2a7fc..3ee3258 100644 --- a/umn/source/auto_scaling/scaling_a_node/creating_a_node_scaling_policy.rst +++ b/umn/source/auto_scaling/scaling_a_node/creating_a_node_scaling_policy.rst @@ -15,7 +15,7 @@ If a node scaling policy and the configuration in the autoscaler add-on take eff Prerequisites ------------- -Before using the node scaling function, you must install the :ref:`autoscaler ` add-on of v1.13.8 or later. +Before using the node scaling function, you must install the :ref:`autoscaler ` add-on of v1.13.8 or later in the cluster. Notes and Constraints --------------------- @@ -37,18 +37,6 @@ Procedure - **Associated Node Pools**: Select the node pool to be associated. You can associate multiple node pools to use the same scaling policy. - .. note:: - - Priority is now supported for node pools. CCE will select a node pool for auto scaling based on the following policies: - - a. CCE uses algorithms to determine whether a node pool meets the conditions to allow scheduling of a pod in pending state, including whether the node resources are greater than requested by the pod, and whether the nodeSelect, nodeAffinity, and taints meet the conditions. In addition, the node pools that fail to be scaled (due to insufficient resources or other reasons) and are still in the 15-minute cool-down interval are filtered. - b. If multiple node pools meet the scaling requirements, the system checks the priority of each node pool and selects the node pool with the highest priority for scaling. The value ranges from 0 to 100 and the default priority is 0. The value 100 indicates the highest priority, and the value 0 indicates the lowest priority. - c. If multiple node pools have the same priority or no priority is configured for them, the system selects the node pool that will consume the least resources based on the configured VM specification. - d. If the VM specifications of multiple node pools are the same but the node pools are deployed in different AZs, the system randomly selects a node pool to trigger scaling. - e. If the resources of the preferred node pool are insufficient, the system automatically selects next node pool based on the priority. - - For details about the node pool priority, see :ref:`Creating a Node Pool `. - - **Rules**: Click **Add Rule**. In the dialog box displayed, set the following parameters: **Rule Name**: Enter a rule name. diff --git a/umn/source/auto_scaling/scaling_a_node/managing_node_scaling_policies.rst b/umn/source/auto_scaling/scaling_a_node/managing_node_scaling_policies.rst index 2c49103..e99d4b6 100644 --- a/umn/source/auto_scaling/scaling_a_node/managing_node_scaling_policies.rst +++ b/umn/source/auto_scaling/scaling_a_node/managing_node_scaling_policies.rst @@ -58,4 +58,4 @@ Enabling or Disabling a Node Scaling Policy #. Choose **Node Scaling** in the navigation pane and click **Disable** in the **Operation** column of the policy to be disabled. If the policy is in the disabled state, click **Enable** in the **Operation** column of the policy. #. In the dialog box displayed, confirm whether to disable or enable the node policy. -.. |image1| image:: /_static/images/en-us_image_0000001244261161.png +.. |image1| image:: /_static/images/en-us_image_0000001517743464.png diff --git a/umn/source/auto_scaling/scaling_a_node/node_scaling_mechanisms.rst b/umn/source/auto_scaling/scaling_a_node/node_scaling_mechanisms.rst index d117a1a..0fab9e6 100644 --- a/umn/source/auto_scaling/scaling_a_node/node_scaling_mechanisms.rst +++ b/umn/source/auto_scaling/scaling_a_node/node_scaling_mechanisms.rst @@ -19,7 +19,7 @@ How autoscaler Works The cluster autoscaler (CA) goes through two processes. -- Scale-out: The CA checks all unschedulable pods every 10 seconds and selects a node group that meets the requirements for scale-out based on the policy you set. +- Scale-out: The CA checks all unschedulable pods every 10 seconds and selects a node pool that meets the requirements for scale-out based on the policy you set. - Scale-in: The CA scans all nodes every 10 seconds. If the number of pod requests on a node is less than the user-defined percentage for scale-in, the CA simulates whether the pods on the node can be migrated to other nodes. If yes, the node will be removed after an idle time window. As described above, if a cluster node is idle for a period of time (10 minutes by default), scale-in is triggered, and the idle node is removed. @@ -29,7 +29,7 @@ However, a node cannot be removed from a cluster if the following pods exist: #. Pods that do not meet specific requirements set in PodDisruptionBudget #. Pods that cannot be scheduled to other nodes due to constraints such as affinity and anti-affinity policies #. Pods that have the **"cluster-autoscaler.kubernetes.io/safe-to-evict": "false"** annotation -#. Pods (except those created by kube-system DaemonSet) that exist in the kube-system namespace on the node +#. Pods (except those created by DaemonSets in the kube-system namespace) that exist in the kube-system namespace on the node #. Pods that are not created by the controller (Deployment/ReplicaSet/job/StatefulSet) autoscaler Architecture @@ -39,7 +39,7 @@ autoscaler Architecture .. _cce_10_0296__fig114831750115719: -.. figure:: /_static/images/en-us_image_0000001199501290.png +.. figure:: /_static/images/en-us_image_0000001569182553.png :alt: **Figure 1** autoscaler architecture **Figure 1** autoscaler architecture diff --git a/umn/source/auto_scaling/scaling_a_workload/managing_workload_scaling_policies.rst b/umn/source/auto_scaling/scaling_a_workload/managing_workload_scaling_policies.rst index d38baef..86c6967 100644 --- a/umn/source/auto_scaling/scaling_a_workload/managing_workload_scaling_policies.rst +++ b/umn/source/auto_scaling/scaling_a_workload/managing_workload_scaling_policies.rst @@ -84,4 +84,4 @@ Deleting an HPA Policy #. In the navigation pane, choose **Workload Scaling**. Click **Delete** in the **Operation** column of the target policy. #. In the dialog box displayed, click **Yes**. -.. |image1| image:: /_static/images/en-us_image_0000001244261103.png +.. |image1| image:: /_static/images/en-us_image_0000001568902521.png diff --git a/umn/source/auto_scaling/using_hpa_and_ca_for_auto_scaling_of_workloads_and_nodes.rst b/umn/source/auto_scaling/using_hpa_and_ca_for_auto_scaling_of_workloads_and_nodes.rst index 5acb210..160a23a 100644 --- a/umn/source/auto_scaling/using_hpa_and_ca_for_auto_scaling_of_workloads_and_nodes.rst +++ b/umn/source/auto_scaling/using_hpa_and_ca_for_auto_scaling_of_workloads_and_nodes.rst @@ -23,7 +23,7 @@ As shown in :ref:`Figure 1 ` - :ref:`Adding a Second Data Disk to a Node in a CCE Cluster ` +- :ref:`Selecting a Data Disk for the Node ` .. toctree:: :maxdepth: 1 @@ -14,3 +15,4 @@ Cluster connecting_to_multiple_clusters_using_kubectl adding_a_second_data_disk_to_a_node_in_a_cce_cluster + selecting_a_data_disk_for_the_node diff --git a/umn/source/best_practice/cluster/selecting_a_data_disk_for_the_node.rst b/umn/source/best_practice/cluster/selecting_a_data_disk_for_the_node.rst new file mode 100644 index 0000000..004f454 --- /dev/null +++ b/umn/source/best_practice/cluster/selecting_a_data_disk_for_the_node.rst @@ -0,0 +1,178 @@ +:original_name: cce_bestpractice_10012.html + +.. _cce_bestpractice_10012: + +Selecting a Data Disk for the Node +================================== + +When a node is created, a data disk is created by default for container runtime and kubelet components to use. The data disk used by the container runtime and kubelet components cannot be detached, and the default size is 100 GB. To reduce costs, the size of a common data disk attached to a node can be reduced to 10 GB. + +.. important:: + + Adjusting the size of the data disk used by the container and Kubelet component may cause risks. You are advised to adjust the size after comprehensive evaluation based on the estimation method provided in this section. + + - If the data disk capacity is too small, the disk space may be insufficient. As a result, the image fails to be pulled. If different images need to be frequently pulled on the node, you are not advised to reduce the data disk capacity. + - During the cluster upgrade pre-check, the system checks whether the data disk usage exceeds 95%. If the disk pressure is high, the cluster upgrade may be affected. + - If Device Mapper is used, the disk space may be insufficient. You are advised to use the OverlayFS or select a large-capacity data disk. + - For dumping logs, application logs must be stored in a separate disk to prevent insufficient space of the dockersys partition from affecting service running. + + - After reducing the data disk capacity, you are advised to install a npd add-on in the cluster to detect node disk pressure. If the disk pressure of a node is high, rectify the fault by referring to :ref:`What Do I Do If the Data Disk Space Is Insufficient? `. + +Notes and Constraints +--------------------- + +- Only clusters of v1.19 or later support reducing the data disk capacity used by running containers and kubelet components. +- Only the EVS disk capacity can be adjusted. (Local disks are available only when the node specification is **disk-intensive** or **Ultra-high I/O**.) + +Selecting a Data Disk +--------------------- + +When selecting a proper data disk, consider the following factors: + +- During image pulling, the system downloads the image .tar package from the image repository, decompresses the package, and deletes the TAR package to retain the image file. During the decompression of the .tar package, the .tar package and the decompressed image file coexist, occupying extra storage space. Pay attention to this when calculating the required data disk capacity. +- During cluster creation, mandatory add-ons (such as everest and coredns add-ons) may be deployed on nodes, occupying certain space. When calculating the data disk size, reserve about 2 GB space for them. +- Logs are generated during application running and occupy certain space. To ensure normal service running, reserve about 1 GB space for each pod. + +For details about the calculation formulas, see :ref:`OverlayFS ` and :ref:`Device Mapper `. + +.. _cce_bestpractice_10012__section97181505230: + +OverlayFS +--------- + +By default, the container engine and container image space on OverlayFS nodes occupy 90% of the data disk space (you are advised to retain this value). All the space is used for the dockersys partition. The calculation formula is as follows: + +- .. _cce_bestpractice_10012__li14531528269: + + Container engine and container image space: Defaults to 90%. Space size = Data disk space x 90% + + - dockersys partition (**/var/lib/docker** path): The entire container engine and container image space (90% of the data disk by default) are in the **/var/lib/docker** directory. Space size = Data disk space x 90% + +- kubelet components and emptyDir volumes space: 10% of the data disk space. Space size = Data disk space x 10% + +On an OverlayFS node, when an image is pulled, the .tar package is decompressed after being downloaded. During this process, the .tar package and the decompressed image file are stored in the dockersys space at the same time, occupying about twice the actual image capacity, after the decompression is complete, the .tar package is deleted. Therefore, in the actual image pulling process, after deducting the space occupied by the system add-on image, ensure that the remaining space of the dockersys partition is greater than twice the actual image capacity. To ensure that the container can run properly, you need to reserve pod space in the dockersys partition for container logs and other related files. + +A proper data disk should meet the following formula: + +**dockersys partition capacity > 2 x Actual total image capacity + Total system add-on image capacity (about 2 GB) + Number of containers x Available space for a single container (about 1 GB log space)** + +.. note:: + + If container logs are output in the json.log format, the dockersys partition is occupied. If persistent storage is configured for container logs, the dockersys partition is not occupied. Estimate the space of a single container as required. + +Example: + +Assume that the storage type of the node is OverlayFS and the data disk size of the node is 20 GB. According to :ref:`the preceding formula `, the default ratio of the container engine and image space is 90%. Therefore, the dockersys partition disk usage is 18 GB (20 GB x 90%). In addition, mandatory add-ons may occupy about 2 GB space during cluster creation. If you deploy a .tar image package of 10 GB, 20 GB dockersys space is occupied by the decompressed package. In addition, the space occupied by mandatory add-ons exceeds the remaining space of dockersys. As a result, the image may fail to be pulled. + +.. _cce_bestpractice_10012__section212373119234: + +Device Mapper +------------- + +By default, the container engine and image space on Device Mapper nodes occupy 90% of the data disk space (recommended). This 90% capacity is divided into the dockersys partition and thinpool space. The calculation formula is as follows: + +- .. _cce_bestpractice_10012__li1519941320114: + + Container engine and image space: 90% of the data disk space by default. Space size = Data disk space x 90% + + - dockersys partition (**/var/lib/docker** path): Defaults to 20%. Space size = Data disk space x 90% x 20% + - thinpool space: Defaults to 80%. Space size = Data disk space x 90% x 80% + +- kubelet and emptyDir space: occupy 10%. Space size = Data disk space x 10% + +On a Device Mapper node, when an image is pulled, the TAR package is temporarily stored in the dockersys partition. After the TAR package is decompressed, the image file is stored in the thinpool space. Finally, the TAR package in the dockersys space is deleted. Therefore, during image pulling, ensure that the dockersys partition space and thinpool space are sufficient. The dockersys space is smaller than the thinpool space. Pay attention to this when calculating the data disk space. To ensure that a container can run properly, reserve pod space in the dockersys partition to store container logs and other related files. + +A proper data disk should meet the following formula: + +- **dockersys partition capacity > temporary storage space of the TAR package (approximately equal to the actual total image capacity) + Number of containers x Space of a single container (about 1 GB log space must be reserved for each container)** +- **thinpool space > Actual total image capacity + Total add-on image capacity (about 2 GB)** + +.. note:: + + If container logs are output in the json.log format, the dockersys partition is occupied. If persistent storage is configured for container logs, the dockersys partition is not occupied. Estimate the space of a single container as required. + +Example: + +Assume that the storage type of the node is Device Mapper and the data disk size of the node is 20 GB. According to :ref:`the preceding formula `, the default ratio of the container engine and image space is 90%. Therefore, the dockersys partition disk usage is: 20 GB x 90% x 20% = 3.6 GB. In addition, mandatory add-ons may occupy about 2 GB dockersys space during cluster creation. Therefore, the remaining space is about 1.6 GB. If you deploy a .tar image package larger than 1.6 GB, the dockersys partition space is insufficient when the package is decompressed. As a result, the image may fail to be pulled. + +.. _cce_bestpractice_10012__section094517492470: + +What Do I Do If the Data Disk Space Is Insufficient? +---------------------------------------------------- + +**Solution 1: Clearing Images** + +You can run the following command to clear unused Docker images: + +.. code-block:: + + docker system prune -a + +.. note:: + + This command will delete all Docker images that are not used. Exercise caution when running this command. + +**Solution 2: Expanding the Disk Capacity** + +#. Expand the capacity of the data disk on the EVS console. + +#. Log in to the CCE console and click the cluster. In the navigation pane, choose **Nodes**. Click **More** > **Sync Server Data** at the row containing the target node. + +#. Log in to the target node. + +#. Run the **lsblk** command to check the block device information of the node. + + A data disk is divided depending on the container storage **Rootfs**: + + - Overlayfs: No independent thin pool is allocated. Image data is stored in the **dockersys** disk. + + .. code-block:: + + # lsblk + NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT + sda 8:0 0 50G 0 disk + └─sda1 8:1 0 50G 0 part / + sdb 8:16 0 200G 0 disk + ├─vgpaas-dockersys 253:0 0 90G 0 lvm /var/lib/docker # Space used by Docker. + └─vgpaas-kubernetes 253:1 0 10G 0 lvm /mnt/paas/kubernetes/kubelet # Space used by Kubernetes. + + Run the following commands on the node to add the new disk capacity to the **dockersys** disk: + + .. code-block:: + + pvresize /dev/sdb + lvextend -l+100%FREE -n vgpaas/dockersys + resize2fs /dev/vgpaas/dockersys + + - Devicemapper: A thin pool is allocated to store image data. + + .. code-block:: + + # lsblk + NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT + sda 8:0 0 50G 0 disk + └─sda1 8:1 0 50G 0 part / + sdb 8:16 0 200G 0 disk + ├─vgpaas-dockersys 253:0 0 18G 0 lvm /var/lib/docker + ├─vgpaas-thinpool_tmeta 253:1 0 3G 0 lvm + │ └─vgpaas-thinpool 253:3 0 67G 0 lvm # Thin pool space. + │ ... + ├─vgpaas-thinpool_tdata 253:2 0 67G 0 lvm + │ └─vgpaas-thinpool 253:3 0 67G 0 lvm + │ ... + └─vgpaas-kubernetes 253:4 0 10G 0 lvm /mnt/paas/kubernetes/kubelet + + - Run the following commands on the node to add the new disk capacity to the **thinpool** disk: + + .. code-block:: + + pvresize /dev/sdb + lvextend -l+100%FREE -n vgpaas/thinpool + + - Run the following commands on the node to add the new disk capacity to the **dockersys** disk: + + .. code-block:: + + pvresize /dev/sdb + lvextend -l+100%FREE -n vgpaas/dockersys + resize2fs /dev/vgpaas/dockersys diff --git a/umn/source/best_practice/container/configuring_core_dumps.rst b/umn/source/best_practice/container/configuring_core_dumps.rst index 74c28dc..dc8c7cb 100644 --- a/umn/source/best_practice/container/configuring_core_dumps.rst +++ b/umn/source/best_practice/container/configuring_core_dumps.rst @@ -12,6 +12,11 @@ Linux allows you to create a core dump file if an application crashes, which con Generally, when a service application crashes, its container exits and is reclaimed and destroyed. Therefore, container core files need to be permanently stored on the host or cloud storage. This topic describes how to configure container core dumps. +Notes and Constraints +--------------------- + +When a container core dump is persistently stored to OBS (parallel file system or object bucket), the default mount option **umask=0** is used. As a result, although the core dump file is generated, the core dump information cannot be written to the core file. + Enabling Core Dump on a Node ---------------------------- @@ -19,13 +24,15 @@ Log in to the node, run the following command to enable core dump, and set the p **echo "/tmp/cores/core.%h.%e.%p.%t" > /proc/sys/kernel/core_pattern** -Parameters: +**%h**, **%e**, **%p**, and **%t** are placeholders, which are described as follows: - **%h**: host name (or pod name). You are advised to configure this parameter. - **%e**: program file name. You are advised to configure this parameter. - **%p**: (optional) process ID. - **%t**: (optional) time of the core dump. +After the core dump function is enabled by running the preceding command, the generated core file is named in the format of **core.{Host name}.{Program file name}.{Process ID}.{Time}**. + You can also configure a pre-installation or post-installation script to automatically run this command when creating a node. Permanently Storing Core Dumps diff --git a/umn/source/best_practice/containerization/containerizing_an_enterprise_application_erp/index.rst b/umn/source/best_practice/containerization/containerizing_an_enterprise_application_erp/index.rst new file mode 100644 index 0000000..96339a7 --- /dev/null +++ b/umn/source/best_practice/containerization/containerizing_an_enterprise_application_erp/index.rst @@ -0,0 +1,16 @@ +:original_name: cce_bestpractice_0001.html + +.. _cce_bestpractice_0001: + +Containerizing an Enterprise Application (ERP) +============================================== + +- :ref:`Solution Overview ` +- :ref:`Procedure ` + +.. toctree:: + :maxdepth: 1 + :hidden: + + solution_overview + procedure/index diff --git a/umn/source/best_practice/containerization/containerizing_an_enterprise_application_erp/procedure/analyzing_the_application.rst b/umn/source/best_practice/containerization/containerizing_an_enterprise_application_erp/procedure/analyzing_the_application.rst new file mode 100644 index 0000000..9ae3480 --- /dev/null +++ b/umn/source/best_practice/containerization/containerizing_an_enterprise_application_erp/procedure/analyzing_the_application.rst @@ -0,0 +1,53 @@ +:original_name: cce_bestpractice_0005.html + +.. _cce_bestpractice_0005: + +Analyzing the Application +========================= + +Before containerizing an application, you need to analyze the running environment and dependencies of the application, and get familiar with the application deployment mode. For details, see :ref:`Table 1 `. + +.. _cce_bestpractice_0005__table1893834493714: + +.. table:: **Table 1** Application environment + + +-----------------------+----------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | Item | Sub-category | Description | + +=======================+============================+=========================================================================================================================================================================================================================================================================+ + | Runtime environment | OS | OS that the application runs on, such as CentOS or Ubuntu. | + | | | | + | | | In this example, the application runs on CentOS 7.1. | + +-----------------------+----------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | | Runtime environment | The Java application requires Java Development Kit (JDK), the Go language requires GoLang, the web application requires Tomcat environment, and the corresponding version number needs to be confirmed. | + | | | | + | | | In this example, the web application of the Tomcat type is used. This application requires the runtime environment of Tomcat 7.0, and Tomcat requires JDK 1.8. | + +-----------------------+----------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | | Dependency package | Understand required dependency packages, such as OpenSSL and other system software, and their version numbers. | + | | | | + | | | In this example, no dependency package is required. | + +-----------------------+----------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | Deployment mode | Peripheral configurations | MongoDB database: In this example, the MongoDB database and Tomcat application are deployed on the same server. Therefore, their configurations can be fixed and there is no need to extract their configurations. | + +-----------------------+----------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | | | External services with which the application needs to interconnect, such as databases and file systems. | + | | | | + | | | These configurations need to be manually configured each time you deploy an application on a VM. However, through containerized deployment, environment variables can be injected into a container, facilitating deployment. | + | | | | + | | | In this example, the application needs to interconnect with the MySQL database. You need to obtain the database configuration file. The server address, database name, database login username, and database login password are injected through environment variables. | + | | | | + | | | .. code-block:: | + | | | | + | | | url=jdbc:mysql://Server address/Database name #Database connection URL | + | | | username=**** #Username for logging in to the database | + | | | password=**** #Password for logging in to the database | + +-----------------------+----------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | | Application configurations | You need to sort out the configuration parameters, such as configurations that need to be modified frequently and those remain unchanged during the running of the application. | + | | | | + | | | In this example, no application configurations need to be extracted. | + | | | | + | | | .. note:: | + | | | | + | | | To avoid frequent image replacement, you are advised to classify configurations of the application. | + | | | | + | | | - For the configurations (such as peripheral interconnection information and log levels) that are frequently changed, you are advised to configure them as environment variables. | + | | | - For the configurations that remain unchanged, directly write them into images. | + +-----------------------+----------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ diff --git a/umn/source/best_practice/containerization/containerizing_an_enterprise_application_erp/procedure/building_and_uploading_an_image.rst b/umn/source/best_practice/containerization/containerizing_an_enterprise_application_erp/procedure/building_and_uploading_an_image.rst new file mode 100644 index 0000000..60f7e0b --- /dev/null +++ b/umn/source/best_practice/containerization/containerizing_an_enterprise_application_erp/procedure/building_and_uploading_an_image.rst @@ -0,0 +1,46 @@ +:original_name: cce_bestpractice_0009.html + +.. _cce_bestpractice_0009: + +Building and Uploading an Image +=============================== + +This section describes how to build an entire application into a Docker image. After building an image, you can use the image to deploy and upgrade the application. This reduces manual configuration and improves efficiency. + +.. note:: + + When building an image, ensure that files used to build the image are stored in the same directory. + +Required Cloud Services +----------------------- + +SoftWare Repository for Container (SWR) provides easy, secure, and reliable management over container images throughout their lifecycle, facilitating the deployment of containerized services. + +Basic Concepts +-------------- + +- Image: A Docker image is a special file system that includes everything needed to run containers: programs, libraries, resources, settings, and so on. It also includes corresponding configuration parameters (such as anonymous volumes, environment variables, and users) required within a container runtime. An image does not contain any dynamic data, and its content remains unchanged after being built. +- Container: Images become containers at runtime, that is, containers are created from images. A container can be created, started, stopped, deleted, or suspended. + +Procedure +--------- + +#. Log in as the **root** user to the device running Docker. + +#. Enter the **apptest** directory. + + **cd apptest** + + **ll** + + Ensure that files used to build the image are stored in the same directory. + + |image1| + +#. Build an image. + + **docker build -t apptest .** + +#. Upload the image to the SWR service. For details, see `Uploading an Image Through the Client `__. + +.. |image1| image:: /_static/images/en-us_image_0091292713.png diff --git a/umn/source/best_practice/containerization/containerizing_an_enterprise_application_erp/procedure/compiling_a_startup_script.rst b/umn/source/best_practice/containerization/containerizing_an_enterprise_application_erp/procedure/compiling_a_startup_script.rst new file mode 100644 index 0000000..e32f058 --- /dev/null +++ b/umn/source/best_practice/containerization/containerizing_an_enterprise_application_erp/procedure/compiling_a_startup_script.rst @@ -0,0 +1,46 @@ +:original_name: cce_bestpractice_0007.html + +.. _cce_bestpractice_0007: + +Compiling a Startup Script +========================== + +During application containerization, you need to prepare a startup script. The method of compiling this script is the same as that of compiling a shell script. The startup script is used to: + +- Start up the software on which the application depends. +- Set the configurations that need to be changed as the environment variables. + +.. note:: + + Startup scripts vary according to applications. You need to compile the script based on your service requirements. + +Procedure +--------- + +#. Log in as user **root** to the device running Docker. + +#. Run the following commands to create the directory where the application is to be stored: + + **mkdir apptest** + + **cd apptest** + +#. .. _cce_bestpractice_0007__li12314175319811: + + Compile a script file. The name and content of the script file vary according to applications. You need to compile the script file based on your application. The following example is only for your reference. + + **vi** **start_tomcat_and_mongo.sh** + + .. code-block:: + + #!/bin/bash + # Load system environment variables. + source /etc/profile + # Start MongoDB. The data is stored in /usr/local/mongodb/data. + ./usr/local/mongodb/bin/mongod --dbpath=/usr/local/mongodb/data --logpath=/usr/local/mongodb/logs --port=27017 -fork + # These three script commands indicate that the contents related to the MySQL database in the environment variables are written into the configuration file when Docker is started. + sed -i "s|mysql://.*/awcp_crmtile|mysql://$MYSQL_URL/$MYSQL_DB|g" /root/apache-tomcat-7.0.82/webapps/awcp/WEB-INF/classes/conf/jdbc.properties + sed -i "s|username=.*|username=$MYSQL_USER|g" /root/apache-tomcat-7.0.82/webapps/awcp/WEB-INF/classes/conf/jdbc.properties + sed -i "s|password=.*|password=$MYSQL_PASSWORD|g" /root/apache-tomcat-7.0.82/webapps/awcp/WEB-INF/classes/conf/jdbc.properties + # Start Tomcat. + bash /root/apache-tomcat-7.0.82/bin/catalina.sh run diff --git a/umn/source/best_practice/containerization/containerizing_an_enterprise_application_erp/procedure/compiling_the_dockerfile.rst b/umn/source/best_practice/containerization/containerizing_an_enterprise_application_erp/procedure/compiling_the_dockerfile.rst new file mode 100644 index 0000000..46db0ba --- /dev/null +++ b/umn/source/best_practice/containerization/containerizing_an_enterprise_application_erp/procedure/compiling_the_dockerfile.rst @@ -0,0 +1,64 @@ +:original_name: cce_bestpractice_0008.html + +.. _cce_bestpractice_0008: + +Compiling the Dockerfile +======================== + +An image is the basis of a container. A container runs based on the content defined in the image. An image has multiple layers. Each layer includes the modifications made based on the previous layer. + +Generally, Dockerfiles are used to customize images. Dockerfile is a text file and contains various instructions. Each instruction is used to build an image layer. That is, each instruction describes how to build an image layer. + +This section describes how to compile a Dockerfile file. + +.. note:: + + Dockerfiles vary according to applications. Dockerfiles need to be compiled based on actual service requirements. + +Procedure +--------- + +#. Log in as the **root** user to the device running Docker. + +#. Write a Dockerfile. + + **vi Dockerfile** + + The following provides an example Dockerfile: + + .. code-block:: + + # Centos:7.1.1503 is used as the base image. + FROM centos:7.1.1503 + # Create a folder to store data and dependency files. You are advised to write multiple commands into one line to reduce the image size. + RUN mkdir -p /usr/local/mongodb/data \ + && mkdir -p /usr/local/mongodb/bin \ + && mkdir -p /root/apache-tomcat-7.0.82 \ + && mkdir -p /root/jdk1.8.0_151 + + # Copy the files in the apache-tomcat-7.0.82 directory to the container path. + COPY ./apache-tomcat-7.0.82 /root/apache-tomcat-7.0.82 + # Copy the files in the jdk1.8.0_151 directory to the container path. + COPY ./jdk1.8.0_151 /root/jdk1.8.0_151 + # Copy the files in the mongodb-linux-x86_64-rhel70-3.2.9 directory to the container path. + COPY ./mongodb-linux-x86_64-rhel70-3.2.9/bin /usr/local/mongodb/bin + # Copy start_tomcat_and_mongo.sh to the /root directory of the container. + COPY ./start_tomcat_and_mongo.sh /root/ + + # Enter Java environment variables. + RUN chown root:root -R /root \ + && echo "JAVA_HOME=/root/jdk1.8.0_151 " >> /etc/profile \ + && echo "PATH=\$JAVA_HOME/bin:$PATH " >> /etc/profile \ + && echo "CLASSPATH=.:\$JAVA_HOME/lib/dt.jar:\$JAVA_HOME/lib/tools.jar" >> /etc/profile \ + && chmod +x /root \ + && chmod +x /root/start_tomcat_and_mongo.sh + + # When the container is started, commands in start_tomcat_and_mongo.sh are automatically run. The file can be one or more commands, or a script. + ENTRYPOINT ["/root/start_tomcat_and_mongo.sh"] + + In the preceding information: + + - **FROM** statement: indicates that **centos:7.1.1503** is used as the base image. + - **Run** statement: indicates that a shell command is executed in the container. + - **Copy** statement: indicates that files in the local computer are copied to the container. + - **ENTRYPOINT** statement: indicates the commands that are run after the container is started. diff --git a/umn/source/best_practice/containerization/containerizing_an_enterprise_application_erp/procedure/containerization_process.rst b/umn/source/best_practice/containerization/containerizing_an_enterprise_application_erp/procedure/containerization_process.rst new file mode 100644 index 0000000..bb22774 --- /dev/null +++ b/umn/source/best_practice/containerization/containerizing_an_enterprise_application_erp/procedure/containerization_process.rst @@ -0,0 +1,14 @@ +:original_name: cce_bestpractice_0004.html + +.. _cce_bestpractice_0004: + +Containerization Process +======================== + +The following figure illustrates the process of containerizing an application. + + +.. figure:: /_static/images/en-us_image_0264626618.png + :alt: **Figure 1** Process of containerizing an application + + **Figure 1** Process of containerizing an application diff --git a/umn/source/best_practice/containerization/containerizing_an_enterprise_application_erp/procedure/containerizing_an_entire_application.rst b/umn/source/best_practice/containerization/containerizing_an_enterprise_application_erp/procedure/containerizing_an_entire_application.rst new file mode 100644 index 0000000..de6e36b --- /dev/null +++ b/umn/source/best_practice/containerization/containerizing_an_enterprise_application_erp/procedure/containerizing_an_entire_application.rst @@ -0,0 +1,54 @@ +:original_name: cce_bestpractice_0003.html + +.. _cce_bestpractice_0003: + +Containerizing an Entire Application +==================================== + +This tutorial describes how to containerize an ERP system by migrating it from a VM to CCE. + +No recoding or re-architecting is required. You only need to pack the entire application into a container image and deploy the container image on CCE. + +Introduction +------------ + +In this example, the **enterprise management application** is developed by enterprise A. This application is provided for third-party enterprises for use, and enterprise A is responsible for application maintenance. + +When a third-party enterprise needs to use this application, a suit of **Tomcat application** and **MongoDB database** must be deployed for the third-party enterprise. The MySQL database, used to store data of third-party enterprises, is provided by enterprise A. + +.. _cce_bestpractice_0003__fig78809934014: + +.. figure:: /_static/images/en-us_image_0166039537.png + :alt: **Figure 1** Application architecture + + **Figure 1** Application architecture + +As shown in :ref:`Figure 1 `, the application is a standard Tomcat application, and its backend interconnects with MongoDB and MySQL databases. For this type of applications, there is no need to split the architecture. The entire application is built as an image, and the MongoDB database is deployed in the same image as the Tomcat application. In this way, the application can be deployed or upgraded through the image. + +- Interconnecting with the MongoDB database for storing user files. +- Interconnecting with the MySQL database for storing third-party enterprise data. The MySQL database is an external cloud database. + +Benefits +-------- + +In this example, the application was deployed on a VM. During application deployment and upgrade, a series of problems is encountered, but application containerization has solved these problems. + +By using containers, you can easily pack application code, configurations, and dependencies and convert them into easy-to-use building blocks. This achieves the environmental consistency and version management, as well as improves the development and operation efficiency. Containers ensure quick, reliable, and consistent deployment of applications and prevent applications from being affected by deployment environment. + +.. table:: **Table 1** Comparison between the two deployment modes + + +---------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | Item | Before: Application Deployment on VM | After: Application Deployment Using Containers | + +=================================+================================================================================================================================================================================+=========================================================================================================================================================================+ + | Deployment | High deployment cost. | More than 50% cost reduced. | + | | | | + | | A VM is required for deploying a system for a customer. | Container services achieve multi-tenant isolation, which allows you to deploy systems for different enterprises on the same VM. | + +---------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | Upgrade | Low upgrade efficiency. | Per-second level upgrade. | + | | | | + | | During version upgrades, you need to log in to VMs one by one and manually configure the upgrades, which is inefficient and error-prone. | Version upgrades can be completed within seconds by replacing the image tag. In addition, CCE provides rolling updates, ensuring zero service downtime during upgrades. | + +---------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | Operation and maintenance (O&M) | High O&M cost. | Automatic O&M | + | | | | + | | As the number of applications deployed for customer grows, the number of VMs that need to be maintained increases accordingly, which requires a large sum of maintenance cost. | Enterprises can focus on service development without paying attention to VM maintenance. | + +---------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ diff --git a/umn/source/best_practice/containerization/containerizing_an_enterprise_application_erp/procedure/creating_a_container_workload.rst b/umn/source/best_practice/containerization/containerizing_an_enterprise_application_erp/procedure/creating_a_container_workload.rst new file mode 100644 index 0000000..ef923b6 --- /dev/null +++ b/umn/source/best_practice/containerization/containerizing_an_enterprise_application_erp/procedure/creating_a_container_workload.rst @@ -0,0 +1,146 @@ +:original_name: cce_bestpractice_0010.html + +.. _cce_bestpractice_0010: + +Creating a Container Workload +============================= + +This section describes how to deploy a workload on CCE. When using CCE for the first time, create an initial cluster and add a node into the cluster. + +.. note:: + + Containerized workloads are deployed in a similar way. The difference lies in: + + - Whether environment variables need to be set. + - Whether cloud storage is used. + +Required Cloud Services +----------------------- + +- Cloud Container Engine (CCE): a highly reliable and high-performance service that allows enterprises to manage containerized applications. With support for Kubernetes-native applications and tools, CCE makes it simple to set up an environment for running containers in the cloud. +- Elastic Cloud Server (ECS): a scalable and on-demand cloud server. It helps you to efficiently set up reliable, secure, and flexible application environments, ensuring stable service running and improving O&M efficiency. +- Virtual Private Cloud (VPC): an isolated and private virtual network environment that users apply for in the cloud. You can configure the IP address ranges, subnets, and security groups, as well as assign elastic IP addresses and allocate bandwidth in a VPC. + +Basic Concepts +-------------- + +- A cluster is a collection of computing resources, including a group of node resources. A container runs on a node. Before creating a containerized application, you must have an available cluster. +- A node is a virtual or physical machine that provides computing resources. You must have sufficient node resources to ensure successful operations such as creating applications. +- A workload indicates a group of container pods running on CCE. CCE supports third-party application hosting and provides the full lifecycle (from deployment to O&M) management for applications. This section describes how to use a container image to create a workload. + +Procedure +--------- + +#. .. _cce_bestpractice_0010__li1025612329217: + + Prepare the environment as described in :ref:`Table 1 `. + + .. _cce_bestpractice_0010__table1399518309317: + + .. table:: **Table 1** Preparing the environment + + +-----------------------+-----------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | No. | Item | Procedure | + +=======================+=======================+================================================================================================================================================================================================+ + | 1 | Creating a VPC | Create a VPC before you create a cluster. A VPC provides an isolated, configurable, and manageable virtual network environment for CCE clusters. | + | | | | + | | | If you have a VPC already, skip to the next task. | + | | | | + | | | a. Log in to the management console. | + | | | b. In the service list, choose **Networking** > **Virtual Private Cloud**. | + | | | c. On the **Dashboard** page, click **Create VPC**. | + | | | d. Follow the instructions to create a VPC. Retain default settings for parameters unless otherwise specified. | + +-----------------------+-----------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | 2 | Creating a key pair | Create a key pair before you create a containerized application. Key pairs are used for identity authentication during remote login to a node. If you have a key pair already, skip this task. | + | | | | + | | | a. Log in to the management console. | + | | | | + | | | b. In the service list, choose **Data Encryption Workshop** under **Security & Compliance**. | + | | | | + | | | c. In the navigation pane, choose **Key Pair Service**. On the **Private Key Pairs** tab page, click **Create Key Pair**. | + | | | | + | | | d. Enter a key pair name, select **I agree to have the private key managed on the cloud** and **I have read and agree to the Key Pair Service Disclaimer**, and click **OK**. | + | | | | + | | | e. In the dialog box displayed, click **OK**. | + | | | | + | | | View and save the key pair. For security purposes, a key pair can be downloaded only once. Keep it secure to ensure successful login. | + +-----------------------+-----------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + +#. Create a cluster and a node. + + a. Log in to the CCE console. Choose **Clusters**. On the displayed page, select the type of the cluster to be created and click Create. + + Configure cluster parameters and select the VPC created in :ref:`1 `. + + b. Buy a node and select the key pair created in :ref:`1 ` as the login mode. + +#. Deploy a workload on CCE. + + a. Log in to the CCE console, click the created cluster, choose **Workloads** in the navigation pane, and click **Create Workload** in the upper right corner. + + b. Set the following parameters, and retain the default settings for other parameters: + + - **Workload Name**: Set it to **apptest**. + - **Pods**: Set it to **1**. + + c. In the **Container Settings** area, select the image uploaded in :ref:`Building and Uploading an Image `. + + d. In the **Container Settings** area, choose **Environment Variables** and add environment variables for interconnecting with the MySQL database. The environment variables are set in the :ref:`startup script `. + + .. note:: + + In this example, interconnection with the MySQL database is implemented through configuring the environment variables. Determine whether to use environment variables based on your service requirements. + + .. table:: **Table 2** Configuring environment variables + + ============== =========================================== + Variable Name Variable Value/Variable Reference + ============== =========================================== + MYSQL_DB Database name. + MYSQL_URL IP address and port number of the database. + MYSQL_USER Database username. + MYSQL_PASSWORD Database user password. + ============== =========================================== + + e. In the **Container Settings** area, choose **Data Storage** and configure cloud storage for persistent data storage. + + .. note:: + + In this example, the MongoDB database is used and persistent data storage is also needed, so you need to configure cloud storage. Determine whether to use cloud storage based on your service requirements. + + The mounted path must be the same as the MongoDB storage path in the Docker startup script. For details, see the :ref:`startup script `. In this example, the path is **/usr/local/mongodb/data**. + + f. In the **Service Settings** area, click |image1| to add a service, configure workload access parameters, and click **OK**. + + .. note:: + + In this example, the application will be accessible from public networks by using an elastic IP address. + + - **Service Name**: name of the application that can be accessed externally. In this example, this parameter is set to **apptest**. + - **Service Type**: In this example, select **NodePort**. + - **Service Affinity** + + - **Cluster-level**: The IP addresses and access ports of all nodes in a cluster can be used to access the workload associated with the Service. Service access will cause performance loss due to route redirection, and the source IP address of the client cannot be obtained. + - **Node-level**: Only the IP address and access port of the node where the workload is located can be used to access the workload associated with the Service. Service access will not cause performance loss due to route redirection, and the source IP address of the client can be obtained. + + - **Port** + + - **Protocol**: Set it to **TCP**. + - **Service Port**: port for accessing the Service. + - **Container Port**: port that the application will listen on the container. In this example, this parameter is set to **8080**. + - **Node Port**: Set it to **Auto**. The system automatically opens a real port on all nodes in the current cluster and then maps the port number to the container port. + + g. Click **Create Workload**. + + After the workload is created, you can view the running workload in the workload list. + +Verifying a Workload +-------------------- + +After a workload is created, you can access the workload to check whether the deployment is successful. + +In the preceding configuration, the NodePort mode is selected to access the workload by using **IP address:Port number**. If the access is successful, the workload is successfully deployed. + +You can obtain the access mode from the **Access Mode** tab page on the workload details page. + +.. |image1| image:: /_static/images/en-us_image_0000001244128658.png diff --git a/umn/source/best_practice/containerization/containerizing_an_enterprise_application_erp/procedure/index.rst b/umn/source/best_practice/containerization/containerizing_an_enterprise_application_erp/procedure/index.rst new file mode 100644 index 0000000..072d3e8 --- /dev/null +++ b/umn/source/best_practice/containerization/containerizing_an_enterprise_application_erp/procedure/index.rst @@ -0,0 +1,28 @@ +:original_name: cce_bestpractice_0340.html + +.. _cce_bestpractice_0340: + +Procedure +========= + +- :ref:`Containerizing an Entire Application ` +- :ref:`Containerization Process ` +- :ref:`Analyzing the Application ` +- :ref:`Preparing the Application Runtime ` +- :ref:`Compiling a Startup Script ` +- :ref:`Compiling the Dockerfile ` +- :ref:`Building and Uploading an Image ` +- :ref:`Creating a Container Workload ` + +.. toctree:: + :maxdepth: 1 + :hidden: + + containerizing_an_entire_application + containerization_process + analyzing_the_application + preparing_the_application_runtime + compiling_a_startup_script + compiling_the_dockerfile + building_and_uploading_an_image + creating_a_container_workload diff --git a/umn/source/best_practice/containerization/containerizing_an_enterprise_application_erp/procedure/preparing_the_application_runtime.rst b/umn/source/best_practice/containerization/containerizing_an_enterprise_application_erp/procedure/preparing_the_application_runtime.rst new file mode 100644 index 0000000..8f64585 --- /dev/null +++ b/umn/source/best_practice/containerization/containerizing_an_enterprise_application_erp/procedure/preparing_the_application_runtime.rst @@ -0,0 +1,122 @@ +:original_name: cce_bestpractice_0006.html + +.. _cce_bestpractice_0006: + +Preparing the Application Runtime +================================= + +After application analysis, you have gained the understanding of the OS and runtime required for running the application. You need to make the following preparations: + +- :ref:`Installing Docker `: During application containerization, you need to build a container image. To do so, you have to prepare a PC and install Docker on it. +- :ref:`Obtaining the base image tag `: Determine the base image based on the OS on which the application runs. In this example, the application runs on CentOS 7.1 and the base image can be obtained from an open-source image repository. +- :ref:`Obtaining the runtime `: Obtain the runtime of the application and the MongoDB database with which the application interconnects. + +.. _cce_bestpractice_0006__section411319276259: + +Installing Docker +----------------- + +Docker is compatible with almost all operating systems. Select a Docker version that best suits your needs. + +.. note:: + + SWR uses Docker 1.11.2 or later to upload images. + + You are advised to install Docker and build images as user **root**. Obtain the password of user **root** of the host where Docker is to be installed in advance. + +#. Log in as user **root** to the device on which Docker is about to be installed. + +#. Run the following commands to quickly install Docker on the device running Linux: + + **curl -fsSL get.docker.com -o get-docker.sh** + + **sh get-docker.sh** + +#. Run the following command to query the Docker version: + + **docker version** + + .. code-block:: + + Client: + Version: 17.12.0-ce + API Version:1.35 + ... + + **Version** indicates the version number. + +.. _cce_bestpractice_0006__section7944139145718: + +Obtaining the Base Image Tag +---------------------------- + +Determine the base image based on the OS on which the application runs. In this example, the application runs on CentOS 7.1 and the base image can be obtained from an open-source image repository. + +.. note:: + + Search for the image tag based on the OS on which the application runs. + +#. Visit the Docker website. + +#. Search for CentOS. The image corresponding to CentOS 7.1 is **centos7.1.1503**. You need to use this image name when compiling the Dockerfile. + + + .. figure:: /_static/images/en-us_image_0091280734.png + :alt: **Figure 1** Obtaining the CentOS version + + **Figure 1** Obtaining the CentOS version + +.. _cce_bestpractice_0006__section44401821348: + +Obtaining the Runtime +--------------------- + +In this example, the web application of the Tomcat type is used. This application requires the runtime of Tomcat 7.0, and Tomcat requires JDK 1.8. In addition, the application must interconnect with the MongoDB database in advance. + +.. note:: + + Download the environment required by the application. + +#. Download Tomcat, JDK, and MongoDB installation packages of the specific versions. + + a. Download JDK 1.8. + + Download address: https://www.oracle.com/java/technologies/jdk8-downloads.html. + + b. Download Tomcat 7.0 from http://archive.apache.org/dist/tomcat/tomcat-7/v7.0.82/bin/apache-tomcat-7.0.82.tar.gz. + + c. Download MongoDB 3.2 from https://fastdl.mongodb.org/linux/mongodb-linux-x86_64-rhel70-3.2.9.tgz. + +#. Log in as user **root** to the device running Docker. + +#. Run the following commands to create the directory where the application is to be stored: For example, set the directory to **apptest**. + + **mkdir apptest** + + **cd apptest** + +#. Use Xshell to save the downloaded dependency files to the **apptest** directory. + +#. Run the following commands to decompress the dependency files: + + **tar -zxf apache-tomcat-7.0.82.tar.gz** + + **tar -zxf jdk-8u151-linux-x64.tar.gz** + + **tar -zxf mongodb-linux-x86_64-rhel70-3.2.9.tgz** + +#. Save the enterprise application (for example, **apptest.war**) in the **webapps/apptest** directory of the Tomcat runtime environment. + + .. note:: + + **apptest.war** is used as an example only. Use your own application for actual configuration. + + **mkdir -p apache-tomcat-7.0.82/webapps/app\ test** + + **cp apptest.war apache-tomcat-7.0.82/webapps/app\ test** + + **cd apache-tomcat-7.0.82/webapps/app\ test** + + **./../../../jdk1.8.0_151/bin/jar -xf apptest.war** + + **rm -rf apptest.war** diff --git a/umn/source/best_practice/containerization/containerizing_an_enterprise_application_erp/solution_overview.rst b/umn/source/best_practice/containerization/containerizing_an_enterprise_application_erp/solution_overview.rst new file mode 100644 index 0000000..2fc1693 --- /dev/null +++ b/umn/source/best_practice/containerization/containerizing_an_enterprise_application_erp/solution_overview.rst @@ -0,0 +1,68 @@ +:original_name: cce_bestpractice_0002.html + +.. _cce_bestpractice_0002: + +Solution Overview +================= + +This chapter provides CCE best practices to walk you through the application containerization. + +What Is a Container? +-------------------- + +A container is a lightweight high-performance resource isolation mechanism implemented based on the Linux kernel. It is a built-in capability of the operating system (OS) kernel. + +CCE is an enterprise-class container service based on open-source Kubernetes. It is a high-performance and high-reliability service through which enterprises can manage containerized applications. CCE supports native Kubernetes applications and tools, allowing you to easily set up a container runtime in the cloud. + +Why Is a Container Preferred? +----------------------------- + +- More efficient use of system resources + + A container does not require extra costs such as fees for hardware virtualization and those for running a complete OS. Therefore, a container has higher resource usage. Compared with a VM with the same configurations, a container can run more applications. + +- Faster startup + + A container directly runs on the host kernel and does not need to start a complete OS. Therefore, a container can be started within seconds or even milliseconds, greatly saving the development, testing, and deployment time. + +- Consistent runtime environment + + A container image provides a complete runtime environment to ensure environment consistency. In this case, problems (for example, some code runs properly on machine A but fails to run on machine B) will not occur. + +- Easier application migration, maintenance, and scaling + + A consistent runtime environment makes application migration easier. In addition, the in-use storage and image technologies facilitate the reuse of repeated applications and simplifies the expansion of images based on base images. + +Containerization Modes +---------------------- + +The following modes are available for containerizing applications: + +- Mode 1: Containerize a single application as a whole. Application code and architecture remain unchanged. +- Mode 2: Separate the components that are frequently upgraded or have high requirements on auto scaling from an application, and then containerize these components. +- Mode 3: Transform an application to microservices and then containerize the microservices one by one. + +:ref:`Table 1 ` lists the advantages and disadvantages of the three modes. + +.. _cce_bestpractice_0002__table955211293219: + +.. table:: **Table 1** Containerization modes + + +----------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------+ + | Containerization Mode | Advantage | Disadvantage | + +======================================================================================================================+====================================================================================================================================================================================================================================================================================================================================================================================+=================================================================================================================================================+ + | Method 1: | - Zero modification on services: The application architecture and code require no change. | - Difficult to expand the entire architecture of an application. As the code size increases, code update and maintenance would be complicated. | + | | - The deployment and upgrade efficiency is improved. Applications can be packed as container images to ensure application environment consistency and improve deployment efficiency. | - Difficult to launch new functions, languages, frameworks, and technologies. | + | Containerize a single application as a whole. | - Reduce resource costs: Containers use system resources more efficiently. Compared with a VM with the same configurations, a container can run more applications. | | + +----------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------+ + | Method 2: | - Progressive transformation: Reconstructing the entire architecture involves a heavy workload. This mode containerizes only a part of components, which is easy to accept for customers. | Need to decouple some services. | + | | - Flexible scaling: Application components that have high requirements on auto scaling are containerized. When the application needs to be scaled, you only need to scale the containers, which is flexible and reduces the required system resources. | | + | Containerize first the application components that are frequently updated or have high requirements on auto scaling. | - Faster rollout of new features: Application components that are frequently upgraded are containerized. In subsequent upgrades, only these containers need to be upgraded. This shortens the time to market (TTM) of new features. | | + +----------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------+ + | Method 3: | - Independent scaling: After an application is split into microservices, you can independently increase or decrease the number of instances for each microservice. | Need to transform the application to microservices, which involves a large number of changes. | + | | - Increased development speed: Microservices are decoupled from one another. Code development of a microservice does not affect other microservices. | | + | Transform an application to microservices and then containerize the microservices one by one. | - Security assurance through isolation: For an overall application, if a security vulnerability exists, attackers can use this vulnerability to obtain the permission to all functions of the application. However, in a microservice architecture, if a service is attacked, attackers can only obtain the access permission to this service, but cannot intrude other services. | | + | | - Breakdown isolation: If one microservice breaks down, other microservices can still run properly. | | + +----------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------+ + +**Mode 1** is used as an example in this tutorial to illustrate how to containerize an enterprise resource planning (ERP) system. diff --git a/umn/source/best_practice/containerization/index.rst b/umn/source/best_practice/containerization/index.rst new file mode 100644 index 0000000..764e14c --- /dev/null +++ b/umn/source/best_practice/containerization/index.rst @@ -0,0 +1,14 @@ +:original_name: cce_bestpractice_0321.html + +.. _cce_bestpractice_0321: + +Containerization +================ + +- :ref:`Containerizing an Enterprise Application (ERP) ` + +.. toctree:: + :maxdepth: 1 + :hidden: + + containerizing_an_enterprise_application_erp/index diff --git a/umn/source/best_practice/devops/interconnecting_gitlab_with_swr_and_cce_for_ci_cd.rst b/umn/source/best_practice/devops/interconnecting_gitlab_with_swr_and_cce_for_ci_cd.rst index 4a1c088..026ff18 100644 --- a/umn/source/best_practice/devops/interconnecting_gitlab_with_swr_and_cce_for_ci_cd.rst +++ b/umn/source/best_practice/devops/interconnecting_gitlab_with_swr_and_cce_for_ci_cd.rst @@ -161,6 +161,8 @@ The content is as follows: stage: deploy script: # Configure the kubeconfig file. + - mkdir -p $HOME/.kube + - export KUBECONFIG=$HOME/.kube/config - echo $kube_config |base64 -d > $KUBECONFIG # Replace the image in the k8s.yaml file. - sed -i "s//swr.eu-de.otc.t-systems.com\/k8s-dev\/nginx:$CI_PIPELINE_ID/g" k8s.yaml @@ -184,8 +186,40 @@ After the pipeline is deployed, locate the **nginx-test** Service on the CCE con If the preceding information is displayed, the deployment is correct. +FAQs +---- + +If the following problems occur during the deployment: + +|image6| + +or + +|image7| + +Check whether the following commands are missing in the **.gitlab-ci.yml** file. If yes, add them to the **.gitlab-ci.yml** file. + +.. code-block:: + + ... + deploy: + # Use the kubectl image. + image: + name: bitnami/kubectl:latest + entrypoint: [""] + stage: deploy + script: + # Configure the kubeconfig file. + - mkdir -p $HOME/.kube + - export KUBECONFIG=$HOME/.kube/config + - echo $kube_config |base64 -d > $KUBECONFIG + # Replace the image in the k8s.yaml file. + ... + .. |image1| image:: /_static/images/en-us_image_0000001238489436.png .. |image2| image:: /_static/images/en-us_image_0000001283301301.png .. |image3| image:: /_static/images/en-us_image_0000001238903330.png .. |image4| image:: /_static/images/en-us_image_0000001238830246.png .. |image5| image:: /_static/images/en-us_image_0000001283343269.png +.. |image6| image:: /_static/images/en-us_image_0000001520115845.png +.. |image7| image:: /_static/images/en-us_image_0000001520396937.png diff --git a/umn/source/best_practice/disaster_recovery/implementing_high_availability_for_containers_in_cce.rst b/umn/source/best_practice/disaster_recovery/implementing_high_availability_for_containers_in_cce.rst index 8b7cd14..034567f 100644 --- a/umn/source/best_practice/disaster_recovery/implementing_high_availability_for_containers_in_cce.rst +++ b/umn/source/best_practice/disaster_recovery/implementing_high_availability_for_containers_in_cce.rst @@ -24,11 +24,11 @@ Assume that there are four nodes in a cluster distributed in the following AZs: .. code-block:: $ kubectl get node -L topology.kubernetes.io/zone,kubernetes.io/hostname - NAME STATUS ROLES AGE VERSION ZONE HOSTNAME - 192.168.5.112 Ready 42m v1.21.7-r0-CCE21.11.1.B007 eu-de-01 192.168.5.112 - 192.168.5.179 Ready 42m v1.21.7-r0-CCE21.11.1.B007 eu-de-01 192.168.5.179 - 192.168.5.252 Ready 37m v1.21.7-r0-CCE21.11.1.B007 eu-de-02 192.168.5.252 - 192.168.5.8 Ready 33h v1.21.7-r0-CCE21.11.1.B007 eu-de-03 192.168.5.8 + NAME STATUS ROLES AGE VERSION ZONE HOSTNAME + 192.168.5.112 Ready 42m v1.21.7-r0-CCE21.11.1.B007 zone01 192.168.5.112 + 192.168.5.179 Ready 42m v1.21.7-r0-CCE21.11.1.B007 zone01 192.168.5.179 + 192.168.5.252 Ready 37m v1.21.7-r0-CCE21.11.1.B007 zone02 192.168.5.252 + 192.168.5.8 Ready 33h v1.21.7-r0-CCE21.11.1.B007 zone03 192.168.5.8 Create workloads according to the following two podAntiAffinity rules: diff --git a/umn/source/best_practice/index.rst b/umn/source/best_practice/index.rst index 5b5e2de..2e96731 100644 --- a/umn/source/best_practice/index.rst +++ b/umn/source/best_practice/index.rst @@ -6,27 +6,35 @@ Best Practice ============= - :ref:`Checklist for Deploying Containerized Applications in the Cloud ` +- :ref:`Containerization ` - :ref:`Migration ` - :ref:`DevOps ` - :ref:`Disaster Recovery ` - :ref:`Security ` - :ref:`Auto Scaling ` +- :ref:`Monitoring ` - :ref:`Cluster ` - :ref:`Networking ` - :ref:`Storage ` - :ref:`Container ` +- :ref:`Permission ` +- :ref:`Release ` .. toctree:: :maxdepth: 1 :hidden: checklist_for_deploying_containerized_applications_in_the_cloud + containerization/index migration/index devops/index disaster_recovery/index security/index auto_scaling/index + monitoring/index cluster/index networking/index storage/index container/index + permission/index + release/index diff --git a/umn/source/best_practice/migration/migrating_on-premises_kubernetes_clusters_to_cce/installing_the_migration_tool.rst b/umn/source/best_practice/migration/migrating_on-premises_kubernetes_clusters_to_cce/installing_the_migration_tool.rst index ea94f39..a6dce4e 100644 --- a/umn/source/best_practice/migration/migrating_on-premises_kubernetes_clusters_to_cce/installing_the_migration_tool.rst +++ b/umn/source/best_practice/migration/migrating_on-premises_kubernetes_clusters_to_cce/installing_the_migration_tool.rst @@ -13,7 +13,7 @@ Prerequisites ------------- - The Kubernetes version of the source on-premises cluster must be 1.10 or later, and the cluster can use DNS and Internet services properly. -- If you use OBS to store backup files, you need to obtain the AK/SK of a user who has the right to operate OBS. For details about how to obtain the AK/SK, see `Access Keys `__. +- If you use OBS to store backup files, you need to obtain the AK/SK of a user who has the right to operate OBS. For details, see `Obtaining Access Keys (AK/SK) `__. - If you use MinIO to store backup files, bind an EIP to the server where MinIO is installed and enable the API and console port of MinIO in the security group. - The target CCE cluster has been created. - The source cluster and target cluster must each have at least one idle node. It is recommended that the node specifications be 4 vCPUs and 8 GB memory or higher. @@ -116,7 +116,7 @@ Download the latest, stable binary file from https://github.com/vmware-tanzu/vel vim credentials-velero - Replace the AK/SK in the file based on the site requirements. If OBS is used, obtain the AK/SK by referring to . If MinIO is used, the AK and SK are the username and password created in :ref:`2 `. + Replace the AK/SK in the file based on the site requirements. If MinIO is used, the AK/SK are the username and password created in :ref:`2 `. .. code-block:: diff --git a/umn/source/best_practice/migration/migrating_on-premises_kubernetes_clusters_to_cce/planning_resources_for_the_target_cluster.rst b/umn/source/best_practice/migration/migrating_on-premises_kubernetes_clusters_to_cce/planning_resources_for_the_target_cluster.rst index 21126fc..516a042 100644 --- a/umn/source/best_practice/migration/migrating_on-premises_kubernetes_clusters_to_cce/planning_resources_for_the_target_cluster.rst +++ b/umn/source/best_practice/migration/migrating_on-premises_kubernetes_clusters_to_cce/planning_resources_for_the_target_cluster.rst @@ -19,7 +19,7 @@ CCE allows you to customize cluster resources to meet various service requiremen | Resource | Key Performance Parameter | Description | Example Value | +=================+===========================================================+==============================================================================================================================================================================================================================================================================================================================================================================================+=================================================================+ | Cluster | **\***\ Cluster Type | - **CCE cluster**: supports VM nodes. You can run your containers in a secure and stable container runtime environment based on a high-performance network model. | CCE cluster | - | | | - **CCE Turbo cluster**: runs on a cloud native infrastructure that features software-hardware synergy to support passthrough networking, high security and reliability, intelligent scheduling, and BMS nodes. | | + | | | - **CCE Turbo cluster**: runs on a cloud native infrastructure that features software-hardware synergy to support passthrough networking, high security and reliability, and intelligent scheduling, and BMS nodes. | | +-----------------+-----------------------------------------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------+ | | **\***\ Network Model | - **VPC network**: The container network uses VPC routing to integrate with the underlying network. This network model is applicable to performance-intensive scenarios. The maximum number of nodes allowed in a cluster depends on the route quota in a VPC network. | VPC network | | | | - **Tunnel network**: The container network is an overlay tunnel network on top of a VPC network and uses the VXLAN technology. This network model is applicable when there is no high requirements on performance. | | diff --git a/umn/source/best_practice/migration/migrating_on-premises_kubernetes_clusters_to_cce/updating_resources_accordingly.rst b/umn/source/best_practice/migration/migrating_on-premises_kubernetes_clusters_to_cce/updating_resources_accordingly.rst index 0824c54..0120a99 100644 --- a/umn/source/best_practice/migration/migrating_on-premises_kubernetes_clusters_to_cce/updating_resources_accordingly.rst +++ b/umn/source/best_practice/migration/migrating_on-premises_kubernetes_clusters_to_cce/updating_resources_accordingly.rst @@ -35,7 +35,7 @@ The WordPress and MySQL images used in this example can be pulled from SWR. Ther Updating Services ----------------- -After the cluster is migrated, the Service of the source cluster may fail to take effect. You can perform the following steps to update the Service. If ingresses are configured in the source cluster, you need to connect the new cluster to ELB again after the migration. For details, see `Using kubectl to Create an ELB Ingress `__. +After the cluster is migrated, the Service of the source cluster may fail to take effect. You can perform the following steps to update the Service. If ingresses are configured in the source cluster, you need to connect the new cluster to ELB again after the migration. For details, see `Using kubectl to Create an ELB Ingress `__. #. Connect to the cluster using kubectl. @@ -45,7 +45,7 @@ After the cluster is migrated, the Service of the source cluster may fail to tak kubectl edit svc wordpress - To update load balancer resources, you need to connect to ELB again. Add the annotations by following the procedure described in `LoadBalancer `__. + To update load balancer resources, you need to connect to ELB again. Add the following annotations. For details, see `LoadBalancer `__. .. code-block:: diff --git a/umn/source/best_practice/monitoring/index.rst b/umn/source/best_practice/monitoring/index.rst new file mode 100644 index 0000000..21a28d9 --- /dev/null +++ b/umn/source/best_practice/monitoring/index.rst @@ -0,0 +1,14 @@ +:original_name: cce_bestpractice_10008.html + +.. _cce_bestpractice_10008: + +Monitoring +========== + +- :ref:`Using Prometheus for Multi-cluster Monitoring ` + +.. toctree:: + :maxdepth: 1 + :hidden: + + using_prometheus_for_multi-cluster_monitoring diff --git a/umn/source/best_practice/monitoring/using_prometheus_for_multi-cluster_monitoring.rst b/umn/source/best_practice/monitoring/using_prometheus_for_multi-cluster_monitoring.rst new file mode 100644 index 0000000..e8703ae --- /dev/null +++ b/umn/source/best_practice/monitoring/using_prometheus_for_multi-cluster_monitoring.rst @@ -0,0 +1,199 @@ +:original_name: cce_bestpractice_10009.html + +.. _cce_bestpractice_10009: + +Using Prometheus for Multi-cluster Monitoring +============================================= + +Scenario +-------- + +Generally, a user has different clusters for different purposes, such as production, testing, and development. To monitor, collect, and view metrics of these clusters, you can deploy a set of Prometheus. + +Solution Architecture +--------------------- + +Multiple clusters are connected to the same Prometheus monitoring system, as shown in the following figure. This reduces maintenance and resource costs and facilitates monitoring information aggregation. + +|image1| + +Prerequisites +------------- + +- The target cluster has been created. +- Prometheus is properly connected to the target cluster. +- Prometheus has been installed on a Linux host using a binary file. For details, see `Installation `__. + +Procedure +--------- + +#. Obtain the **bear_token** information of the target cluster. + + a. Create the RBAC permission in the target cluster. + + Log in to the background node of the target cluster and create the **prometheus_rbac.yaml** file. + + .. code-block:: + + apiVersion: v1 + kind: ServiceAccount + metadata: + name: prometheus-test + namespace: kube-system + + --- + apiVersion: rbac.authorization.k8s.io/v1 + kind: ClusterRole + metadata: + name: prometheus-test + rules: + - apiGroups: + - "" + resources: + - nodes + - services + - endpoints + - pods + - nodes/proxy + verbs: + - get + - list + - watch + - apiGroups: + - "extensions" + resources: + - ingresses + verbs: + - get + - list + - watch + - apiGroups: + - "" + resources: + - configmaps + - nodes/metrics + verbs: + - get + - nonResourceURLs: + - /metrics + verbs: + - get + --- + apiVersion: rbac.authorization.k8s.io/v1 + kind: ClusterRoleBinding + metadata: + name: prometheus-test + roleRef: + apiGroup: rbac.authorization.k8s.io + kind: ClusterRole + name: prometheus-test + subjects: + - kind: ServiceAccount + name: prometheus-test + namespace: kube-system + + Run the following command to create the RBAC permission: + + **kubectl apply -f prometheus_rbac.yaml** + + b. Obtain the **bearer_token** information of the target cluster. + + .. note:: + + - In clusters earlier than v1.21, a token is obtained by mounting the secret of the service account to a pod. Tokens obtained this way are permanent. This approach is no longer recommended starting from version 1.21. Service accounts will stop auto creating secrets in clusters from version 1.25. + + In clusters of version 1.21 or later, you can use the `TokenRequest `__ API to `obtain the token `__ and use the projected volume to mount the token to the pod. Such tokens are valid for a fixed period. When the mounting pod is deleted, the token automatically becomes invalid. . + + - If you need a token that never expires, you can also `manually manage secrets for service accounts `__. Although a permanent service account token can be manually created, you are advised to use a short-lived token by calling the `TokenRequest `__ API for higher security. + + Obtain the **serviceaccount** information. + + **kubectl describe sa prometheus-test -n kube-system** + + |image2| + + **kubectl describe secret prometheus-test-token-hdhkg -n kube-system** + + |image3| + + Record the token value, which is the **bearer_token** information to be collected. + +#. Configure **bearer_token** information. + + Log in to the host where Prometheus is located, go to the Prometheus installation directory, and save the token information of the target cluster in a file. + + |image4| + +#. Configure Prometheus to monitor jobs. + + The example job monitors container metrics. If you need to monitor other metrics, you can add jobs and compile capture rules. + + .. code-block:: + + - job_name: k8s_cAdvisor + scheme: https + bearer_token_file: k8s_token # Token file in the previous step. + tls_config: + insecure_skip_verify: true + kubernetes_sd_configs: # kubernetes automatic discovery configuration + - role: node # Automatic discovery of the node type + bearer_token_file: k8s_token # Token file in the previous step + api_server: https://192.168.0.153:5443 # The API server address of the Kubernetes cluster + tls_config: + insecure_skip_verify: true # Skip the authentication on the server. + relabel_configs: ## Modify the existing label of the target cluster before capturing metrics. + - target_label: __address__ + replacement: 192.168.0.153:5443 + action: replace + ## Convert metrics_path to /api/v1/nodes/${1}/proxy/metrics/cadvisor. + # Obtain data from kubelet using the API Server proxy. + - source_labels: [__meta_kubernetes_node_name] # Specifies the source label to be processed. + regex: (.+) # Match the value of the source label. (.+) indicates that any value of the source label can be matched. + target_label: __metrics_path__ # specifies the label to be replaced. + replacement: /api/v1/nodes/${1}/proxy/metrics/cadvisor # indicates the new label, that is, the value of __metrics_path__. ${1} indicates the value that matches the regular expression, that is, node name. + - target_label: cluster + replacement: xxxxx ## (Optional) Enter the cluster information based on the actual situation. + + ### The following job monitors another cluster. + - job_name: k8s02_cAdvisor + scheme: https + bearer_token_file: k8s02_token # Token file in the previous step + tls_config: + insecure_skip_verify: true + kubernetes_sd_configs: + - role: node + bearer_token_file: k8s02_token # Token file in the previous step + api_server: https://192.168.0.147:5443 # API Server address of the Kubernetes cluster + tls_config: + insecure_skip_verify: true # Skip the authentication on the server. + relabel_configs: ## Modify the existing label of the target cluster before capturing metrics. + - target_label: __address__ + replacement: 192.168.0.147:5443 + action: replace + + - source_labels: [__meta_kubernetes_node_name] + regex: (.+) + target_label: __metrics_path__ + replacement: /api/v1/nodes/${1}/proxy/metrics/cadvisor + + - target_label: cluster + replacement: xxxx ## (Optional) Enter the cluster information based on the actual situation. + +#. Enable Prometheus. + + After the configuration, enable Prometheus. + + **./prometheus --config.file=prometheus.yml** + +#. Log in to Prometheus and view the monitoring information. + + |image5| + + |image6| + +.. |image1| image:: /_static/images/en-us_image_0000001352090724.png +.. |image2| image:: /_static/images/en-us_image_0000001403252957.png +.. |image3| image:: /_static/images/en-us_image_0000001352573116.png +.. |image4| image:: /_static/images/en-us_image_0000001352413288.png +.. |image5| image:: /_static/images/en-us_image_0000001352253356.png +.. |image6| image:: /_static/images/en-us_image_0000001402893085.png diff --git a/umn/source/best_practice/networking/implementing_sticky_session_through_load_balancing.rst b/umn/source/best_practice/networking/implementing_sticky_session_through_load_balancing.rst index 4196a6b..fc5e388 100644 --- a/umn/source/best_practice/networking/implementing_sticky_session_through_load_balancing.rst +++ b/umn/source/best_practice/networking/implementing_sticky_session_through_load_balancing.rst @@ -16,15 +16,21 @@ In load balancing and sticky session, connection and session are two key concept Simply put, if a user needs to log in, it can be regarded as a session; otherwise, a connection. -The sticky session mechanism fundamentally conflicts with the basic functions of load balancing. A load balancer forwards requests from clients to multiple backend servers to avoid overload on a single server. However, sticky session requires that some requests be forwarded to the same server for processing. Therefore, you need to select a proper sticky session mechanism based on the application environment. +The sticky session mechanism fundamentally conflicts with the basic functions of load balancing. A load balancer forwards requests from clients to multiple backend servers to avoid overload on a single server. However, sticky session requires that some requests be forwarded to the same server for processing. Therefore, select a proper sticky session mechanism based on the application environment. Layer-4 Load Balancing (Service) -------------------------------- In layer-4 load balancing, source IP address-based sticky session (Hash routing based on the client IP address) can be enabled. To enable source IP address-based sticky session on Services, the following conditions must be met: +**CCE cluster** + #. **Service Affinity** of the Service is set to **Node level** (that is, the value of the **externalTrafficPolicy** field of the Service is **Local**). + .. note:: + + You do not need to set this parameter for CCE Turbo clusters. + #. Enable the source IP address-based sticky session in the load balancing configuration of the Service. .. code-block:: @@ -42,7 +48,7 @@ In layer-4 load balancing, source IP address-based sticky session (Hash routing spec: selector: app: nginx - externalTrafficPolicy: Local + externalTrafficPolicy: Local # You do not need to set this parameter for CCE Turbo clusters. ports: - name: cce-service-0 targetPort: 80 @@ -149,7 +155,7 @@ In layer-7 load balancing, sticky session based on HTTP cookies and app cookies kubernetes.io/elb.session-affinity-option: '{"app_cookie_name":"test"}' # Application cookie name. ... -#. Create an ingress and associate it with a Service. The following example describes how to automatically create a shared load balancer. For details about how to specify other types of load balancers, see `Using kubectl to Create an ELB Ingress `__. +#. Create an ingress and associate it with a Service. The following example describes how to automatically create a shared load balancer. For details about how to specify other types of load balancers, see `Using kubectl to Create an ELB Ingress `__. .. code-block:: diff --git a/umn/source/best_practice/networking/obtaining_the_client_source_ip_address_for_a_container.rst b/umn/source/best_practice/networking/obtaining_the_client_source_ip_address_for_a_container.rst index 8c90f70..fbf1253 100644 --- a/umn/source/best_practice/networking/obtaining_the_client_source_ip_address_for_a_container.rst +++ b/umn/source/best_practice/networking/obtaining_the_client_source_ip_address_for_a_container.rst @@ -62,9 +62,11 @@ To obtain source IP addresses, perform the following steps: c. Click **Service List**. Under **Networking**, click **Elastic Load Balance**. d. On the **Load Balancers** page, click the name of the load balancer. e. Click **Listeners**. - f. To add a listener, click **Add Listener**. - g. To modify a listener, locate the listener and click |image3| on the right of its name. - h. Enable **Obtain Client IP Address**. + + - To add a listener, click **Add Listener**. + - To modify a listener, locate the listener and click the edit button on the right of its name. + + f. Enable **Obtain Client IP Address**. .. _cce_bestpractice_00035__section6340152911914: @@ -75,4 +77,3 @@ Set the service affinity of a NodePort Service to **Node level** instead of **Cl .. |image1| image:: /_static/images/en-us_image_0000001176818150.png .. |image2| image:: /_static/images/en-us_image_0000001221501677.png -.. |image3| image:: /_static/images/en-us_image_0000001221820189.png diff --git a/umn/source/best_practice/networking/planning_cidr_blocks_for_a_cluster.rst b/umn/source/best_practice/networking/planning_cidr_blocks_for_a_cluster.rst index 77090e8..dbf99ab 100644 --- a/umn/source/best_practice/networking/planning_cidr_blocks_for_a_cluster.rst +++ b/umn/source/best_practice/networking/planning_cidr_blocks_for_a_cluster.rst @@ -62,11 +62,11 @@ Single-VPC Single-Cluster Scenarios .. _cce_bestpractice_00004__en-us_topic_0099587154_fig15791152874920: .. figure:: /_static/images/en-us_image_0000001392318380.png - :alt: **Figure 2** Network CIDR block planning in the single-VPC single-cluster scenario (CCE cluster) + :alt: **Figure 2** Network CIDR block planning in single-VPC single-cluster scenarios (CCE cluster) - **Figure 2** Network CIDR block planning in the single-VPC single-cluster scenario (CCE cluster) + **Figure 2** Network CIDR block planning in single-VPC single-cluster scenarios (CCE cluster) -:ref:`Figure 3 ` shows the CIDR block planning for a **CCE Turbo cluster** (cloud native network 2.0). +:ref:`Figure 3 ` shows the CIDR block planning for a **CCE Turbo cluster** (Cloud Native Network 2.0). - VPC CIDR Block: specifies the VPC CIDR block where the cluster resides. The size of this CIDR block affects the maximum number of nodes that can be created in the cluster. - Subnet CIDR Block: specifies the subnet CIDR block where the node in the cluster resides. The subnet CIDR block is included in the VPC CIDR block. Different nodes in the same cluster can be allocated to different subnet CIDR blocks. @@ -76,12 +76,12 @@ Single-VPC Single-Cluster Scenarios .. _cce_bestpractice_00004__fig19746213285: .. figure:: /_static/images/en-us_image_0000001392280374.png - :alt: **Figure 3** CIDR block planning in the single-VPC single-cluster scenario (CCE Turbo cluster) + :alt: **Figure 3** Network CIDR block planning in single-VPC single-cluster scenarios (CCE Turbo cluster) - **Figure 3** CIDR block planning in the single-VPC single-cluster scenario (CCE Turbo cluster) + **Figure 3** Network CIDR block planning in single-VPC single-cluster scenarios (CCE Turbo cluster) -**Single-VPC Multi-Cluster Scenarios** --------------------------------------- +Single-VPC Multi-Cluster Scenarios +---------------------------------- **VPC network model** @@ -90,7 +90,7 @@ Pod packets are forwarded through VPC routes. CCE automatically configures a rou - VPC CIDR Block: specifies the VPC CIDR block where the cluster resides. The size of this CIDR block affects the maximum number of nodes that can be created in the cluster. - Subnet CIDR Block: The subnet CIDR block in each cluster cannot overlap with the container CIDR block. - Container CIDR Block: If multiple VPC network model clusters exist in a single VPC, the container CIDR blocks of all clusters cannot overlap because the clusters use the same routing table. In this case, CCE clusters are partially interconnected. A pod of a cluster can directly access the pods of another cluster, but cannot access the Services of the cluster. -- Service CIDR Block: can be used only in clusters. Therefore, the service CIDR blocks of different clusters can overlap, but cannot overlap with the subnet CIDR block and container CIDR block of the cluster to which the clusters belong. +- Service CIDR Block: can be used only in clusters. Therefore, the Service CIDR blocks of different clusters can overlap, but cannot overlap with the subnet CIDR block and container CIDR block of the cluster. .. _cce_bestpractice_00004__en-us_topic_0099587154_fig69527530400: @@ -106,7 +106,7 @@ Though at some cost of performance, the tunnel encapsulation enables higher inte - VPC CIDR Block: specifies the VPC CIDR block where the cluster resides. The size of this CIDR block affects the maximum number of nodes that can be created in the cluster. - Subnet CIDR Block: The subnet CIDR block in each cluster cannot overlap with the container CIDR block. - Container CIDR Block: The container CIDR blocks of all clusters can overlap. In this case, pods in different clusters cannot be directly accessed using IP addresses. It is recommended that ELB be used for the cross-cluster access between containers. -- Service CIDR Block: can be used only in clusters. Therefore, the service CIDR blocks of different clusters can overlap, but cannot overlap with the subnet CIDR block and container CIDR block of the cluster to which the clusters belong. +- Service CIDR Block: can be used only in clusters. Therefore, the Service CIDR blocks of different clusters can overlap, but cannot overlap with the subnet CIDR block and container CIDR block of the cluster. .. _cce_bestpractice_00004__en-us_topic_0099587154_fig8672112184219: @@ -115,20 +115,20 @@ Though at some cost of performance, the tunnel encapsulation enables higher inte **Figure 5** Tunnel network - multi-cluster scenario -**Cloud native network 2.0 network model** (CCE Turbo cluster) +**Cloud Native Network 2.0 Model** (CCE Turbo cluster) In this mode, container IP addresses are allocated from the VPC CIDR block. ELB passthrough networking is supported to direct access requests to containers. Security groups and multiple types of VPC networks can be bound to deliver high performance. - VPC CIDR Block: specifies the VPC CIDR block where the cluster resides. In a CCE Turbo cluster, the CIDR block size affects the total number of nodes and containers that can be created in the cluster. - Subnet CIDR Block: There is no special restriction on the subnet CIDR blocks in CCE Turbo clusters. - Container Subnet: The CIDR block of the container subnet is included in the VPC CIDR block. Container subnets in different clusters can overlap with each other or overlap with the subnet CIDR block. However, you are advised to stagger the container CIDR blocks of different clusters and ensure that the container subnet CIDR blocks have sufficient IP addresses. In this case, pods in different clusters can directly access each other through IP addresses. -- Service CIDR Block: can be used only in clusters. Therefore, the service CIDR blocks of different clusters can overlap, but cannot overlap with the subnet CIDR block or container CIDR block. +- Service CIDR Block: can be used only in clusters. Therefore, the Service CIDR blocks of different clusters can overlap, but cannot overlap with the subnet CIDR block and container subnet CIDR block of the cluster. .. figure:: /_static/images/en-us_image_0000001392259910.png - :alt: **Figure 6** Cloud native network 2.0 network model - multi-cluster scenario + :alt: **Figure 6** Cloud Native Network 2.0 - multi-cluster scenario - **Figure 6** Cloud native network 2.0 network model - multi-cluster scenario + **Figure 6** Cloud Native Network 2.0 - multi-cluster scenario **Coexistence of Clusters in Multi-Network** @@ -137,7 +137,7 @@ When a VPC contains clusters created with different network models, comply with - VPC CIDR Block: In this scenario, all clusters are located in the same VPC CIDR block. Ensure that there are sufficient available IP addresses in the VPC. - Subnet CIDR Block: Ensure that the subnet CIDR block does not overlap with the container CIDR block. Even in some scenarios (for example, coexistence with CCE Turbo clusters), the subnet CIDR block can overlap with the container (subnet) CIDR block. However, this is not recommended. - Container CIDR Block: Ensure that the container CIDR blocks of clusters in **VPC network model** do not overlap. -- Service CIDR Block: The service CIDR blocks of all clusters can overlap, but cannot overlap with the subnet CIDR block and container CIDR block of the cluster. +- Service CIDR Block: The Service CIDR blocks of all clusters can overlap, but cannot overlap with the subnet CIDR block and container CIDR block of the cluster. Cross-VPC Cluster Interconnection --------------------------------- @@ -148,14 +148,14 @@ In the VPC network model, after creating a peering connection, you need to add r .. figure:: /_static/images/en-us_image_0261818886.png - :alt: **Figure 7** VPC Network - VPC interconnection scenario + :alt: **Figure 7** VPC network - VPC interconnection scenario - **Figure 7** VPC Network - VPC interconnection scenario + **Figure 7** VPC network - VPC interconnection scenario When creating a VPC peering connection between containers across VPCs, pay attention to the following points: - The VPC to which the clusters belong must not overlap. In each cluster, the subnet CIDR block cannot overlap with the container CIDR block. -- The container CIDR blocks of clusters cannot overlap, but the Service CIDR blocks can. +- The container CIDR blocks of clusters at both ends cannot overlap, but the Service CIDR blocks can. - You need to add not only the peer VPC CIDR block but also the peer container CIDR block to the VPC routing tables at both ends. Note that this operation must be performed in the VPC route tables of the clusters. In the tunnel network model, after creating a peering connection, you need to add routes for the peering connection to enable communication between the two VPCs. @@ -168,13 +168,13 @@ In the tunnel network model, after creating a peering connection, you need to ad Pay attention to the following: -- The VPC of the clusters must not overlap. +- The VPCs of the clusters must not overlap. - The container CIDR blocks of all clusters can overlap, so do the Service CIDR blocks. - Add the peer subnet CIDR block to the route table of the VPC peering connection. -In **Cloud Native Network 2.0** mode, after creating a VPC peering connection, you only need to add routes for the VPC peering connection to enable communication between the two VPCs. Ensure that the VPC of the clusters does not overlap. +In **Cloud Native Network 2.0** mode, after creating a VPC peering connection, you only need to add routes for the VPC peering connection to enable communication between the two VPCs. Ensure that the VPCs of the clusters do not overlap. -**VPC-IDC Scenarios** ---------------------- +VPC-IDC Scenarios +----------------- Similar to the VPC interconnection scenario, some CIDR blocks in the VPC are routed to the IDC. The pod IP addresses of CCE clusters cannot overlap with the addresses within these CIDR blocks. To access the pod IP addresses in the cluster in the IDC, you need to configure the route table to the private line VBR on the IDC. diff --git a/umn/source/best_practice/networking/selecting_a_network_model.rst b/umn/source/best_practice/networking/selecting_a_network_model.rst index b48f95c..b1912ac 100644 --- a/umn/source/best_practice/networking/selecting_a_network_model.rst +++ b/umn/source/best_practice/networking/selecting_a_network_model.rst @@ -5,7 +5,7 @@ Selecting a Network Model ========================= -CCE uses self-proprietary, high-performance container networking add-ons to support the tunnel network, Cloud Native Network 2.0, and VPC network models. +CCE uses proprietary, high-performance container networking add-ons to support the tunnel network, Cloud Native Network 2.0, and VPC network models. .. caution:: diff --git a/umn/source/best_practice/permission/configuring_kubeconfig_for_fine-grained_management_on_cluster_resources.rst b/umn/source/best_practice/permission/configuring_kubeconfig_for_fine-grained_management_on_cluster_resources.rst new file mode 100644 index 0000000..875f596 --- /dev/null +++ b/umn/source/best_practice/permission/configuring_kubeconfig_for_fine-grained_management_on_cluster_resources.rst @@ -0,0 +1,230 @@ +:original_name: cce_bestpractice_00221.html + +.. _cce_bestpractice_00221: + +Configuring kubeconfig for Fine-Grained Management on Cluster Resources +======================================================================= + +Scenario +-------- + +By default, the kubeconfig file provided by CCE for users has permissions bound to the **cluster-admin** role, which are equivalent to the permissions of user **root**. It is difficult to implement refined management on users with such permissions. + +Purpose +------- + +Cluster resources are managed in a refined manner so that specific users have only certain permissions (such as adding, querying, and modifying resources). + +Note +---- + +Ensure that kubectl is available on your host. If not, download it from `here `__ (corresponding to the cluster version or the latest version). + +Configuration Method +-------------------- + +.. note:: + + In the following example, only pods and Deployments in the **test** space can be viewed and added, and they cannot be deleted. + +#. Set the service account name to **my-sa** and namespace to **test**. + + .. code-block:: + + kubectl create sa my-sa -n test + + |image1| + +#. Configure the role table and assign operation permissions to different resources. + + .. code-block:: + + vi role-test.yaml + + The content is as follows: + + .. code-block:: + + apiVersion: rbac.authorization.k8s.io/v1 + kind: Role + metadata: + annotations: + rbac.authorization.kubernetes.io/autoupdate: "true" + labels: + kubernetes.io/bootstrapping: rbac-defaults + name: myrole + namespace: test + rules: + - apiGroups: + - "" + resources: + - pods + verbs: + - get + - list + - watch + - apiGroups: + - apps + resources: + - pods + - deployments + verbs: + - get + - list + - watch + - create + + Create a Role. + + .. code-block:: + + kubectl create -f role-test.yaml + + |image2| + +#. Create a RoleBinding and bind the service account to the role so that the user can obtain the corresponding permissions. + + .. code-block:: + + vi myrolebinding.yaml + + The content is as follows: + + .. code-block:: + + apiVersion: rbac.authorization.k8s.io/v1 + kind: RoleBinding + metadata: + name: myrolebinding + namespace: test + roleRef: + apiGroup: rbac.authorization.k8s.io + kind: Role + name: myrole + subjects: + - kind: ServiceAccount + name: my-sa + namespace: test + + Create a RoleBinding. + + .. code-block:: + + kubectl create -f myrolebinding.yaml + + |image3| + + The user information is configured. Now perform :ref:`4 ` to :ref:`6 ` to write the user information to the configuration file. + +#. .. _cce_bestpractice_00221__en-us_topic_0235296162_li756812692518: + + Configure the cluster information. + + a. Use the sa name **my-sa** to obtain the secret corresponding to the sa. In the following example, **my-sa-token-z4967** in the first column is the secret name. + + .. code-block:: + + kubectl get secret -n test |grep my-sa + + |image4| + + b. Decrypt the **ca.crt** file in the secret and export it. + + .. code-block:: + + kubectl get secret my-sa-token-5gpl4 -n test -oyaml |grep ca.crt: | awk '{print $2}' |base64 -d > /home/ca.crt + + c. Set the cluster access mode. **test-arm** indicates the cluster to be accessed, **10.0.1.100** indicates the IP address of the API server in the cluster and **/home/test.config** indicates the path for storing the configuration file. + + - If the internal API server address is used, run the following command: + + .. code-block:: + + kubectl config set-cluster test-arm --server=https://10.0.1.100:5443 --certificate-authority=/home/ca.crt --embed-certs=true --kubeconfig=/home/test.config + + - If the public API server address is used, run the following command: + + .. code-block:: + + kubectl config set-cluster test-arm --server=https://10.0.1.100:5443 --kubeconfig=/home/test.config --insecure-skip-tls-verify=true + + |image5| + + .. note:: + + If you **perform operations on a node in the cluster** or **the node that uses the configuration is a cluster node**, do not set the path of kubeconfig to **/root/.kube/config**. + + The cluster API server address is an intranet API server address. After an EIP is bound to the cluster, the cluster API server address can also be a public API server address. + +#. Configure the cluster authentication information. + + a. Obtain the cluster token. (If the token is obtained in GET mode, you need to run **based64 -d** to decode the token.) + + .. code-block:: + + token=$(kubectl describe secret my-sa-token-5gpl4 -n test | awk '/token:/{print $2}') + + b. Set the cluster user **ui-admin**. + + .. code-block:: + + kubectl config set-credentials ui-admin --token=$token --kubeconfig=/home/test.config + + |image6| + +#. .. _cce_bestpractice_00221__en-us_topic_0235296162_li147965421277: + + Configure the context information for cluster authentication. **ui-admin@test** is the context name. + + .. code-block:: + + kubectl config set-context ui-admin@test --cluster=test-arm --user=ui-admin --kubeconfig=/home/test.config + + |image7| + +#. .. _cce_bestpractice_00221__en-us_topic_0235296162_li1088912408273: + + Set the context. For details about how to use the context, see :ref:`Permissions Verification `. + + .. code-block:: + + kubectl config use-context ui-admin@test --kubeconfig=/home/test.config + + |image8| + + .. note:: + + If you want to assign other users the above permissions to perform operations on the cluster, provide the generated configuration file **/home/test.config** to the user after performing step :ref:`6 `. The user must ensure that the host can access the API server address of the cluster. When performing step :ref:`7 ` on the host and using kubectl, the user must set the kubeconfig parameter to the path of the configuration file. + +.. _cce_bestpractice_00221__en-us_topic_0235296162_section14884146153319: + +Permissions Verification +------------------------ + +#. Pods in the **test** namespace cannot access pods in other namespaces. + + .. code-block:: + + kubectl get pod -n test --kubeconfig=/home/test.config + + |image9| + +#. Pods in the **test** namespace cannot be deleted. + + |image10| + +Further Readings +---------------- + +For more information about users and identity authentication in Kubernetes, see `Authenticating `__. + +.. |image1| image:: /_static/images/en-us_image_0271457115.png +.. |image2| image:: /_static/images/en-us_image_0271467350.png +.. |image3| image:: /_static/images/en-us_image_0271467469.png +.. |image4| image:: /_static/images/en-us_image_0271463079.png +.. |image5| image:: /_static/images/en-us_image_0271466158.png +.. |image6| image:: /_static/images/en-us_image_0271466198.png +.. |image7| image:: /_static/images/en-us_image_0271466336.png +.. |image8| image:: /_static/images/en-us_image_0271466320.png +.. |image9| image:: /_static/images/en-us_image_0271466402.png +.. |image10| image:: /_static/images/en-us_image_0271466430.png diff --git a/umn/source/best_practice/permission/index.rst b/umn/source/best_practice/permission/index.rst new file mode 100644 index 0000000..127d98e --- /dev/null +++ b/umn/source/best_practice/permission/index.rst @@ -0,0 +1,14 @@ +:original_name: cce_bestpractice_0055.html + +.. _cce_bestpractice_0055: + +Permission +========== + +- :ref:`Configuring kubeconfig for Fine-Grained Management on Cluster Resources ` + +.. toctree:: + :maxdepth: 1 + :hidden: + + configuring_kubeconfig_for_fine-grained_management_on_cluster_resources diff --git a/umn/source/best_practice/release/index.rst b/umn/source/best_practice/release/index.rst new file mode 100644 index 0000000..70adcc6 --- /dev/null +++ b/umn/source/best_practice/release/index.rst @@ -0,0 +1,16 @@ +:original_name: cce_bestpractice_10000.html + +.. _cce_bestpractice_10000: + +Release +======= + +- :ref:`Overview ` +- :ref:`Using Services to Implement Simple Grayscale Release and Blue-Green Deployment ` + +.. toctree:: + :maxdepth: 1 + :hidden: + + overview + using_services_to_implement_simple_grayscale_release_and_blue-green_deployment diff --git a/umn/source/best_practice/release/overview.rst b/umn/source/best_practice/release/overview.rst new file mode 100644 index 0000000..77242fa --- /dev/null +++ b/umn/source/best_practice/release/overview.rst @@ -0,0 +1,36 @@ +:original_name: cce_bestpractice_10001.html + +.. _cce_bestpractice_10001: + +Overview +======== + +Challenges +---------- + +When switching between old and new services, you may be challenged in ensuring the system service continuity. If a new service version is directly released to all users at a time, it can be risky because once an online accident or bug occurs, the impact on users is great. It could take a long time to fix the issue. Sometimes, the version has to be rolled back, which severely affects user experience. + +Solutions +--------- + +Several release policies are developed for service upgrade: grayscale release, blue-green deployment, A/B testing, rolling upgrade, and batch suspension of release. Traffic loss or service unavailability caused by releases can be avoided as much as possible. + +This document describes the principles and practices of grayscale release and blue-green deployment. + +- Grayscale release, also called canary release, is a smooth iteration mode for version upgrade. During the upgrade, some users use the new version, while other users continue to use the old version. After the new version is stable and ready, it gradually takes over all the live traffic. In this way, service risks brought by the release of the new version can be minimized, the impact of faults can be reduced, and quick rollback is supported. + + The following figure shows the general process of grayscale release. First, divide 20% of all service traffic to the new version. If the service version runs normally, gradually increase the traffic proportion and continue to test the performance of the new version. If the new version is stable, switch all traffic to it and bring the old version offline. + + |image1| + + If an exception occurs in the new version when 20% of the traffic goes to the new version, you can quickly switch back to the old version. + + |image2| + +- Blue-green deployment provides a zero-downtime, predictable manner for releasing applications to reduce service interruption during the release. A new version is deployed while the old version is retained. The two versions are online at the same time. The new and old versions work in hot backup mode. The route weight is switched (0 or 100) to enable different versions to go online or offline. If a problem occurs, the version can be quickly rolled back. + + |image3| + +.. |image1| image:: /_static/images/en-us_image_0000001214475863.gif +.. |image2| image:: /_static/images/en-us_image_0000001214717329.gif +.. |image3| image:: /_static/images/en-us_image_0000001169315996.gif diff --git a/umn/source/best_practice/release/using_services_to_implement_simple_grayscale_release_and_blue-green_deployment.rst b/umn/source/best_practice/release/using_services_to_implement_simple_grayscale_release_and_blue-green_deployment.rst new file mode 100644 index 0000000..7ab2a75 --- /dev/null +++ b/umn/source/best_practice/release/using_services_to_implement_simple_grayscale_release_and_blue-green_deployment.rst @@ -0,0 +1,264 @@ +:original_name: cce_bestpractice_10002.html + +.. _cce_bestpractice_10002: + +Using Services to Implement Simple Grayscale Release and Blue-Green Deployment +============================================================================== + +To implement grayscale release for a CCE cluster, you need to deploy other open-source tools, such as Nginx Ingress, to the cluster or deploy services to a service mesh. These solutions are difficult to implement. If your grayscale release requirements are simple and you do not want to introduce too many plug-ins or complex configurations, you can refer to this section to implement simple grayscale release and blue-green deployment based on native Kubernetes features. + +Principles +---------- + +Users usually use Kubernetes objects such as Deployments and StatefulSets to deploy services. Each workload manages a group of pods. The following figure uses Deployment as an example. + +|image1| + +Generally, a Service is created for each workload. The Service uses the selector to match the backend pod. Other Services or objects outside the cluster can access the pods backing the Service. If a pod needs to be exposed, set the Service type to LoadBalancer. The ELB load balancer functions as the traffic entrance. + +- **Grayscale release principles** + + Take a Deployment as an example. A Service, in most cases, will be created for each Deployment. However, Kubernetes does not require that Services and Deployments correspond to each other. A Service uses a selector to match backend pods. If pods of different Deployments are selected by the same selector, a Service corresponds to multiple versions of Deployments. You can adjust the number of replicas of Deployments of different versions to adjust the weights of services of different versions to achieve grayscale release. The following figure shows the process: + + |image2| + +- **Blue-green deployment principles** + + Take a Deployment as an example. Two Deployments of different versions have been deployed in the cluster, and their pods are labeled with the same key but different values to distinguish versions. A Service uses the selector to select the pod of a Deployment of a version. In this case, you can change the value of the label that determines the version in the Service selector to change the pod backing the Service. In this way, you can directly switch the service traffic from one version to another. The following figure shows the process: + + |image3| + +Prerequisites +------------- + +The Nginx image has been uploaded to SWR. The Nginx images have two versions: v1 and v2. The welcome pages are **Nginx-v1** and **Nginx-v2**. + +Resource Creation +----------------- + +You can use YAML to deploy Deployments and Services in either of the following ways: + +- On the **Create Deployment** page, click **Create YAML** on the right and edit the YAML file in the window. +- Save the sample YAML file in this section as a file and use kubectl to specify the YAML file. For example, run the **kubectl create -f xxx.yaml** command. + +Step 1: Deploy Services of Two Versions +--------------------------------------- + +Two versions of Nginx services are deployed in the cluster to provide external access through ELB. + +#. Create a Deployment of the first version. The following uses nginx-v1 as an example. Example YAML: + + .. code-block:: + + apiVersion: apps/v1 + kind: Deployment + metadata: + name: nginx-v1 + spec: + replicas: 2 # Number of replicas of the Deployment, that is, the number of pods + selector: # Label selector + matchLabels: + app: nginx + version: v1 + template: + metadata: + labels: # Pod label + app: nginx + version: v1 + spec: + containers: + - image: {your_repository}/nginx:v1 # The image used by the container is nginx:v1. + name: container-0 + resources: + limits: + cpu: 100m + memory: 200Mi + requests: + cpu: 100m + memory: 200Mi + imagePullSecrets: + - name: default-secret + +#. Create a Deployment of the second version. The following uses nginx-v2 as an example. Example YAML: + + .. code-block:: + + apiVersion: apps/v1 + kind: Deployment + metadata: + name: nginx-v2 + spec: + replicas: 2 # Number of replicas of the Deployment, that is, the number of pods + selector: # Label selector + matchLabels: + app: nginx + version: v2 + template: + metadata: + labels: # Pod label + app: nginx + version: v2 + spec: + containers: + - image: {your_repository}/nginx:v2 # The image used by the container is nginx:v2. + name: container-0 + resources: + limits: + cpu: 100m + memory: 200Mi + requests: + cpu: 100m + memory: 200Mi + imagePullSecrets: + - name: default-secret + + You can log in to the CCE console to view the deployment status. + +Step 2: Implement Grayscale Release +----------------------------------- + +#. Create a LoadBalancer Service for the Deployment. Do not specify the version in the selector. Enable the Service to select the pods of the Deployments of two versions. Example YAML: + + .. code-block:: + + apiVersion: v1 + kind: Service + metadata: + annotations: + kubernetes.io/elb.id: 586c97da-a47c-467c-a615-bd25a20de39c # ID of the ELB load balancer. Replace it with the actual value. + name: nginx + spec: + ports: + - name: service0 + port: 80 + protocol: TCP + targetPort: 80 + selector: # The selector does not contain version information. + app: nginx + type: LoadBalancer # Service type (LoadBalancer) + +#. Run the following command to test the access: + + **for i in {1..10}; do curl** \ **; done;** + + indicates the IP address of the ELB load balancer. + + The command output is as follows. Half of the responses are from the Deployment of version v1, and the other half are from version v2. + + .. code-block:: + + Nginx-v2 + Nginx-v1 + Nginx-v1 + Nginx-v1 + Nginx-v2 + Nginx-v1 + Nginx-v2 + Nginx-v1 + Nginx-v2 + Nginx-v2 + +#. Use the console or kubectl to adjust the number of replicas of the Deployments. Change the number of replicas to 4 for v1 and 1 for v2. + + **kubectl scale deployment/nginx-v1 --replicas=4** + + **kubectl scale deployment/nginx-v2 --replicas=1** + +#. Run the following command to test the access again: + + **for i in {1..10}; do curl** \ **; done;** + + indicates the IP address of the ELB load balancer. + + In the command output, among the 10 access requests, only two responses are from the v2 version. The response ratio of the v1 and v2 versions is the same as the ratio of the number of replicas of the v1 and v2 versions, that is, 4:1. Grayscale release is implemented by controlling the number of replicas of services of different versions. + + .. code-block:: + + Nginx-v1 + Nginx-v1 + Nginx-v1 + Nginx-v1 + Nginx-v2 + Nginx-v1 + Nginx-v2 + Nginx-v1 + Nginx-v1 + Nginx-v1 + + .. note:: + + If the ratio of v1 to v2 is not 4:1, you can set the number of access times to a larger value, for example, 20. Theoretically, the more the times, the closer the response ratio between v1 and v2 is to 4:1. + +Step 3: Implement Blue-Green Deployment +--------------------------------------- + +#. Create a LoadBalancer Service for a deployed Deployment and specify that the v1 version is used. Example YAML: + + .. code-block:: + + apiVersion: v1 + kind: Service + metadata: + annotations: + kubernetes.io/elb.id: 586c97da-a47c-467c-a615-bd25a20de39c # ID of the ELB load balancer. Replace it with the actual value. + name: nginx + spec: + ports: + - name: service0 + port: 80 + protocol: TCP + targetPort: 80 + selector: # Set the version to v1 in the selector. + app: nginx + version: v1 + type: LoadBalancer # Service type (LoadBalancer) + +#. Run the following command to test the access: + + **for i in {1..10}; do curl** \ **; done;** + + indicates the IP address of the ELB load balancer. + + The command output is as follows (all responses are from the v1 version): + + .. code-block:: + + Nginx-v1 + Nginx-v1 + Nginx-v1 + Nginx-v1 + Nginx-v1 + Nginx-v1 + Nginx-v1 + Nginx-v1 + Nginx-v1 + Nginx-v1 + +#. Use the console or kubectl to modify the selector of the Service so that the v2 version is selected. + + **kubectl patch service nginx -p '{"spec":{"selector":{"version":"v2"}}}'** + +#. Run the following command to test the access again: + + **for i in {1..10}; do curl** \ **; done;** + + indicates the IP address of the ELB load balancer. + + The returned results show that are all responses are from the v2 version. The blue-green deployment is successfully implemented. + + .. code-block:: + + Nginx-v2 + Nginx-v2 + Nginx-v2 + Nginx-v2 + Nginx-v2 + Nginx-v2 + Nginx-v2 + Nginx-v2 + Nginx-v2 + Nginx-v2 + +.. |image1| image:: /_static/images/en-us_image_0000001169475948.png +.. |image2| image:: /_static/images/en-us_image_0000001168997466.png +.. |image3| image:: /_static/images/en-us_image_0000001214635805.png diff --git a/umn/source/best_practice/security/cluster_security.rst b/umn/source/best_practice/security/cluster_security.rst index ea7b068..aec368a 100644 --- a/umn/source/best_practice/security/cluster_security.rst +++ b/umn/source/best_practice/security/cluster_security.rst @@ -138,7 +138,7 @@ Configuring Network Isolation in a Cluster - Cloud Native Network 2.0 - In the Cloud Native Network 2.0 model, you can configure security groups to isolate networks between pods. For details, see `SecurityGroups `__. + In the Cloud Native Network 2.0 model, you can configure security groups to isolate networks between pods. For details, see `SecurityGroup `__. - VPC network diff --git a/umn/source/best_practice/security/container_security.rst b/umn/source/best_practice/security/container_security.rst index e16075e..dbc2a4e 100644 --- a/umn/source/best_practice/security/container_security.rst +++ b/umn/source/best_practice/security/container_security.rst @@ -120,7 +120,7 @@ If application containers on a node do not need to access Kubernetes, you can pe iptables -I FORWARD -s {container_cidr} -d {Private API server IP} -j REJECT - *{container_cidr}* indicates the container network of the cluster, for example, 10.0.0.0/16, and *{master_ip}* indicates the IP address of the master node. + *{container_cidr}* indicates the container CIDR of the cluster, for example, 10.0.0.0/16. To ensure configuration persistence, you are advised to write the command to the **/etc/rc.local** script. diff --git a/umn/source/best_practice/storage/custom_storage_classes.rst b/umn/source/best_practice/storage/custom_storage_classes.rst index b3079ee..e312d5a 100644 --- a/umn/source/best_practice/storage/custom_storage_classes.rst +++ b/umn/source/best_practice/storage/custom_storage_classes.rst @@ -1,6 +1,6 @@ -:original_name: cce_bestpractice_00281_0.html +:original_name: cce_bestpractice_00281.html -.. _cce_bestpractice_00281_0: +.. _cce_bestpractice_00281: Custom Storage Classes ====================== @@ -147,7 +147,7 @@ For an ultra-high I/O storage class, you can set the class name to **csi-disk-ss .. note:: - The reclamation policy set here has no impact on the SFS Turbo storage. Therefore, the yearly/monthly SFS Turbo resources will not be reclaimed when the cluster or PVC is deleted. + The reclamation policy set here has no impact on the SFS Turbo storage. If high data security is required, you are advised to select **Retain** to prevent data from being deleted by mistake. diff --git a/umn/source/best_practice/storage/dynamically_creating_and_mounting_subdirectories_of_an_sfs_turbo_file_system.rst b/umn/source/best_practice/storage/dynamically_creating_and_mounting_subdirectories_of_an_sfs_turbo_file_system.rst index 46a70e6..1a2b8b2 100644 --- a/umn/source/best_practice/storage/dynamically_creating_and_mounting_subdirectories_of_an_sfs_turbo_file_system.rst +++ b/umn/source/best_practice/storage/dynamically_creating_and_mounting_subdirectories_of_an_sfs_turbo_file_system.rst @@ -1,6 +1,6 @@ -:original_name: cce_bestpractice_00253_0.html +:original_name: cce_bestpractice_00253.html -.. _cce_bestpractice_00253_0: +.. _cce_bestpractice_00253: Dynamically Creating and Mounting Subdirectories of an SFS Turbo File System ============================================================================ @@ -18,14 +18,14 @@ Notes and Constraints - Only clusters of v1.15 and later are supported. - The cluster must use the everest add-on of version 1.1.13 or later. - Kata containers are not supported. -- A maximum of 10 PVCs can be created concurrently at a time by using the subdirectory function. +- When the everest add-on earlier than 1.2.69 or 2.1.11 is used, a maximum of 10 PVCs can be created concurrently at a time by using the subdirectory function. Everest 1.2.69 or later or 2.1.11 or later is recommended. Creating an SFS Turbo Volume of the subpath Type ------------------------------------------------ .. caution:: - The CCE console has not yet supported the operations related to this feature, such as expanding, disassociating, and deleting subPath volumes. + Do not expand, disassociate, or delete subPath volumes. #. Import an SFS Turbo file system that is located in the same VPC and subnet as the cluster. @@ -64,7 +64,7 @@ Creating an SFS Turbo Volume of the subpath Type - In versions later than everest 1.1.13 and earlier than everest 1.2.8, only the **nolock** parameter can be configured. By default, the **nolock** parameter is used for the mount operation and does not need to be configured. If **nolock** is set to **false**, the **lock** field is used. - - Starting from everest 1.2.8, more parameters are supported. The default parameter configurations are shown below. For details, see `Setting Mount Options `__. **Do not set nolock to true. Otherwise, the mount operation fails.** + - Starting from everest 1.2.8, more mount options are supported. For details, see `Setting Mount Options `__. **Do not set nolock to true. Otherwise, the mount operation fails.** .. code-block:: diff --git a/umn/source/best_practice/storage/expanding_node_disk_capacity.rst b/umn/source/best_practice/storage/expanding_node_disk_capacity.rst index c18b43d..cf7bde2 100644 --- a/umn/source/best_practice/storage/expanding_node_disk_capacity.rst +++ b/umn/source/best_practice/storage/expanding_node_disk_capacity.rst @@ -8,8 +8,137 @@ Expanding Node Disk Capacity System Disk ----------- +EulerOS 2.9 is used as the sample OS. Originally, system disk **/dev/vda** has 50 GB and one partition (**/dev/vda1**), and then 50 GB is added to the disk. In this example, the additional 50 GB is allocated to the existing **/dev/vda1** partition. + #. Expand the capacity of the system disk on the EVS console. -#. Restart the node on the ECS console. + +#. Log in to the node and run the **growpart** command to check whether growpart has been installed. + + If the tool operation guide is displayed, the tool has been installed. Otherwise, run the following command to install it: + + .. code-block:: + + yum install cloud-utils-growpart + +#. Run the following command to view the total capacity of the system disk **/dev/vda**: + + .. code-block:: + + fdisk -l + + The following information is displayed, indicating that the total capacity of system disk **/dev/vda** is 100 GiB: + + .. code-block:: console + + [root@test-48162 ~]# fdisk -l + Disk /dev/vda: 100 GiB, 107374182400 bytes, 209715200 sectors + Units: sectors of 1 * 512 = 512 bytes + Sector size (logical/physical): 512 bytes / 512 bytes + I/O size (minimum/optimal): 512 bytes / 512 bytes + Disklabel type: dos + Disk identifier: 0x78d88f0b + + Device Boot Start End Sectors Size Id Type + /dev/vda1 * 2048 104857566 104855519 50G 83 Linux + + Disk /dev/vdb: 100 GiB, 107374182400 bytes, 209715200 sectors + Units: sectors of 1 * 512 = 512 bytes + Sector size (logical/physical): 512 bytes / 512 bytes + I/O size (minimum/optimal): 512 bytes / 512 bytes + + Disk /dev/mapper/vgpaas-dockersys: 90 GiB, 96632569856 bytes, 188735488 sectors + Units: sectors of 1 * 512 = 512 bytes + Sector size (logical/physical): 512 bytes / 512 bytes + I/O size (minimum/optimal): 512 bytes / 512 bytes + + Disk /dev/mapper/vgpaas-kubernetes: 10 GiB, 10733223936 bytes, 20963328 sectors + Units: sectors of 1 * 512 = 512 bytes + Sector size (logical/physical): 512 bytes / 512 bytes + I/O size (minimum/optimal): 512 bytes / 512 bytes + +#. Run the following command to check the capacity of the system disk partition **/dev/vda1**: + + .. code-block:: + + df -TH + + The command output is as follows: + + .. code-block:: console + + [root@test-48162 ~]# df -TH + Filesystem Type Size Used Avail Use% Mounted on + devtmpfs devtmpfs 1.8G 0 1.8G 0% /dev + tmpfs tmpfs 1.8G 0 1.8G 0% /dev/shm + tmpfs tmpfs 1.8G 13M 1.8G 1% /run + tmpfs tmpfs 1.8G 0 1.8G 0% /sys/fs/cgroup + /dev/vda1 ext4 53G 3.3G 47G 7% / + tmpfs tmpfs 1.8G 75M 1.8G 5% /tmp + /dev/mapper/vgpaas-dockersys ext4 95G 1.3G 89G 2% /var/lib/docker + /dev/mapper/vgpaas-kubernetes ext4 11G 39M 10G 1% /mnt/paas/kubernetes/kubelet + ... + +#. Run the following command to extend the partition using growpart: + + .. code-block:: + + growpart System disk Partition number + + Command example: (The system disk has only one partition **/dev/vda1**. Therefore, the partition number is **1**.) + + .. code-block:: + + growpart /dev/vda 1 + + The command output is as follows: + + .. code-block:: + + CHANGED: partition=1 start=2048 old: size=104855519 end=104857567 new: size=209713119 end=209715167 + +#. Run the following command to extend the file system: + + .. code-block:: + + resize2fs Disk partition + + Example command: + + .. code-block:: + + resize2fs /dev/vda1 + + The command output is as follows: + + .. code-block:: + + resize2fs 1.45.6 (20-Mar-2020) + Filesystem at /dev/vda1 is mounted on /; on-line resizing required + old_desc_blocks = 7, new_desc_blocks = 13 + The filesystem on /dev/vda1 is now 26214139 (4k) blocks long. + +#. Run the following command to view the new capacity of the **/dev/vda1** partition: + + .. code-block:: + + df -TH + + Information similar to the following is displayed: + + .. code-block:: console + + [root@test-48162 ~]# df -TH + Filesystem Type Size Used Avail Use% Mounted on + devtmpfs devtmpfs 1.8G 0 1.8G 0% /dev + tmpfs tmpfs 1.8G 0 1.8G 0% /dev/shm + tmpfs tmpfs 1.8G 13M 1.8G 1% /run + tmpfs tmpfs 1.8G 0 1.8G 0% /sys/fs/cgroup + /dev/vda1 ext4 106G 3.3G 98G 4% / + tmpfs tmpfs 1.8G 75M 1.8G 5% /tmp + /dev/mapper/vgpaas-dockersys ext4 95G 1.3G 89G 2% /var/lib/docker + /dev/mapper/vgpaas-kubernetes ext4 11G 39M 10G 1% /mnt/paas/kubernetes/kubelet + ... + #. Log in to the CCE console and click the cluster. In the navigation pane, choose **Nodes**. Click **More** > **Sync Server Data** at the row containing the target node. Node Data Disk (Dedicated for Docker) @@ -63,12 +192,20 @@ Node Data Disk (Dedicated for Docker) │ ... └─vgpaas-kubernetes 253:4 0 10G 0 lvm /mnt/paas/kubernetes/kubelet - Run the following commands on the node to add the new disk capacity to the **thinpool** disk: + - Run the following commands on the node to add the new disk capacity to the **thinpool** disk: - .. code-block:: + .. code-block:: - pvresize /dev/sdb - lvextend -l+100%FREE -n vgpaas/thinpool + pvresize /dev/sdb + lvextend -l+100%FREE -n vgpaas/thinpool + + - Run the following commands on the node to add the new disk capacity to the **dockersys** disk: + + .. code-block:: + + pvresize /dev/sdb + lvextend -l+100%FREE -n vgpaas/dockersys + resize2fs /dev/vgpaas/dockersys Node Data Disk (Kubernetes) --------------------------- diff --git a/umn/source/best_practice/storage/index.rst b/umn/source/best_practice/storage/index.rst index 1c955f5..f706068 100644 --- a/umn/source/best_practice/storage/index.rst +++ b/umn/source/best_practice/storage/index.rst @@ -7,9 +7,9 @@ Storage - :ref:`Expanding Node Disk Capacity ` - :ref:`Mounting an Object Storage Bucket of a Third-Party Tenant ` -- :ref:`Dynamically Creating and Mounting Subdirectories of an SFS Turbo File System ` +- :ref:`Dynamically Creating and Mounting Subdirectories of an SFS Turbo File System ` - :ref:`How Do I Change the Storage Class Used by a Cluster of v1.15 from FlexVolume to CSI Everest? ` -- :ref:`Custom Storage Classes ` +- :ref:`Custom Storage Classes ` - :ref:`Realizing Automatic Topology for EVS Disks When Nodes Are Deployed Across AZs (csi-disk-topology) ` .. toctree:: diff --git a/umn/source/best_practice/storage/mounting_an_object_storage_bucket_of_a_third-party_tenant.rst b/umn/source/best_practice/storage/mounting_an_object_storage_bucket_of_a_third-party_tenant.rst index 9c6ce2a..768ff17 100644 --- a/umn/source/best_practice/storage/mounting_an_object_storage_bucket_of_a_third-party_tenant.rst +++ b/umn/source/best_practice/storage/mounting_an_object_storage_bucket_of_a_third-party_tenant.rst @@ -85,7 +85,7 @@ Statically Importing OBS Buckets and Parallel File Systems fsType: obsfs volumeAttributes: everest.io/obs-volume-type: STANDARD - everest.io/region: eu-de #Set it to the ID of the current region. + everest.io/region: eu-de #Set it to the ID of the current region. storage.kubernetes.io/csiProvisionerIdentity: everest-csi-provisioner volumeHandle: objbucket #Replace the name with the actual bucket name of the third-party tenant. persistentVolumeReclaimPolicy: Retain #This parameter must be set to Retain to ensure that the bucket will not be deleted when a PV is deleted. diff --git a/umn/source/change_history.rst b/umn/source/change_history.rst index 572e0ab..284b946 100644 --- a/umn/source/change_history.rst +++ b/umn/source/change_history.rst @@ -10,6 +10,13 @@ Change History +-----------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Released On | What's New | +===================================+=======================================================================================================================================================================================================================================+ + | 2023-05-30 | - Added\ :ref:`Configuring a Node Pool `. | + | | - Added\ :ref:`Configuring Health Check for Multiple Ports `. | + | | - Updated\ :ref:`Creating a Node `. | + | | - Updated\ :ref:`Creating a Node Pool `. | + | | - Updated\ :ref:`OS Patch Notes for Cluster Nodes `. | + | | - Updated\ :ref:`Notes and Constraints `. | + +-----------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | 2023-02-10 | - Supported the creation of clusters of v1.25. | | | - Added :ref:`Configuring Pod Security Admission `. | | | - Added :ref:`Vulnerability Fixing Policies `. | diff --git a/umn/source/charts/overview.rst b/umn/source/charts/overview.rst index d848ec9..3e359af 100644 --- a/umn/source/charts/overview.rst +++ b/umn/source/charts/overview.rst @@ -33,4 +33,4 @@ Helm can help application orchestration for Kubernetes: - Controls phases in a deployment cycle. - Tests and verifies the released version. -.. |image1| image:: /_static/images/en-us_image_0000001325364477.png +.. |image1| image:: /_static/images/en-us_image_0000001518062492.png diff --git a/umn/source/cloud_trace_service_cts/querying_cts_logs.rst b/umn/source/cloud_trace_service_cts/querying_cts_logs.rst index 3c0459c..19ea48d 100644 --- a/umn/source/cloud_trace_service_cts/querying_cts_logs.rst +++ b/umn/source/cloud_trace_service_cts/querying_cts_logs.rst @@ -42,7 +42,7 @@ Procedure #. Click |image2| on the left of a trace to expand its details, as shown below. - .. figure:: /_static/images/en-us_image_0000001243981141.png + .. figure:: /_static/images/en-us_image_0000001569022781.png :alt: **Figure 1** Expanding trace details **Figure 1** Expanding trace details @@ -50,10 +50,10 @@ Procedure #. Click **View Trace** in the **Operation** column. The trace details are displayed. - .. figure:: /_static/images/en-us_image_0000001244141139.png + .. figure:: /_static/images/en-us_image_0000001517743372.png :alt: **Figure 2** Viewing event details **Figure 2** Viewing event details -.. |image1| image:: /_static/images/en-us_image_0000001244141141.gif -.. |image2| image:: /_static/images/en-us_image_0000001199341250.png +.. |image1| image:: /_static/images/en-us_image_0000001569182497.gif +.. |image2| image:: /_static/images/en-us_image_0000001569182505.png diff --git a/umn/source/clusters/changing_cluster_scale.rst b/umn/source/clusters/changing_cluster_scale.rst index 5521e82..687f58d 100644 --- a/umn/source/clusters/changing_cluster_scale.rst +++ b/umn/source/clusters/changing_cluster_scale.rst @@ -33,4 +33,4 @@ Procedure You can click **Operation Records** in the upper left corner to view the cluster change history. The status changes from **Executing** to **Successful**, indicating that the cluster specifications are successfully changed. -.. |image1| image:: /_static/images/en-us_image_0000001236723668.png +.. |image1| image:: /_static/images/en-us_image_0000001518062664.png diff --git a/umn/source/clusters/cluster_overview/basic_cluster_information.rst b/umn/source/clusters/cluster_overview/basic_cluster_information.rst index f15add4..50114de 100644 --- a/umn/source/clusters/cluster_overview/basic_cluster_information.rst +++ b/umn/source/clusters/cluster_overview/basic_cluster_information.rst @@ -5,7 +5,7 @@ Basic Cluster Information ========================= -`Kubernetes `__ allows you to easily deploy and manage containerized application and facilitates container scheduling and orchestration. +`Kubernetes `__ is an open source container orchestration engine for automating deployment, scaling, and management of containerized applications. For developers, Kubernetes is a cluster operating system. Kubernetes provides service discovery, scaling, load balancing, self-healing, and even leader election, freeing developers from infrastructure-related configurations. @@ -16,10 +16,14 @@ Kubernetes Cluster Architecture A Kubernetes cluster consists of master nodes (Masters) and worker nodes (Nodes). Applications are deployed on worker nodes, and you can specify the nodes for deployment. +.. note:: + + For a cluster created on CCE, the master node is hosted by CCE. You only need to create a node. + The following figure shows the architecture of a Kubernetes cluster. -.. figure:: /_static/images/en-us_image_0267028603.png +.. figure:: /_static/images/en-us_image_0000001568822869.png :alt: **Figure 1** Kubernetes cluster architecture **Figure 1** Kubernetes cluster architecture diff --git a/umn/source/clusters/cluster_overview/cce_turbo_clusters_and_cce_clusters.rst b/umn/source/clusters/cluster_overview/cce_turbo_clusters_and_cce_clusters.rst index 3e752a3..2a5b2e4 100644 --- a/umn/source/clusters/cluster_overview/cce_turbo_clusters_and_cce_clusters.rst +++ b/umn/source/clusters/cluster_overview/cce_turbo_clusters_and_cce_clusters.rst @@ -12,26 +12,25 @@ The following table lists the differences between CCE Turbo clusters and CCE clu .. table:: **Table 1** Cluster types - +-----------------+-----------------------------+--------------------------------------------------------------------------------------------------------------------------------+----------------------------------------------------------------------------------------+ - | Dimension | Sub-dimension | CCE Turbo Cluster | CCE Cluster | - +=================+=============================+================================================================================================================================+========================================================================================+ - | Cluster | Positioning | Next-gen container cluster, with accelerated computing, networking, and scheduling. Designed for Cloud Native 2.0 | Standard cluster for common commercial use | - +-----------------+-----------------------------+--------------------------------------------------------------------------------------------------------------------------------+----------------------------------------------------------------------------------------+ - | | Node type | Hybrid deployment of VMs and bare-metal servers | Hybrid deployment of VMs | - +-----------------+-----------------------------+--------------------------------------------------------------------------------------------------------------------------------+----------------------------------------------------------------------------------------+ - | Networking | Model | **Cloud Native Network 2.0**: applies to large-scale and high-performance scenarios. | **Cloud-native network 1.0**: applies to common, smaller-scale scenarios. | - | | | | | - | | | Max networking scale: 2,000 nodes | - Tunnel network model | - | | | | - VPC network model | - +-----------------+-----------------------------+--------------------------------------------------------------------------------------------------------------------------------+----------------------------------------------------------------------------------------+ - | | Performance | Flattens the VPC network and container network into one. No performance loss. | Overlays the VPC network with the container network, causing certain performance loss. | - +-----------------+-----------------------------+--------------------------------------------------------------------------------------------------------------------------------+----------------------------------------------------------------------------------------+ - | | Container network isolation | Associates pods with security groups. Unifies security isolation in and out the cluster via security groups' network policies. | - Tunnel network model: supports network policies for intra-cluster communications. | - | | | | - VPC network model: supports no isolation. | - +-----------------+-----------------------------+--------------------------------------------------------------------------------------------------------------------------------+----------------------------------------------------------------------------------------+ - | Security | Isolation | - Physical machine: runs Kata containers, allowing VM-level isolation. | Runs common containers, isolated by cgroups. | - | | | - VM: runs common containers. | | - +-----------------+-----------------------------+--------------------------------------------------------------------------------------------------------------------------------+----------------------------------------------------------------------------------------+ + +-----------------+-----------------------------+--------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------+ + | Dimension | Sub-dimension | CCE Turbo cluster | CCE cluster | + +=================+=============================+================================================================================================================================+================================================================================================+ + | Cluster | Positioning | Next-gen container cluster, with accelerated computing, networking, and scheduling. Designed for Cloud Native 2.0 | Standard cluster for common commercial use | + +-----------------+-----------------------------+--------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------+ + | | Node type | Deployment of VMs | Hybrid deployment of VMs and bare metal servers | + +-----------------+-----------------------------+--------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------+ + | Network | Model | **Cloud Native Network 2.0**: applies to large-scale and high-performance scenarios. | **Cloud-native network 1.0**: applies to common, smaller-scale scenarios. | + | | | | | + | | | Max networking scale: 2,000 nodes | - Container tunnel network model | + | | | | - VPC network model | + +-----------------+-----------------------------+--------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------+ + | | Network performance | Flattens the VPC network and container network into one. No performance loss. | Overlays the VPC network with the container network, causing certain performance loss. | + +-----------------+-----------------------------+--------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------+ + | | Container network isolation | Associates pods with security groups. Unifies security isolation in and out the cluster via security groups' network policies. | - Container tunnel network model: supports network policies for intra-cluster communications. | + | | | | - VPC network model: supports no isolation. | + +-----------------+-----------------------------+--------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------+ + | Security | Isolation | - VM: runs common containers, isolated by cgroups. | Common containers are deployed and isolated by cgroups. | + +-----------------+-----------------------------+--------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------+ QingTian Architecture --------------------- @@ -40,4 +39,4 @@ QingTian Architecture The QingTian architecture consists of data plane (software-hardware synergy) and management plane (Alkaid Smart Cloud Brain). The data plane innovates in five dimensions: simplified data center, diversified computing power, QingTian cards, ultra-fast engines, and simplified virtualization, to fully offload and accelerate compute, storage, networking, and security components. VMs, bare metal servers, and containers can run together. As a distributed operating system, the Alkaid Smart Cloud Brain focuses on the cloud, AI, and 5G, and provide all-domain scheduling to achieve cloud-edge-device collaboration and governance. -.. |image1| image:: /_static/images/en-us_image_0000001212924318.png +.. |image1| image:: /_static/images/en-us_image_0000001517743452.png diff --git a/umn/source/clusters/cluster_overview/release_notes/cce_kubernetes_1.21_release_notes.rst b/umn/source/clusters/cluster_overview/release_notes/cce_kubernetes_1.21_release_notes.rst index b646a8e..a40fb66 100644 --- a/umn/source/clusters/cluster_overview/release_notes/cce_kubernetes_1.21_release_notes.rst +++ b/umn/source/clusters/cluster_overview/release_notes/cce_kubernetes_1.21_release_notes.rst @@ -17,7 +17,7 @@ Resource Changes and Deprecations - Graceful node shutdown has been upgraded to the test state. With this update, kubelet can detect that a node is shut down and gracefully terminate the pods on the node. Prior to this update, when the node was shut down, its pod did not follow the expected termination lifecycle, which caused workload problems. Now kubelet can use systemd to detect the systems that are about to be shut down and notify the running pods to terminate them gracefully. - For a pod with multiple containers, you can use **kubectl.kubernetes.io/** to pre-select containers. - PodSecurityPolicy is deprecated. For details, see https://kubernetes.io/blog/2021/04/06/podsecuritypolicy-deprecation-past-present-and-future/. -- The `BoundServiceAccountTokenVolume `__ feature has entered the beta test. This feature improves the token security of the service account and changes the method of mounting tokens to pods. Kubernetes clusters of v1.21 and later enable this approach by default. +- The `BoundServiceAccountTokenVolume `__ feature has entered the beta test. This feature improves the token security of the service account and changes the method of mounting tokens to pods. Kubernetes clusters of v1.21 and later enable this approach by default. **Kubernetes 1.20 Release Notes** diff --git a/umn/source/clusters/cluster_overview/release_notes/cce_kubernetes_1.23_release_notes.rst b/umn/source/clusters/cluster_overview/release_notes/cce_kubernetes_1.23_release_notes.rst index e476d02..9ddd2cb 100644 --- a/umn/source/clusters/cluster_overview/release_notes/cce_kubernetes_1.23_release_notes.rst +++ b/umn/source/clusters/cluster_overview/release_notes/cce_kubernetes_1.23_release_notes.rst @@ -12,7 +12,7 @@ Resource Changes and Deprecations **Changes in CCE 1.23** -- The web-terminal add-on is no longer supported. Use CloudShell or kubectl instead. +- The web-terminal add-on is no longer supported. Use kubectl instead. **Kubernetes 1.23 Release Notes** @@ -28,7 +28,7 @@ Resource Changes and Deprecations - The Kubernetes release cycle is changed from four releases a year to three releases a year. - StatefulSets support **minReadySeconds**. - During scale-in, pods are randomly selected and deleted based on the pod UID by default (LogarithmicScaleDown). This feature enhances the randomness of the pods to be deleted and alleviates the problems caused by pod topology spread constraints. For more information, see `KEP-2185 `__ and `issue 96748 `__. -- The `BoundServiceAccountTokenVolume `__ feature is stable. This feature improves the token security of the service account and changes the method of mounting tokens to pods. Kubernetes clusters of v1.21 and later enable this approach by default. +- The `BoundServiceAccountTokenVolume `__ feature is stable. This feature improves the token security of the service account and changes the method of mounting tokens to pods. Kubernetes clusters of v1.21 and later enable this approach by default. References ---------- diff --git a/umn/source/clusters/creating_a_cce_cluster.rst b/umn/source/clusters/creating_a_cce_cluster.rst index 34da41e..1442a57 100644 --- a/umn/source/clusters/creating_a_cce_cluster.rst +++ b/umn/source/clusters/creating_a_cce_cluster.rst @@ -12,7 +12,7 @@ In CCE, you can create a CCE cluster to manage VMs. By using high-performance ne Notes and Constraints --------------------- -- During the node creation, software packages are downloaded from OBS using the domain name. You need to use a private DNS server to resolve the OBS domain name, and configure the subnet where the node resides with a private DNS server address. When you create a subnet, the private DNS server is used by default. If you change the subnet DNS, ensure that the DNS server in use can resolve the OBS domain name. +- During the node creation, software packages are downloaded from OBS using the domain name. You need to use a private DNS server to resolve the OBS domain name, and configure the DNS server address of the subnet where the node resides with a private DNS server address. When you create a subnet, the private DNS server is used by default. If you change the subnet DNS, ensure that the DNS server in use can resolve the OBS domain name. - You can create a maximum of 50 clusters in a single region. - After a cluster is created, the following items cannot be changed: @@ -80,17 +80,21 @@ Procedure #. Click **Next: Add-on Configuration**. - By default, :ref:`cordens ` and :ref:`everest ` add-ons are installed. + **Domain Name Resolution**: Uses the :ref:`coredns ` add-on, installed by default, to resolve domain names and connect to the cloud DNS server. - **Service log** + **Container Storage**: Uses the :ref:`everest ` add-on, installed by default, to provide container storage based on CSI and connect to cloud storage services such as EVS. - - **ICAgent**: + **Service logs** + + - Using ICAgent: A log collector provided by Application Operations Management (AOM), reporting logs to AOM and Log Tank Service (LTS) according to the log collection rules you configured. You can collect stdout logs as required. -#. After the parameters are specified, click **Next: Confirm**. The cluster resource list is displayed. Confirm the information and click **Submit**. + **Overload Control**: If overload control is enabled, concurrent requests are dynamically controlled based on the resource pressure of master nodes to keep them and the cluster available. + +#. After setting the parameters, click **Next: Confirm**. After confirming that the cluster configuration information is correct, select **I have read and understand the preceding instructions** and click **Submit**. It takes about 6 to 10 minutes to create a cluster. You can click **Back to Cluster List** to perform other operations on the cluster or click **Go to Cluster Events** to view the cluster details. diff --git a/umn/source/clusters/creating_a_cce_turbo_cluster.rst b/umn/source/clusters/creating_a_cce_turbo_cluster.rst index 79cd235..49279dc 100644 --- a/umn/source/clusters/creating_a_cce_turbo_cluster.rst +++ b/umn/source/clusters/creating_a_cce_turbo_cluster.rst @@ -12,7 +12,7 @@ CCE Turbo clusters are paired with the Cloud Native Network 2.0 model for large- Notes and Constraints --------------------- -- During the node creation, software packages are downloaded from OBS using the domain name. You need to use a private DNS server to resolve the OBS domain name, and configure the subnet where the node resides with a private DNS server address. When you create a subnet, the private DNS server is used by default. If you change the subnet DNS, ensure that the DNS server in use can resolve the OBS domain name. +- During the node creation, software packages are downloaded from OBS using the domain name. You need to use a private DNS server to resolve the OBS domain name, and configure the DNS server address of the subnet where the node resides with a private DNS server address. When you create a subnet, the private DNS server is used by default. If you change the subnet DNS, ensure that the DNS server in use can resolve the OBS domain name. - You can create a maximum of 50 clusters in a single region. - CCE Turbo clusters support only Cloud Native Network 2.0. For details about this network model, see :ref:`Cloud Native Network 2.0 `. - After a cluster is created, the following items cannot be changed: @@ -86,7 +86,9 @@ Procedure #. Click **Next: Add-on Configuration**. - By default, :ref:`cordens ` and :ref:`everest ` add-ons are installed. + **Domain Name Resolution**: Uses the :ref:`coredns ` add-on, installed by default, to resolve domain names and connect to the cloud DNS server. + + **Container Storage**: The :ref:`everest ` add-on is installed by default to provide container storage based on CSI and connect to cloud storage services such as EVS. **Service log** @@ -96,6 +98,8 @@ Procedure You can collect stdout logs as required. + **Overload Control**: If overload control is enabled, concurrent requests are dynamically controlled based on the resource pressure of master nodes to keep them and the cluster available. + #. After configuring the parameters, click **Next: Confirm**. It takes about 6 to 10 minutes to create a cluster. You can click **Back to Cluster List** to perform other operations on the cluster or click **Go to Cluster Events** to view the cluster details. diff --git a/umn/source/clusters/managing_a_cluster/managing_cluster_components.rst b/umn/source/clusters/managing_a_cluster/cluster_configuration_management.rst similarity index 54% rename from umn/source/clusters/managing_a_cluster/managing_cluster_components.rst rename to umn/source/clusters/managing_a_cluster/cluster_configuration_management.rst index f6fc814..abaf903 100644 --- a/umn/source/clusters/managing_a_cluster/managing_cluster_components.rst +++ b/umn/source/clusters/managing_a_cluster/cluster_configuration_management.rst @@ -2,8 +2,8 @@ .. _cce_10_0213: -Managing Cluster Components -=========================== +Cluster Configuration Management +================================ Scenario -------- @@ -35,84 +35,86 @@ Procedure .. table:: **Table 2** kube-apiserver parameters - +----------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-----------------------------------------+ - | Parameter | Description | Value | - +========================================+=============================================================================================================================================================================+=========================================+ - | default-not-ready-toleration-seconds | notReady tolerance time, in seconds. NoExecute that is added by default to every pod that does not already have such a toleration. | Default: 300s | - +----------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-----------------------------------------+ - | default-unreachable-toleration-seconds | unreachable tolerance time, in seconds. NoExecute that is added by default to every pod that does not already have such a toleration. | Default: 300s | - +----------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-----------------------------------------+ - | max-mutating-requests-inflight | Maximum number of concurrent mutating requests. When the value of this parameter is exceeded, the server rejects requests. | Default: 1000 | - | | | | - | | The value **0** indicates no limitation. | | - | | | | - | | Manual configuration is no longer supported since cluster v1.21. The value is automatically specified based on the cluster scale. | | - | | | | - | | - **200** for clusters with 50 or 200 nodes | | - | | - **500** for clusters with 1,000 nodes | | - | | - **1000** for clusters with 2,000 nodes | | - +----------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-----------------------------------------+ - | max-requests-inflight | Maximum number of concurrent non-mutating requests. When the value of this parameter is exceeded, the server rejects requests. | Default: 2000 | - | | | | - | | The value **0** indicates no limitation. | | - | | | | - | | Manual configuration is no longer supported since cluster v1.21. The value is automatically specified based on the cluster scale. | | - | | | | - | | - **400** for clusters with 50 or 200 nodes | | - | | - **1000** for clusters with 1,000 nodes | | - | | - **2000** for clusters with 2,000 nodes | | - +----------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-----------------------------------------+ - | service-node-port-range | Range of node port numbers. | Default: | - | | | | - | | | 30000-32767 | - | | | | - | | | Options: | - | | | | - | | | min>20105 | - | | | | - | | | max<32768 | - +----------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-----------------------------------------+ - | support-overload | Cluster overload control. If enabled, concurrent requests are dynamically controlled based on the resource pressure of master nodes to keep them and the cluster available. | - false: Overload control is disabled. | - | | | - true: Overload control is enabled. | - +----------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-----------------------------------------+ + +----------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------+ + | Parameter | Description | Value | + +========================================+===============================================================================================================================================================================================================================================+===================================================================================================================================+ + | default-not-ready-toleration-seconds | notReady tolerance time, in seconds. NoExecute that is added by default to every pod that does not already have such a toleration. | Default: 300s | + +----------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------+ + | default-unreachable-toleration-seconds | unreachable tolerance time, in seconds. NoExecute that is added by default to every pod that does not already have such a toleration. | Default: 300s | + +----------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------+ + | max-mutating-requests-inflight | Maximum number of concurrent mutating requests. When the value of this parameter is exceeded, the server rejects requests. | Manual configuration is no longer supported since cluster v1.21. The value is automatically specified based on the cluster scale. | + | | | | + | | The value **0** indicates no limitation. | - **200** for clusters with 50 or 200 nodes | + | | | - **500** for clusters with 1,000 nodes | + | | | - **1000** for clusters with 2,000 nodes | + +----------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------+ + | max-requests-inflight | Maximum number of concurrent non-mutating requests. When the value of this parameter is exceeded, the server rejects requests. | Manual configuration is no longer supported since cluster v1.21. The value is automatically specified based on the cluster scale. | + | | | | + | | The value **0** indicates no limitation. | - **400** for clusters with 50 or 200 nodes | + | | | - **1000** for clusters with 1,000 nodes | + | | | - **2000** for clusters with 2,000 nodes | + +----------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------+ + | service-node-port-range | NodePort port range. After changing the value, you need to go to the security group page to change the TCP/UDP port range of node security groups 30000 to 32767. Otherwise, ports other than the default port cannot be accessed externally. | Default: | + | | | | + | | | 30000-32767 | + | | | | + | | | Options: | + | | | | + | | | min>20105 | + | | | | + | | | max<32768 | + +----------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------+ + | support-overload | Cluster overload control. If enabled, concurrent requests are dynamically controlled based on the resource pressure of master nodes to keep them and the cluster available. | - false: Overload control is disabled. | + | | | - true: Overload control is enabled. | + +----------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------+ .. table:: **Table 3** kube-controller-manager parameters - +---------------------------------------+-----------------------------------------------------------------------------------------------------------------------+-----------------------+ - | Parameter | Description | Value | - +=======================================+=======================================================================================================================+=======================+ - | concurrent-deployment-syncs | Number of Deployments that are allowed to synchronize concurrently. | Default: 5 | - +---------------------------------------+-----------------------------------------------------------------------------------------------------------------------+-----------------------+ - | concurrent-endpoint-syncs | Number of endpoints that are allowed to synchronize concurrently. | Default: 5 | - +---------------------------------------+-----------------------------------------------------------------------------------------------------------------------+-----------------------+ - | concurrent-gc-syncs | Number of garbage collector workers that are allowed to synchronize concurrently. | Default: 20 | - +---------------------------------------+-----------------------------------------------------------------------------------------------------------------------+-----------------------+ - | concurrent-job-syncs | Number of jobs that can be synchronized at the same time. | Default: 5 | - +---------------------------------------+-----------------------------------------------------------------------------------------------------------------------+-----------------------+ - | concurrent-namespace-syncs | Number of namespaces that are allowed to synchronize concurrently. | Default: 10 | - +---------------------------------------+-----------------------------------------------------------------------------------------------------------------------+-----------------------+ - | concurrent-replicaset-syncs | Number of ReplicaSets that are allowed to synchronize concurrently. | Default: 5 | - +---------------------------------------+-----------------------------------------------------------------------------------------------------------------------+-----------------------+ - | concurrent-resource-quota-syncs | Number of resource quotas that are allowed to synchronize concurrently. | Default: 5 | - +---------------------------------------+-----------------------------------------------------------------------------------------------------------------------+-----------------------+ - | concurrent-service-syncs | Number of Services that are allowed to synchronize concurrently. | Default: 10 | - +---------------------------------------+-----------------------------------------------------------------------------------------------------------------------+-----------------------+ - | concurrent-serviceaccount-token-syncs | Number of service account tokens that are allowed to synchronize concurrently. | Default: 5 | - +---------------------------------------+-----------------------------------------------------------------------------------------------------------------------+-----------------------+ - | concurrent-ttl-after-finished-syncs | Number of TTL-after-finished controller workers that are allowed to synchronize concurrently. | Default: 5 | - +---------------------------------------+-----------------------------------------------------------------------------------------------------------------------+-----------------------+ - | concurrent_rc_syncs | Number of replication controllers that are allowed to synchronize concurrently. | Default: 5 | - +---------------------------------------+-----------------------------------------------------------------------------------------------------------------------+-----------------------+ - | horizontal-pod-autoscaler-sync-period | How often HPA audits metrics in a cluster. | Default: 15 seconds | - +---------------------------------------+-----------------------------------------------------------------------------------------------------------------------+-----------------------+ - | kube-api-qps | Query per second (QPS) to use while talking with kube-apiserver. | Default: 100 | - +---------------------------------------+-----------------------------------------------------------------------------------------------------------------------+-----------------------+ - | kube-api-burst | Burst to use while talking with kube-apiserver. | Default: 100 | - +---------------------------------------+-----------------------------------------------------------------------------------------------------------------------+-----------------------+ - | terminated-pod-gc-threshold | Number of terminated pods that can exist before the terminated pod garbage collector starts deleting terminated pods. | Default: 1000 | - | | | | - | | If <= 0, the terminated pod garbage collector is disabled. | | - +---------------------------------------+-----------------------------------------------------------------------------------------------------------------------+-----------------------+ + +---------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-----------------------+ + | Parameter | Description | Value | + +=======================================+========================================================================================================================================================================+=======================+ + | concurrent-deployment-syncs | Number of Deployments that are allowed to synchronize concurrently. | Default: 5 | + +---------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-----------------------+ + | concurrent-endpoint-syncs | Number of endpoints that are allowed to synchronize concurrently. | Default: 5 | + +---------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-----------------------+ + | concurrent-gc-syncs | Number of garbage collector workers that are allowed to synchronize concurrently. | Default: 20 | + +---------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-----------------------+ + | concurrent-job-syncs | Number of jobs that can be synchronized at the same time. | Default: 5 | + +---------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-----------------------+ + | concurrent-namespace-syncs | Number of namespaces that are allowed to synchronize concurrently. | Default: 10 | + +---------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-----------------------+ + | concurrent-replicaset-syncs | Number of ReplicaSets that are allowed to synchronize concurrently. | Default: 5 | + +---------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-----------------------+ + | concurrent-resource-quota-syncs | Number of resource quotas that are allowed to synchronize concurrently. | Default: 5 | + +---------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-----------------------+ + | concurrent-service-syncs | Number of Services that are allowed to synchronize concurrently. | Default: 10 | + +---------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-----------------------+ + | concurrent-serviceaccount-token-syncs | Number of service account tokens that are allowed to synchronize concurrently. | Default: 5 | + +---------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-----------------------+ + | concurrent-ttl-after-finished-syncs | Number of TTL-after-finished controller workers that are allowed to synchronize concurrently. | Default: 5 | + +---------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-----------------------+ + | concurrent_rc_syncs | Number of replication controllers that are allowed to synchronize concurrently. | Default: 5 | + | | | | + | | .. note:: | | + | | | | + | | This parameter is used only in clusters of v1.19 or earlier. | | + +---------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-----------------------+ + | concurrent-rc-syncs | Number of replication controllers that are allowed to synchronize concurrently. | Default: 5 | + | | | | + | | .. note:: | | + | | | | + | | This parameter is used only in clusters of v1.21 to v1.23. In clusters of v1.25 and later, this parameter is deprecated (officially deprecated from v1.25.3-r0 on). | | + +---------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-----------------------+ + | horizontal-pod-autoscaler-sync-period | How often HPA audits metrics in a cluster. | Default: 15 seconds | + +---------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-----------------------+ + | kube-api-qps | Query per second (QPS) to use while talking with kube-apiserver. | Default: 100 | + +---------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-----------------------+ + | kube-api-burst | Burst to use while talking with kube-apiserver. | Default: 100 | + +---------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-----------------------+ + | terminated-pod-gc-threshold | Number of terminated pods that can exist before the terminated pod garbage collector starts deleting terminated pods. | Default: 1000 | + | | | | + | | If <= 0, the terminated pod garbage collector is disabled. | | + +---------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-----------------------+ .. table:: **Table 4** kube-scheduler parameters @@ -137,7 +139,7 @@ Procedure +----------------------------+----------------------------------------------------------------------------------------------+-----------------------+ | nic-max-above-warm-target | Reclaim number of ENIs pre-bound to a node at the cluster level | Default: 2 | +----------------------------+----------------------------------------------------------------------------------------------+-----------------------+ - | prebound-subeni-percentage | Low threshold of the number of bound ENIs:High threshold of the number of bound ENIs | Default: 0:0 | + | prebound-subeni-percentage | Low threshold of the number of bound ENIs : High threshold of the number of bound ENIs | Default: 0:0 | | | | | | | .. note:: | | | | | | @@ -149,8 +151,8 @@ Procedure References ---------- -- `kube-apiserver `__ +- `kube-apiserver `__ - `kube-controller-manager `__ -- `kube-scheduler `__ +- `kube-scheduler `__ -.. |image1| image:: /_static/images/en-us_image_0000001199757520.png +.. |image1| image:: /_static/images/en-us_image_0000001517903048.png diff --git a/umn/source/clusters/managing_a_cluster/deleting_a_cluster.rst b/umn/source/clusters/managing_a_cluster/deleting_a_cluster.rst index 100f20a..fc387ea 100644 --- a/umn/source/clusters/managing_a_cluster/deleting_a_cluster.rst +++ b/umn/source/clusters/managing_a_cluster/deleting_a_cluster.rst @@ -49,4 +49,4 @@ Procedure The delete operation takes 1 to 3 minutes to complete. -.. |image1| image:: /_static/images/en-us_image_0000001244997085.png +.. |image1| image:: /_static/images/en-us_image_0000001569023085.png diff --git a/umn/source/clusters/managing_a_cluster/hibernating_and_waking_up_a_cluster.rst b/umn/source/clusters/managing_a_cluster/hibernating_and_waking_up_a_cluster.rst index bc87150..9892edf 100644 --- a/umn/source/clusters/managing_a_cluster/hibernating_and_waking_up_a_cluster.rst +++ b/umn/source/clusters/managing_a_cluster/hibernating_and_waking_up_a_cluster.rst @@ -33,5 +33,5 @@ Waking Up a Cluster #. Click |image2| next to the cluster to be woken up. #. When the cluster status changes from **Waking** to **Running**, the cluster is woken up. It takes about 3 to 5 minutes to wake up the cluster. -.. |image1| image:: /_static/images/en-us_image_0000001236562704.png -.. |image2| image:: /_static/images/en-us_image_0000001225747980.png +.. |image1| image:: /_static/images/en-us_image_0000001517743460.png +.. |image2| image:: /_static/images/en-us_image_0000001569182589.png diff --git a/umn/source/clusters/managing_a_cluster/index.rst b/umn/source/clusters/managing_a_cluster/index.rst index e4b3ac6..68d0b13 100644 --- a/umn/source/clusters/managing_a_cluster/index.rst +++ b/umn/source/clusters/managing_a_cluster/index.rst @@ -5,7 +5,7 @@ Managing a Cluster ================== -- :ref:`Managing Cluster Components ` +- :ref:`Cluster Configuration Management ` - :ref:`Deleting a Cluster ` - :ref:`Hibernating and Waking Up a Cluster ` - :ref:`Cluster Overload Control ` @@ -14,7 +14,7 @@ Managing a Cluster :maxdepth: 1 :hidden: - managing_cluster_components + cluster_configuration_management deleting_a_cluster hibernating_and_waking_up_a_cluster cluster_overload_control diff --git a/umn/source/clusters/obtaining_a_cluster_certificate.rst b/umn/source/clusters/obtaining_a_cluster_certificate.rst index 2bc42d4..d98cf05 100644 --- a/umn/source/clusters/obtaining_a_cluster_certificate.rst +++ b/umn/source/clusters/obtaining_a_cluster_certificate.rst @@ -20,7 +20,7 @@ Procedure #. In the **Download X.509 Certificate** dialog box displayed, select the certificate expiration time and download the X.509 certificate of the cluster as prompted. - .. figure:: /_static/images/en-us_image_0000001199181228.png + .. figure:: /_static/images/en-us_image_0000001568822637.png :alt: **Figure 1** Downloading a certificate **Figure 1** Downloading a certificate diff --git a/umn/source/clusters/upgrading_a_cluster/before_you_start.rst b/umn/source/clusters/upgrading_a_cluster/before_you_start.rst index 4e31c57..7803923 100644 --- a/umn/source/clusters/upgrading_a_cluster/before_you_start.rst +++ b/umn/source/clusters/upgrading_a_cluster/before_you_start.rst @@ -22,7 +22,9 @@ Precautions Notes and Constraints --------------------- -- Currently, only CCE clusters consisting of VM nodes can be upgraded. +- Currently, only CCE clusters consisting of VM nodes and CCE Turbo clusters can be upgraded. + +- Currently, clusters using private images cannot be upgraded. - After the cluster is upgraded, if the containerd vulnerability of the container engine is fixed in :ref:`Cluster Version Release Notes `, you need to manually restart containerd for the upgrade to take effect. The same applies to the existing pods. diff --git a/umn/source/clusters/upgrading_a_cluster/index.rst b/umn/source/clusters/upgrading_a_cluster/index.rst index abb1088..72114fb 100644 --- a/umn/source/clusters/upgrading_a_cluster/index.rst +++ b/umn/source/clusters/upgrading_a_cluster/index.rst @@ -7,9 +7,11 @@ Upgrading a Cluster - :ref:`Upgrade Overview ` - :ref:`Before You Start ` +- :ref:`Post-Upgrade Verification ` - :ref:`Performing Replace/Rolling Upgrade ` - :ref:`Performing In-place Upgrade ` - :ref:`Migrating Services Across Clusters of Different Versions ` +- :ref:`Troubleshooting for Pre-upgrade Check Exceptions ` .. toctree:: :maxdepth: 1 @@ -17,6 +19,8 @@ Upgrading a Cluster upgrade_overview before_you_start + post-upgrade_verification/index performing_replace_rolling_upgrade performing_in-place_upgrade migrating_services_across_clusters_of_different_versions + troubleshooting_for_pre-upgrade_check_exceptions/index diff --git a/umn/source/clusters/upgrading_a_cluster/performing_in-place_upgrade.rst b/umn/source/clusters/upgrading_a_cluster/performing_in-place_upgrade.rst index f4c648a..d9b8328 100644 --- a/umn/source/clusters/upgrading_a_cluster/performing_in-place_upgrade.rst +++ b/umn/source/clusters/upgrading_a_cluster/performing_in-place_upgrade.rst @@ -30,28 +30,30 @@ For more information, see :ref:`Before You Start `. Procedure --------- -This section describes how to upgrade a CCE cluster of v1.15 or later. For other versions, see :ref:`Performing Replace/Rolling Upgrade `. +The cluster upgrade goes through check, backup, configuration and upgrade, and verification. -#. Log in to the CCE console and click the cluster name to access the cluster. +#. Log in to the CCE console and access the cluster console. -#. In the navigation pane, choose **Cluster Upgrade**. You can view the new version available for upgrade on the right. +#. In the navigation pane, choose **Cluster Upgrade**. You can view the recommended version on the right. - Check the version information, last update/upgrade time, available upgrade version, and upgrade history of the current cluster. - - The cluster upgrade goes through pre-upgrade check, add-on upgrade/uninstallation, master node upgrade, worker node upgrade, and post-upgrade processing. +#. Select the cluster version to be upgraded and click **Check**. .. note:: - - If your cluster version is up-to-date, the **Upgrade** button is grayed out. - - If your cluster status is abnormal or there are abnormal add-ons, the **Upgrade** button is dimmed. Perform a check by referring to :ref:`Before You Start `. + - If your cluster has a new minor version, you do not need to select the cluster version. The latest minor version is used by default. + - If your cluster has a new major version, you can select a version as required. + - If your cluster is of the latest version, the check entry will be hidden. -#. Click **Upgrade** or **Install Patch** on the right. Set the upgrade parameters. +#. Click **Start Check** and confirm the check. If there are abnormal or risky items in the cluster, handle the exceptions based on the check results displayed on the page and check again. - - **New Version**: Select the Kubernetes version to which the cluster can be upgraded. + - **Exceptions**: View the solution displayed on the page, handle the exceptions and check again. + - **Risk Items**: may affect the cluster upgrade. Check the risk description and see whether you may be impacted. If no risk exists, click **OK** next to the risk item to manually skip this risk item and check again. - - (Optional) **Cluster Backup**: Determine whether to back up the entire master node. This backup mode is recommended. + After the check is passed, click **Next: Back Up**. - A manual confirmation is required for backing up the entire master node. The backup process uses the Cloud Backup and Recovery (CBR) service and takes about 20 minutes. If there are many cloud backup tasks at the current site, the backup time may be prolonged. You are advised to back up the master node. +#. (Optional) Manually back up the data. Data is backed up during the upgrade following a default policy. You can click **Back Up** to manually back up data. If you do not need to manually back up data, click **Next: Configure & Upgrade**. + +#. Configure the upgrade parameters. - **Add-on Upgrade Configuration**: Add-ons that have been installed in your cluster are listed. During the cluster upgrade, the system automatically upgrades the add-ons to be compatible with the target cluster version. You can click **Set** to re-define the add-on parameters. @@ -59,21 +61,22 @@ This section describes how to upgrade a CCE cluster of v1.15 or later. For other If a red dot |image1| is displayed on the right of an add-on, the add-on is incompatible with the target cluster version. During the upgrade, the add-on will be uninstalled and then re-installed. Ensure that the add-on parameters are correctly configured. - - **Node Upgrade Configuration**: Before setting the node upgrade priority, you need to select a node pool. Nodes and node pools will be upgraded according to the priorities you specify. You can set the maximum number of nodes to be upgraded in a batch, or set priorities for nodes to be upgraded. If you do not set this parameter, the system will determine the nodes to upgrade in batches based on specific conditions. + - **Node Upgrade Configuration:** You can set the maximum number of nodes to be upgraded in a batch. + - **Node Priority:** You can set priorities for nodes to be upgraded. If you do not set this parameter, the system will determine the nodes to upgrade in batches based on specific conditions. Before setting the node upgrade priority, you need to select a node pool. Nodes and node pools will be upgraded according to the priorities you specify. - **Add Upgrade Priority**: Add upgrade priorities for node pools. - **Add Node Priority**: After adding a node pool priority, you can set the upgrade sequence of nodes in the node pool. The system upgrades nodes in the sequence you specify. If you skip this setting, the system upgrades nodes based on the default policy. -#. Read the upgrade instructions carefully, and select **I have read and agree to Upgrade Precautions**. Click **Upgrade**. +#. After the configuration is complete, click **Upgrade** and confirm the upgrade. The cluster starts to be upgraded. You can view the process in the lower part of the page. -#. After you click **Upgrade**, the cluster upgrade starts. You can view the upgrade process in the lower part of the page. + During the upgrade, you can click **Suspend** on the right to suspend the cluster upgrade. To continue the upgrade, click **Continue**. When the progress bar reaches 100%, the cluster upgrade is complete. - During the upgrade, you can click **Suspend** on the right to suspend the cluster upgrade. To continue the upgrade, click **Continue**. + .. note:: - If an upgrade failure message is displayed during the cluster upgrade, rectify the fault as prompted and try again. + If an upgrade failure message is displayed during the cluster upgrade, rectify the fault as prompted and try again. -#. When the upgrade progress reaches 100%, the cluster is upgraded. The version information will be properly displayed, and no upgrade is required. +#. After the upgrade is complete, click **Next: Verify**. Verify the upgrade based on the displayed check items. After confirming that all check items are normal, click **Complete** and confirm that the post-upgrade check is complete. -#. After the upgrade is complete, verify the cluster Kubernetes version on the **Clusters** page. + You can verify the cluster Kubernetes version on the **Clusters** page. -.. |image1| image:: /_static/images/en-us_image_0000001244101223.png +.. |image1| image:: /_static/images/en-us_image_0000001517743672.png diff --git a/umn/source/clusters/upgrading_a_cluster/post-upgrade_verification/index.rst b/umn/source/clusters/upgrading_a_cluster/post-upgrade_verification/index.rst new file mode 100644 index 0000000..095e6cd --- /dev/null +++ b/umn/source/clusters/upgrading_a_cluster/post-upgrade_verification/index.rst @@ -0,0 +1,26 @@ +:original_name: cce_10_0560.html + +.. _cce_10_0560: + +Post-Upgrade Verification +========================= + +- :ref:`Service Verification ` +- :ref:`Pod Check ` +- :ref:`Node and Container Network Check ` +- :ref:`Node Label and Taint Check ` +- :ref:`New Node Check ` +- :ref:`New Pod Check ` +- :ref:`Node Skipping Check for Reset ` + +.. toctree:: + :maxdepth: 1 + :hidden: + + service_verification + pod_check + node_and_container_network_check + node_label_and_taint_check + new_node_check + new_pod_check + node_skipping_check_for_reset diff --git a/umn/source/clusters/upgrading_a_cluster/post-upgrade_verification/new_node_check.rst b/umn/source/clusters/upgrading_a_cluster/post-upgrade_verification/new_node_check.rst new file mode 100644 index 0000000..4dc1a13 --- /dev/null +++ b/umn/source/clusters/upgrading_a_cluster/post-upgrade_verification/new_node_check.rst @@ -0,0 +1,21 @@ +:original_name: cce_10_0565.html + +.. _cce_10_0565: + +New Node Check +============== + +Check Item +---------- + +Check whether nodes can be created in the cluster. + +Procedure +--------- + +Go to the CCE console and access the cluster console. Choose **Nodes** in the navigation pane, and click **Create Node**. + +Solution +-------- + +If nodes cannot be created in your cluster after the cluster is upgraded, contact technical support. diff --git a/umn/source/clusters/upgrading_a_cluster/post-upgrade_verification/new_pod_check.rst b/umn/source/clusters/upgrading_a_cluster/post-upgrade_verification/new_pod_check.rst new file mode 100644 index 0000000..1a7f45c --- /dev/null +++ b/umn/source/clusters/upgrading_a_cluster/post-upgrade_verification/new_pod_check.rst @@ -0,0 +1,64 @@ +:original_name: cce_10_0566.html + +.. _cce_10_0566: + +New Pod Check +============= + +Check Item +---------- + +- Check whether pods can be created on the existing nodes after the cluster is upgraded. +- Check whether pods can be created on new nodes after the cluster is upgraded. + +Procedure +--------- + +After creating a node based on :ref:`New Node Check `, create a DaemonSet workload to create pods on each node. + +Go to the CCE console, access the cluster console, and choose **Workloads** in the navigation pane. On the displayed page, switch to the **DaemonSets** tab page and click **Create Workload** or **Create from YAML** in the upper right corner. + +You are advised to use the image for routine tests as the base image. You can deploy a pod by referring to the following YAML file. + +.. note:: + + In this test, YAML deploys DaemonSet in the default namespace, uses **ngxin:perl** as the base image, requests 10 MB CPU and 10 Mi memory, and limits 100 MB CPU and 50 Mi memory. + +.. code-block:: + + apiVersion: apps/v1 + kind: DaemonSet + metadata: + name: post-upgrade-check + namespace: default + spec: + selector: + matchLabels: + app: post-upgrade-check + version: v1 + template: + metadata: + labels: + app: post-upgrade-check + version: v1 + spec: + containers: + - name: container-1 + image: nginx:perl + imagePullPolicy: IfNotPresent + resources: + requests: + cpu: 10m + memory: 10Mi + limits: + cpu: 100m + memory: 50Mi + +After the workload is created, check whether the pod status of the workload is normal. + +After the check is complete, go to the CCE console and access the cluster console. Choose **Workloads** in the navigation pane. On the displayed page, switch to the **DaemonSets** tab page, choose **More** > **Delete** in the **Operation** column of the **post-upgrade-check** workload to delete the test workload. + +Solution +-------- + +If the pod cannot be created or the pod status is abnormal, contact technical support and specify whether the exception occurs on new nodes or existing nodes. diff --git a/umn/source/clusters/upgrading_a_cluster/post-upgrade_verification/node_and_container_network_check.rst b/umn/source/clusters/upgrading_a_cluster/post-upgrade_verification/node_and_container_network_check.rst new file mode 100644 index 0000000..49c6fd2 --- /dev/null +++ b/umn/source/clusters/upgrading_a_cluster/post-upgrade_verification/node_and_container_network_check.rst @@ -0,0 +1,68 @@ +:original_name: cce_10_0563.html + +.. _cce_10_0563: + +Node and Container Network Check +================================ + +Check Item +---------- + +- Check whether the nodes are running properly. +- Check whether the node network is normal. +- Check whether the container network is normal. + +Procedure +--------- + +The node status reflects whether the node component or network is normal. + +Go to the CCE console and access the cluster console. Choose **Nodes** in the navigation pane. You can filter node status by status to check whether there are abnormal nodes. + +|image1| + +The container network affects services. Check whether your services are available. + +Solution +-------- + +If the node status is abnormal, contact technical support. + +If the container network is abnormal and your services are affected, contact technical support and confirm the abnormal network access path. + ++----------------------------------------------+------------------------------------------------------------------------------+--------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------+ +| Source | Destination | Destination Type | Possible Fault | ++==============================================+==============================================================================+======================================+======================================================================================================================================+ +| - Pods (inside a cluster) | Public IP address of Service ELB | Cluster traffic load balancing entry | No record. | +| - Nodes (inside a cluster) | | | | +| - Nodes in the same VPC (outside a cluster) | | | | +| - Third-party clouds | | | | ++----------------------------------------------+------------------------------------------------------------------------------+--------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------+ +| | Private IP address of Service ELB | Cluster traffic load balancing entry | No record. | ++----------------------------------------------+------------------------------------------------------------------------------+--------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------+ +| | Public IP address of ingress ELB | Cluster traffic load balancing entry | No record. | ++----------------------------------------------+------------------------------------------------------------------------------+--------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------+ +| | Private IP address of ingress ELB | Cluster traffic load balancing entry | No record. | ++----------------------------------------------+------------------------------------------------------------------------------+--------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------+ +| | Public IP address of NodePort Service | Cluster traffic entry | The kube proxy configuration is overwritten. This fault has been rectified in the upgrade process. | ++----------------------------------------------+------------------------------------------------------------------------------+--------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------+ +| | Private IP address of NodePort Service | Cluster traffic entry | No record. | ++----------------------------------------------+------------------------------------------------------------------------------+--------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------+ +| | ClusterIP Service | Service network plane | No record. | ++----------------------------------------------+------------------------------------------------------------------------------+--------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------+ +| | Non NodePort Service port | Container network | No record. | ++----------------------------------------------+------------------------------------------------------------------------------+--------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------+ +| | Cross-node pods | Container network plane | No record. | ++----------------------------------------------+------------------------------------------------------------------------------+--------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------+ +| | Pods on the same node | Container network plane | No record. | ++----------------------------------------------+------------------------------------------------------------------------------+--------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------+ +| | Service and pod domain names are resolved by CoreDNS. | Domain name resolution | No record. | ++----------------------------------------------+------------------------------------------------------------------------------+--------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------+ +| | External domain names are resolved based on the CoreDNS hosts configuration. | Domain name resolution | After the coredns add-on is upgraded, the configuration is overwritten. This fault has been rectified in the add-on upgrade process. | ++----------------------------------------------+------------------------------------------------------------------------------+--------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------+ +| | External domain names are resolved based on the CoreDNS upstream server. | Domain name resolution | After the coredns add-on is upgraded, the configuration is overwritten. This fault has been rectified in the add-on upgrade process. | ++----------------------------------------------+------------------------------------------------------------------------------+--------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------+ +| | External domain names are not resolved by CoreDNS. | Domain name resolution | No record. | ++----------------------------------------------+------------------------------------------------------------------------------+--------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------+ + +.. |image1| image:: /_static/images/en-us_image_0000001518062524.png diff --git a/umn/source/clusters/upgrading_a_cluster/post-upgrade_verification/node_label_and_taint_check.rst b/umn/source/clusters/upgrading_a_cluster/post-upgrade_verification/node_label_and_taint_check.rst new file mode 100644 index 0000000..61234d3 --- /dev/null +++ b/umn/source/clusters/upgrading_a_cluster/post-upgrade_verification/node_label_and_taint_check.rst @@ -0,0 +1,26 @@ +:original_name: cce_10_0564.html + +.. _cce_10_0564: + +Node Label and Taint Check +========================== + +Check Item +---------- + +- Check whether the label is lost. +- Check whether there are unexpected taints. + +Procedure +--------- + +Go to the CCE console, access the cluster console, and choose **Nodes** in the navigation pane. On the displayed page, click the **Nodes** tab, select all nodes, and click **Manage Labels and Taints** to view the labels and taints of the current node. + +Solution +-------- + +User labels are not changed during the cluster upgrade. If you find that labels are lost or added abnormally, contact technical support. + +If you find a new taint (**node.kubernetes.io/upgrade**) on a node, the node may be skipped during the upgrade. For details, see :ref:`Node Skipping Check for Reset `. + +If you find that other taints are added to the node, contact technical support. diff --git a/umn/source/clusters/upgrading_a_cluster/post-upgrade_verification/node_skipping_check_for_reset.rst b/umn/source/clusters/upgrading_a_cluster/post-upgrade_verification/node_skipping_check_for_reset.rst new file mode 100644 index 0000000..69ab900 --- /dev/null +++ b/umn/source/clusters/upgrading_a_cluster/post-upgrade_verification/node_skipping_check_for_reset.rst @@ -0,0 +1,22 @@ +:original_name: cce_10_0567.html + +.. _cce_10_0567: + +Node Skipping Check for Reset +============================= + +Check Item +---------- + +After the cluster is upgraded, you need to reset the nodes that fail to be upgraded. + +Procedure +--------- + +Go back to the previous step or view the upgrade details on the upgrade history page to view the nodes that are skipped during the upgrade. + +The skipped nodes are displayed on the upgrade details page. Reset the skipped nodes after the upgrade is complete. For details about how to reset a node, see :ref:`Resetting a Node `. + +.. note:: + + Resetting a node will reset all node labels, which may affect workload scheduling. Before resetting a node, check and retain the labels that you have manually added to the node. diff --git a/umn/source/clusters/upgrading_a_cluster/post-upgrade_verification/pod_check.rst b/umn/source/clusters/upgrading_a_cluster/post-upgrade_verification/pod_check.rst new file mode 100644 index 0000000..c3740f5 --- /dev/null +++ b/umn/source/clusters/upgrading_a_cluster/post-upgrade_verification/pod_check.rst @@ -0,0 +1,31 @@ +:original_name: cce_10_0562.html + +.. _cce_10_0562: + +Pod Check +========= + +Check Item +---------- + +- Check whether unexpected pods exist in the cluster. +- Check whether there are pods restart unexpectedly in the cluster. + +Procedure +--------- + +Go to the CCE console and access the cluster console. Choose **Workloads** in the navigation pane. On the displayed page, switch to the **Pods** tab page. Select **All namespaces**, click **Status**, and check whether abnormal pods exist. + +|image1| + +View the **Restarts** column to check whether there are pods that are restarted abnormally. + +|image2| + +Solution +-------- + +If there are abnormal pods in your cluster after the cluster upgrade, contact technical support. + +.. |image1| image:: /_static/images/en-us_image_0000001518222492.png +.. |image2| image:: /_static/images/en-us_image_0000001518062540.png diff --git a/umn/source/clusters/upgrading_a_cluster/post-upgrade_verification/service_verification.rst b/umn/source/clusters/upgrading_a_cluster/post-upgrade_verification/service_verification.rst new file mode 100644 index 0000000..ff9d008 --- /dev/null +++ b/umn/source/clusters/upgrading_a_cluster/post-upgrade_verification/service_verification.rst @@ -0,0 +1,28 @@ +:original_name: cce_10_0561.html + +.. _cce_10_0561: + +Service Verification +==================== + +Check Item +---------- + +After the cluster is upgraded, check whether the services are running normal. + +Procedure +--------- + +Different services have different verification mode. Select a suitable one and verify the service before and after the upgrade. + +You can verify the service from the following aspects: + +- The service page is available. +- No alarm or event is generated on the normal platform. +- No error log is generated for key processes. +- The API dialing test is normal. + +Solution +-------- + +If your online services are abnormal after the cluster upgrade, contact technical support. diff --git a/umn/source/clusters/upgrading_a_cluster/troubleshooting_for_pre-upgrade_check_exceptions/cce-hpa-controller_restriction_check.rst b/umn/source/clusters/upgrading_a_cluster/troubleshooting_for_pre-upgrade_check_exceptions/cce-hpa-controller_restriction_check.rst new file mode 100644 index 0000000..d814ec8 --- /dev/null +++ b/umn/source/clusters/upgrading_a_cluster/troubleshooting_for_pre-upgrade_check_exceptions/cce-hpa-controller_restriction_check.rst @@ -0,0 +1,16 @@ +:original_name: cce_10_0479.html + +.. _cce_10_0479: + +cce-hpa-controller Restriction Check +==================================== + +Check Item +---------- + +Check whether the current cce-controller-hpa add-on has compatibility restrictions. + +Solution +-------- + +The current cce-controller-hpa add-on has compatibility restrictions. An add-on that can provide metric APIs, for example, metric-server, must be installed in the cluster. diff --git a/umn/source/clusters/upgrading_a_cluster/troubleshooting_for_pre-upgrade_check_exceptions/checking_coredns_configuration_consistency.rst b/umn/source/clusters/upgrading_a_cluster/troubleshooting_for_pre-upgrade_check_exceptions/checking_coredns_configuration_consistency.rst new file mode 100644 index 0000000..bf07507 --- /dev/null +++ b/umn/source/clusters/upgrading_a_cluster/troubleshooting_for_pre-upgrade_check_exceptions/checking_coredns_configuration_consistency.rst @@ -0,0 +1,78 @@ +:original_name: cce_10_0493.html + +.. _cce_10_0493: + +Checking CoreDNS Configuration Consistency +========================================== + +Check Item +---------- + +Check whether the current CoreDNS key configuration Corefile is different from the Helm Release record. The difference may be overwritten during the add-on upgrade, affecting domain name resolution in the cluster. + +Solution +-------- + +You can upgrade the coredns add-on separately after confirming the configuration differences. + +#. For details about how to configure kubectl, see :ref:`Connecting to a Cluster Using kubectl `. + +#. .. _cce_10_0493__en-us_topic_0000001548755413_li1178291934910: + + Obtain the Corefile that takes effect currently. + + .. code-block:: + + kubectl get cm -nkube-system coredns -o jsonpath='{.data.Corefile}' > corefile_now.txt + cat corefile_now.txt + +#. .. _cce_10_0493__en-us_topic_0000001548755413_li111544111811: + + Obtain the Corefile in the Helm Release record (depending on Python 3). + + .. code-block:: + + latest_release=`kubectl get secret -nkube-system -l owner=helm -l name=cceaddon-coredns --sort-by=.metadata.creationTimestamp | awk 'END{print $1}'` + kubectl get secret -nkube-system $latest_release -o jsonpath='{.data.release}' | base64 -d | base64 -d | gzip -d | python -m json.tool | python -c " + import json,sys,re,yaml; + manifests = json.load(sys.stdin)['manifest'] + files = re.split('(?:^|\s*\n)---\s*',manifests) + for file in files: + if 'coredns/templates/configmap.yaml' in file and 'Corefile' in file: + corefile = yaml.safe_load(file)['data']['Corefile'] + print(corefile,end='') + exit(0); + print('error') + exit(1); + " > corefile_record.txt + cat corefile_record.txt + +#. Compare the output information of :ref:`2 ` and :ref:`3 `. + + .. code-block:: + + diff corefile_now.txt corefile_record.txt -y; + + |image1| + +#. Return to the CCE console and click the cluster name to go to the cluster console. On the **Add-ons** page, select the coredns add-on and click **Upgrade**. + + To retain the differentiated configurations, use either of the following methods: + + - Set **parameterSyncStrategy** to **force**. You need to manually enter the differentiated configurations. For details, see :ref:`coredns (System Resource Add-On, Mandatory) `. + - If **parameterSyncStrategy** is set to **inherit**, differentiated configurations are automatically inherited. The system automatically parses, identifies, and inherits differentiated parameters. + + |image2| + +#. Click **OK**. After the add-on upgrade is complete, check whether all CoreDNS instances are available and whether the Corefile meets the expectation. + + .. code-block:: + + kubectl get cm -nkube-system coredns -o jsonpath='{.data.Corefile}' + +#. Change the value of **parameterSyncStrategy** to **ensureConsistent** to enable configuration consistency verification. + + Use the parameter configuration function of CCE add-on management to modify the Corefile configuration to avoid differences. + +.. |image1| image:: /_static/images/en-us_image_0000001628843805.png +.. |image2| image:: /_static/images/en-us_image_0000001578443828.png diff --git a/umn/source/clusters/upgrading_a_cluster/troubleshooting_for_pre-upgrade_check_exceptions/checking_deprecated_kubernetes_apis.rst b/umn/source/clusters/upgrading_a_cluster/troubleshooting_for_pre-upgrade_check_exceptions/checking_deprecated_kubernetes_apis.rst new file mode 100644 index 0000000..dc9b337 --- /dev/null +++ b/umn/source/clusters/upgrading_a_cluster/troubleshooting_for_pre-upgrade_check_exceptions/checking_deprecated_kubernetes_apis.rst @@ -0,0 +1,28 @@ +:original_name: cce_10_0487.html + +.. _cce_10_0487: + +Checking Deprecated Kubernetes APIs +=================================== + +Check Item +---------- + +The system scans the audit logs of the past day to check whether the user calls the deprecated APIs of the target Kubernetes version. + +.. note:: + + Due to the limited time range of audit logs, this check item is only an auxiliary method. APIs to be deprecated may have been used in the cluster, but their usage is not included in the audit logs of the past day. Check the API usage carefully. + +Solution +-------- + +**Description** + +The check result shows that your cluster calls a deprecated API of the target cluster version through kubectl or other applications. You can rectify the fault before the upgrade. Otherwise, the API will be intercepted by kube-apiserver after the upgrade. For details about each deprecated API, see `Deprecated API Migration Guide `__. + +**Cases** + +Ingresses of extensions/v1beta1 and networking.k8s.io/v1beta1 API are deprecated in clusters of v1.22. If you upgrade a CCE cluster from v1.19 or v1.21 to v1.23, existing resources are not affected, but the v1beta1 API version may be intercepted in the creation and editing scenarios. + +For details about the YAML configuration structure changes, see :ref:`Using kubectl to Create an ELB Ingress `. diff --git a/umn/source/clusters/upgrading_a_cluster/troubleshooting_for_pre-upgrade_check_exceptions/checking_the_add-on.rst b/umn/source/clusters/upgrading_a_cluster/troubleshooting_for_pre-upgrade_check_exceptions/checking_the_add-on.rst new file mode 100644 index 0000000..380b24b --- /dev/null +++ b/umn/source/clusters/upgrading_a_cluster/troubleshooting_for_pre-upgrade_check_exceptions/checking_the_add-on.rst @@ -0,0 +1,29 @@ +:original_name: cce_10_0433.html + +.. _cce_10_0433: + +Checking the Add-on +=================== + +Check Item +---------- + +Check the following aspects: + +- Check whether the add-on status is normal. +- Check whether the add-on supports the target version. + +Solution +-------- + +- **Scenario 1: The add-on status is abnormal.** + + Log in to the CCE console and go to the target cluster. Choose **O&M** > **Add-ons** to view and handle the abnormal add-on. + +- **Scenario 2: The target version does not support the current add-on.** + + The add-on cannot be automatically upgraded with the cluster. Log in to the CCE console and go to the target cluster. Choose **O&M** > **Add-ons** to manually upgrade the add-on. + +- **Scenario 3: The add-on does not support the target cluster even if the add-on is upgraded to the latest version. In this case, go to the cluster console and choose Cluster Information > O&M > Add-ons in the navigation pane to manually uninstall the add-on.** + + For details about the supported add-on versions and replacement solutions, see the :ref:`help document `. diff --git a/umn/source/clusters/upgrading_a_cluster/troubleshooting_for_pre-upgrade_check_exceptions/checking_the_blocklist.rst b/umn/source/clusters/upgrading_a_cluster/troubleshooting_for_pre-upgrade_check_exceptions/checking_the_blocklist.rst new file mode 100644 index 0000000..132914b --- /dev/null +++ b/umn/source/clusters/upgrading_a_cluster/troubleshooting_for_pre-upgrade_check_exceptions/checking_the_blocklist.rst @@ -0,0 +1,21 @@ +:original_name: cce_10_0432.html + +.. _cce_10_0432: + +Checking the Blocklist +====================== + +Check Item +---------- + +Check whether the current user is in the upgrade blocklist. + +Solution +-------- + +CCE temporarily disables the cluster upgrade function due to the following reasons: + +- The cluster is identified as the core production cluster. +- Other O&M tasks are being or will be performed to improve cluster stability, for example, 3AZ reconstruction of the master node. + +You can contact technical support. diff --git a/umn/source/clusters/upgrading_a_cluster/troubleshooting_for_pre-upgrade_check_exceptions/checking_the_helm_chart.rst b/umn/source/clusters/upgrading_a_cluster/troubleshooting_for_pre-upgrade_check_exceptions/checking_the_helm_chart.rst new file mode 100644 index 0000000..2f30fc8 --- /dev/null +++ b/umn/source/clusters/upgrading_a_cluster/troubleshooting_for_pre-upgrade_check_exceptions/checking_the_helm_chart.rst @@ -0,0 +1,20 @@ +:original_name: cce_10_0434.html + +.. _cce_10_0434: + +Checking the Helm Chart +======================= + +Check Item +---------- + +Check whether the current HelmRelease record contains discarded Kubernetes APIs that are not supported by the target cluster version. If yes, the Helm chart may be unavailable after the upgrade. + +Solution +-------- + +Convert the discarded Kubernetes APIs to APIs that are compatible with both the source and target versions. + +.. note:: + + This item has been automatically processed in the upgrade process. You can ignore this item. diff --git a/umn/source/clusters/upgrading_a_cluster/troubleshooting_for_pre-upgrade_check_exceptions/checking_the_master_node_ssh_connectivity.rst b/umn/source/clusters/upgrading_a_cluster/troubleshooting_for_pre-upgrade_check_exceptions/checking_the_master_node_ssh_connectivity.rst new file mode 100644 index 0000000..5e159fe --- /dev/null +++ b/umn/source/clusters/upgrading_a_cluster/troubleshooting_for_pre-upgrade_check_exceptions/checking_the_master_node_ssh_connectivity.rst @@ -0,0 +1,16 @@ +:original_name: cce_10_0435.html + +.. _cce_10_0435: + +Checking the Master Node SSH Connectivity +========================================= + +Check Item +---------- + +Check whether CCE can connect to your master nodes. + +Solution +-------- + +Contact technical support. diff --git a/umn/source/clusters/upgrading_a_cluster/troubleshooting_for_pre-upgrade_check_exceptions/checking_the_node.rst b/umn/source/clusters/upgrading_a_cluster/troubleshooting_for_pre-upgrade_check_exceptions/checking_the_node.rst new file mode 100644 index 0000000..07c7d2c --- /dev/null +++ b/umn/source/clusters/upgrading_a_cluster/troubleshooting_for_pre-upgrade_check_exceptions/checking_the_node.rst @@ -0,0 +1,58 @@ +:original_name: cce_10_0431.html + +.. _cce_10_0431: + +Checking the Node +================= + +Check Item +---------- + +Check the following aspects: + +- Check whether the node is available. +- Check whether the node OS supports the upgrade. +- Check whether there are unexpected node pool tags in the node. +- Check whether the Kubernetes node name is consistent with the ECS name. + +Solution +-------- + +- **Scenario 1: The node is unavailable.** + + Log in to the CCE console and access the cluster console. Choose **Nodes** in the navigation pane and check the node status. Ensure that the node is in the **Running** status. A node in the **Installing** or **Deleting** status cannot be upgraded. + + If the node status is abnormal, restore the node by referring to and retry the check task. + +- **Scenario 2: The node OS does not support the upgrade.** + + The following table lists the node OSs that support the upgrade. You can reset the node OS to an available OS in the list. + + .. table:: **Table 1** OSs that support the upgrade + + +-----------------+-----------------------------------------------------------------------------------------------------------------------+ + | OS | Restriction | + +=================+=======================================================================================================================+ + | EulerOS 2.5/2.9 | None | + +-----------------+-----------------------------------------------------------------------------------------------------------------------+ + | CentOS 7.7 | None | + +-----------------+-----------------------------------------------------------------------------------------------------------------------+ + | Ubuntu 22.04 | Some sites cannot perform upgrade. If the check result shows the upgrade is not supported, contact technical support. | + +-----------------+-----------------------------------------------------------------------------------------------------------------------+ + +- **Scenario 3: There are unexpected node pool tags in the node.** + + If a node is migrated from a node pool to the default node pool, the node pool label **cce.cloud.com/cce-nodepool** is retained, affecting cluster upgrade. Check whether the load scheduling on the node depends on the label. + + - If there is no dependency, delete the tag. + - If yes, modify the load balancing policy, remove the dependency, and then delete the tag. + +- **Scenario 4: The Kubernetes node name is consistent with the ECS name.** + + Kubernetes node name, which defaults to the node's private IP. If you select a cloud server name as the node name, the cluster cannot be upgraded. + + Log in to the CCE console and access the cluster console. Choose **Nodes** in the navigation pane, view the node label, and check whether the value of **kubernetes.io/hostname** is consistent with the ECS name. If they are the same, remove the node before the cluster upgrade. + + |image1| + +.. |image1| image:: /_static/images/en-us_image_0000001517903020.png diff --git a/umn/source/clusters/upgrading_a_cluster/troubleshooting_for_pre-upgrade_check_exceptions/checking_the_node_pool.rst b/umn/source/clusters/upgrading_a_cluster/troubleshooting_for_pre-upgrade_check_exceptions/checking_the_node_pool.rst new file mode 100644 index 0000000..012260d --- /dev/null +++ b/umn/source/clusters/upgrading_a_cluster/troubleshooting_for_pre-upgrade_check_exceptions/checking_the_node_pool.rst @@ -0,0 +1,45 @@ +:original_name: cce_10_0436.html + +.. _cce_10_0436: + +Checking the Node Pool +====================== + +Check Item +---------- + +Check the following aspects: + +- Check the node status. +- Check whether the auto scaling function of the node pool is disabled. + +Solution +-------- + +- **Scenario 1: The node pool status is abnormal.** + + Log in to the CCE console, go to the target cluster and choose **Nodes**. On the displayed page, click **Node Pools** tab and check the node pool status. If the node pool is being scaled, wait until the scaling is complete, and disable the auto scaling function by referring to :ref:`Scenario 2 `. + +- .. _cce_10_0436__li2791152121810: + + **Scenario 2: The auto scaling function of the node pool is enabled.** + + **Solution 1 (Recommended)** + + Log in to the CCE console and go to the target cluster. Choose **O&M** > **Add-ons** and uninstall the autoscaler add-on. + + .. note:: + + Before uninstalling the autoscaler add-on, click **Upgrade** to back up the configuration so that the add-on configuration can be restored during reinstallation. + + Before uninstalling the autoscaler add-on, choose **O&M** > **Node Scaling** and back up the current scaling policies so that they can be restored during reinstallation. These policies will be deleted when the autoscaler add-on is uninstalled. + + Obtain and back up the node scaling policy by clicking **Edit**. + + **Solution 2** + + If you do not want to uninstall the autoscaler add-on, log in to the CCE console and access the cluster detail page. Choose **Nodes** in the navigation pane. On the displayed page, click the **Node Pools** tab and click **Edit** of the corresponding node pool to disable the auto scaling function. + + .. note:: + + Before disabling the auto scaling function, back up the autoscaling configuration so that the configuration can be restored when the function is enabled. diff --git a/umn/source/clusters/upgrading_a_cluster/troubleshooting_for_pre-upgrade_check_exceptions/checking_the_security_group.rst b/umn/source/clusters/upgrading_a_cluster/troubleshooting_for_pre-upgrade_check_exceptions/checking_the_security_group.rst new file mode 100644 index 0000000..db669df --- /dev/null +++ b/umn/source/clusters/upgrading_a_cluster/troubleshooting_for_pre-upgrade_check_exceptions/checking_the_security_group.rst @@ -0,0 +1,23 @@ +:original_name: cce_10_0437.html + +.. _cce_10_0437: + +Checking the Security Group +=========================== + +Check Item +---------- + +Check whether the security group allows the master node to access nodes using ICMP. + +Solution +-------- + +Log in to the VPC console, choose **Access Control** > **Security Groups**, and enter the target cluster name in the search box. Two security groups are displayed: + +- The security group name is **cluster name-node-xxx**. This security group is associated with the user nodes. +- The security group name is **cluster name-control-xxx**. This security group is associated with the master nodes. + +Click the security group of the node user and ensure that the following rules are configured to allow the master node to access the node using **ICMP**. + +Otherwise, add a rule to the node security group. Set **Source** to **Security group**. diff --git a/umn/source/node_pools/managing_a_node_pool.rst b/umn/source/clusters/upgrading_a_cluster/troubleshooting_for_pre-upgrade_check_exceptions/compatibility_risk.rst similarity index 52% rename from umn/source/node_pools/managing_a_node_pool.rst rename to umn/source/clusters/upgrading_a_cluster/troubleshooting_for_pre-upgrade_check_exceptions/compatibility_risk.rst index ccac6d4..3dc0be0 100644 --- a/umn/source/node_pools/managing_a_node_pool.rst +++ b/umn/source/clusters/upgrading_a_cluster/troubleshooting_for_pre-upgrade_check_exceptions/compatibility_risk.rst @@ -1,267 +1,66 @@ -:original_name: cce_10_0222.html +:original_name: cce_10_0441.html -.. _cce_10_0222: +.. _cce_10_0441: -Managing a Node Pool -==================== +Compatibility Risk +================== -Notes and Constraints +Check Item +---------- + +Read the version compatibility differences and ensure that they are not affected. + +The patch upgrade does not involve version compatibility differences. + +Version compatibility --------------------- -The default node pool DefaultPool does not support the following management operations. - -Configuring Kubernetes Parameters ---------------------------------- - -CCE allows you to highly customize Kubernetes parameter settings on core components in a cluster. For more information, see `kubelet `__. - -This function is supported only in clusters of **v1.15 and later**. It is not displayed for clusters earlier than v1.15. - -#. Log in to the CCE console. -#. Click the cluster name and access the cluster console. Choose **Nodes** in the navigation pane and click the **Node Pools** tab on the right. -#. Choose **More** > **Manage** next to the node pool name. -#. On the **Manage Component** page on the right, change the values of the following Kubernetes parameters: - - .. table:: **Table 1** kubelet - - +----------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ - | Parameter | Description | Default Value | Remarks | - +============================+====================================================================================================================================================================================================================================================================================================================================================================================================================+=================================================================================================================================+=======================================================================================================================================================================================================================================================================+ - | cpu-manager-policy | Specifies the CPU core binding configuration. For details, see :ref:`CPU Core Binding `. | none | The values can be modified during the node pool lifecycle. | - | | | | | - | | - **none**: disables pods from exclusively occupying CPUs. Select this value if you want a large pool of shareable CPU cores. | | | - | | - **static**: enables pods to exclusively occupy CPUs. Select this value if your workload is sensitive to latency in CPU cache and scheduling. | | | - +----------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ - | kube-api-qps | Query per second (QPS) to use while talking with kube-apiserver. | 100 | | - +----------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ - | kube-api-burst | Burst to use while talking with kube-apiserver. | 100 | | - +----------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ - | max-pods | Maximum number of pods managed by kubelet. | 40 | | - | | | | | - | | | 20 | | - +----------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ - | pod-pids-limit | PID limit in Kubernetes | -1 | | - +----------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ - | with-local-dns | Whether to use the local IP address as the ClusterDNS of the node. | false | | - +----------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ - | event-qps | QPS limit for event creation | 5 | | - +----------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ - | allowed-unsafe-sysctls | Insecure system configuration allowed. | [] | | - | | | | | - | | Starting from **v1.17.17**, CCE enables pod security policies for kube-apiserver. You need to add corresponding configurations to **allowedUnsafeSysctls** of a pod security policy to make the policy take effect. (This configuration is not required for clusters earlier than v1.17.17.) For details, see :ref:`Example of Enabling Unsafe Sysctls in Pod Security Policy `. | | | - +----------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ - | over-subscription-resource | Whether to enable node oversubscription. | true | ``-`` | - | | | | | - | | If this parameter is set to **true**, the node oversubscription feature is enabled. For details, see :ref:`Hybrid Deployment of Online and Offline Jobs `. | | | - +----------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ - | colocation | Whether to enable node hybrid deployment. | true | ``-`` | - | | | | | - | | If this parameter is set to **true**, the node hybrid deployment feature is enabled. For details, see :ref:`Hybrid Deployment of Online and Offline Jobs `. | | | - +----------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ - | kube-reserved-mem | Reserved node memory. | Depends on node specifications. For details, see :ref:`Formula for Calculating the Reserved Resources of a Node `. | The sum of kube-reserved-mem and system-reserved-mem is less than half of the memory. | - | | | | | - | system-reserved-mem | | | | - +----------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ - | topology-manager-policy | Set the topology management policy. | none | The values can be modified during the node pool lifecycle. | - | | | | | - | | Valid values are as follows: | | .. important:: | - | | | | | - | | - **restricted**: kubelet accepts only pods that achieve optimal NUMA alignment on the requested resources. | | NOTICE: | - | | - **best-effort**: kubelet preferentially selects pods that implement NUMA alignment on CPU and device resources. | | Exercise caution when modifying topology-manager-policy and topology-manager-scope will restart kubelet and recalculate the resource allocation of pods based on the modified policy. As a result, running pods may restart or even fail to receive any resources. | - | | - **none** (default): The topology management policy is disabled. | | | - | | - **single-numa-node**: kubelet allows only pods that are aligned to the same NUMA node in terms of CPU and device resources. | | | - +----------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ - | topology-manager-scope | Set the resource alignment granularity of the topology management policy. Valid values are as follows: | container | | - | | | | | - | | - **container** (default) | | | - | | - **pod** | | | - +----------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ - | resolv-conf | DNS resolution configuration file specified by the container | The default value is null. | ``-`` | - +----------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ - - .. table:: **Table 2** kube-proxy - - +----------------------------------+-------------------------------------------------------------+---------------+------------------------------------------------------------+ - | Parameter | Description | Default Value | Remarks | - +==================================+=============================================================+===============+============================================================+ - | conntrack-min | sysctl -w net.nf_conntrack_max | 131072 | The values can be modified during the node pool lifecycle. | - +----------------------------------+-------------------------------------------------------------+---------------+------------------------------------------------------------+ - | conntrack-tcp-timeout-close-wait | sysctl -w net.netfilter.nf_conntrack_tcp_timeout_close_wait | 1h0m0s | | - +----------------------------------+-------------------------------------------------------------+---------------+------------------------------------------------------------+ - - .. table:: **Table 3** Network components (available only for CCE Turbo clusters) - - +---------------------------+------------------------------------------------------------------------------------------------------+-----------------+-----------------+ - | Parameter | Description | Default Value | Remarks | - +===========================+======================================================================================================+=================+=================+ - | nic-threshold | Low threshold of the number of bound ENIs:High threshold of the number of bound ENIs | Default: 0:0 | ``-`` | - | | | | | - | | .. note:: | | | - | | | | | - | | This parameter is being discarded. Use the dynamic pre-binding parameters of the other four ENIs. | | | - +---------------------------+------------------------------------------------------------------------------------------------------+-----------------+-----------------+ - | nic-minimum-target | Minimum number of ENIs bound to the nodes in the node pool | Default: 10 | ``-`` | - +---------------------------+------------------------------------------------------------------------------------------------------+-----------------+-----------------+ - | nic-maximum-target | Maximum number of ENIs pre-bound to a node at the node pool level | Default: 0 | ``-`` | - +---------------------------+------------------------------------------------------------------------------------------------------+-----------------+-----------------+ - | nic-warm-target | Number of ENIs pre-bound to a node at the node pool level | Default: 2 | ``-`` | - +---------------------------+------------------------------------------------------------------------------------------------------+-----------------+-----------------+ - | nic-max-above-warm-target | Reclaim number of ENIs pre-bound to a node at the node pool level | Default: 2 | ``-`` | - +---------------------------+------------------------------------------------------------------------------------------------------+-----------------+-----------------+ - - .. table:: **Table 4** Pod security group in a node pool (available only for CCE Turbo clusters) - - +------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-----------------+-----------------+ - | Parameter | Description | Default Value | Remarks | - +==============================+=====================================================================================================================================================================================================================================================================================================+=================+=================+ - | security_groups_for_nodepool | - Default security group used by pods in a node pool. You can enter the security group ID. If this parameter is not set, the default security group of the cluster container network is used. A maximum of five security group IDs can be specified at the same time, separated by semicolons (;). | ``-`` | ``-`` | - | | - The priority of the security group is lower than that of the security group configured for the :ref:`SecurityGroup ` resource object. | | | - +------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-----------------+-----------------+ - - .. table:: **Table 5** Docker (available only for node pools that use Docker) - - +-----------------------+---------------------------------------------------------------+-----------------+--------------------------------------------------------------------------------------------------------+ - | Parameter | Description | Default Value | Remarks | - +=======================+===============================================================+=================+========================================================================================================+ - | native-umask | \`--exec-opt native.umask | normal | Cannot be changed. | - +-----------------------+---------------------------------------------------------------+-----------------+--------------------------------------------------------------------------------------------------------+ - | docker-base-size | \`--storage-opts dm.basesize | 0 | Cannot be changed. | - +-----------------------+---------------------------------------------------------------+-----------------+--------------------------------------------------------------------------------------------------------+ - | insecure-registry | Address of an insecure image registry | false | Cannot be changed. | - +-----------------------+---------------------------------------------------------------+-----------------+--------------------------------------------------------------------------------------------------------+ - | limitcore | Maximum size of a core file in a container. The unit is byte. | 5368709120 | ``-`` | - +-----------------------+---------------------------------------------------------------+-----------------+--------------------------------------------------------------------------------------------------------+ - | default-ulimit-nofile | Limit on the number of handles in a container | {soft}:{hard} | The value cannot exceed the value of the kernel parameter **nr_open** and cannot be a negative number. | - | | | | | - | | | | You can run the following command to obtain the kernel parameter **nr_open**: | - | | | | | - | | | | .. code-block:: | - | | | | | - | | | | sysctl -a | grep nr_open | - +-----------------------+---------------------------------------------------------------+-----------------+--------------------------------------------------------------------------------------------------------+ - -#. Click **OK**. - -Editing a Node Pool -------------------- - -#. Log in to the CCE console. - -#. Click the cluster name and access the cluster console. Choose **Nodes** in the navigation pane and click the **Node Pools** tab on the right. - -#. Click **Edit** next to the name of the node pool you will edit. In the **Edit Node Pool** page, edit the following parameters: - - **Basic Settings** - - .. table:: **Table 6** Basic settings - - +-----------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ - | Parameter | Description | - +===================================+=================================================================================================================================================================================================================================================================================================================================================================================================================================================+ - | Node Pool Name | Name of the node pool. | - +-----------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ - | Auto Scaling | By default, this parameter is disabled. | - | | | - | | After you enable autoscaler by clicking |image1|, nodes in the node pool are automatically created or deleted based on service requirements. | - | | | - | | - **Maximum Nodes** and **Minimum Nodes**: You can set the maximum and minimum number of nodes to ensure that the number of nodes to be scaled is within a proper range. | - | | - **Priority**: A larger value indicates a higher priority. For example, if this parameter is set to **1** and **4** respectively for node pools A and B, B has a higher priority than A, and auto scaling is first triggered for B. If the priorities of multiple node pools are set to the same value, for example, **2**, the node pools are not prioritized and the system performs scaling based on the minimum resource waste principle. | - | | - **Cooldown Period**: Required. The unit is minute. This parameter indicates the interval between the previous scale-out action and the next scale-in action. | - | | | - | | If the **Autoscaler** field is set to on, install the :ref:`autoscaler add-on ` to use the autoscaler feature. | - +-----------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ - - **Advanced Settings** - - .. table:: **Table 7** Advanced settings - - +-----------------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ - | Parameter | Description | - +===================================+================================================================================================================================================================================================================================================================+ - | K8s label | Click **Add Label** to set the key-value pair attached to the Kubernetes objects (such as pods). A maximum of 20 labels can be added. | - | | | - | | Labels can be used to distinguish nodes. With workload affinity settings, container pods can be scheduled to a specified node. For more information, see `Labels and Selectors `__. | - | | | - | | .. note:: | - | | | - | | After a **K8s label** is modified, the inventory nodes in the node pool are updated synchronously. | - +-----------------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ - | Resource Tag | You can add resource tags to classify resources. | - | | | - | | You can create **predefined tags** in Tag Management Service (TMS). Predefined tags are visible to all service resources that support the tagging function. You can use these tags to improve tagging and resource migration efficiency. | - | | | - | | CCE will automatically create the "CCE-Dynamic-Provisioning-Node=\ *node id*" tag. | - | | | - | | .. note:: | - | | | - | | After a **resource tag** is modified, the modification automatically takes effect when a node is added. For existing nodes, you need to manually reset the nodes for the modification to take effect. | - +-----------------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ - | Taint | This field is left blank by default. You can add taints to set anti-affinity for the node. A maximum of 10 taints are allowed for each node. Each taint contains the following parameters: | - | | | - | | - **Key**: A key must contain 1 to 63 characters starting with a letter or digit. Only letters, digits, hyphens (-), underscores (_), and periods (.) are allowed. A DNS subdomain name can be used as the prefix of a key. | - | | - **Value**: A value must start with a letter or digit and can contain a maximum of 63 characters, including letters, digits, hyphens (-), underscores (_), and periods (.). | - | | - **Effect**: Available options are **NoSchedule**, **PreferNoSchedule**, and **NoExecute**. | - | | | - | | For details, see :ref:`Managing Node Taints `. | - | | | - | | .. note:: | - | | | - | | After a **taint** is modified, the inventory nodes in the node pool are updated synchronously. | - +-----------------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ - | Edit Key pair | Only node pools that use key pairs for login support key pair editing. You can select another key pair. | - | | | - | | .. note:: | - | | | - | | The edited key pair automatically takes effect when a node is added. For existing nodes, you need to manually reset the nodes for the key pair to take effect. | - +-----------------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ - -#. Click **OK**. - - In the node pool list, the node pool status becomes **Scaling**. After the status changes to **Completed**, the node pool parameters are modified successfully. The modified configuration will be synchronized to all nodes in the node pool. - -Deleting a Node Pool --------------------- - -Deleting a node pool will delete nodes in the pool. Pods on these nodes will be automatically migrated to available nodes in other node pools. If pods in the node pool have a specific node selector and none of the other nodes in the cluster satisfies the node selector, the pods will become unschedulable. - -#. Log in to the CCE console. -#. Click the cluster name and access the cluster console. Choose **Nodes** in the navigation pane and click the **Node Pools** tab on the right. -#. Choose **More > Delete** next to a node pool name to delete the node pool. -#. Read the precautions in the **Delete Node Pool** dialog box. -#. In the text box, click **Yes** to confirm that you want to continue the deletion. - -.. _cce_10_0222__section550619571556: - -Copying a Node Pool -------------------- - -You can copy the configuration of an existing node pool to create a new node pool on the CCE console. - -#. Log in to the CCE console. -#. Click the cluster name and access the cluster console. Choose **Nodes** in the navigation pane and click the **Node Pools** tab on the right. -#. Choose **More > Copy** next to a node pool name to copy the node pool. -#. The configurations of the selected node pool are replicated to the **Clone Node Pool** page. You can edit the configurations as required and click **Next: Confirm**. -#. On the **Confirm** page, confirm the node pool configuration and click **Create Now**. Then, a new node pool is created based on the edited configuration. - -Migrating a Node ----------------- - -Nodes in a node pool can be migrated. Currently, nodes in a node pool can be migrated only to the default node pool (defaultpool) in the same cluster. - -#. Log in to the CCE console and click the cluster name to access the cluster. - -#. In the navigation pane, choose **Nodes** and switch to the **Node Pools** tab page. - -#. Click **View Node** in the **Operation** column of the node pool to be migrated. - -#. Select the nodes to be migrated and choose **More** > **Migrate** to migrate the nodes to the default node pool in batches. - - You can also choose **More** > **Migrate** in the **Operation** column of a single node to migrate the node. - -#. In the displayed **Migrate Node** window, confirm the information. - - .. note:: - - The migration has no impacts on the original resource tags, Kubernetes labels, and taints of the node. - -.. |image1| image:: /_static/images/en-us_image_0000001528627005.png ++--------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ +| Major Version Upgrade Path | Precaution | Self-Check | ++======================================+==============================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================+=============================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================+ +| Upgrade from v1.19 to v1.21 or v1.23 | The bug of **exec probe timeouts** is fixed in Kubernetes 1.21. Before this bug fix, the exec probe does not consider the **timeoutSeconds** field. Instead, the probe will run indefinitely, even beyond its configured deadline. It will stop until the result is returned. If this field is not specified, the default value **1** is used. This field takes effect after the upgrade. If the probe runs over 1 second, the application health check may fail and the application may restart frequently. | Before the upgrade, check whether the timeout is properly set for the exec probe. | ++--------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ +| | kube-apiserver of CCE 1.19 or later requires that the Subject Alternative Names (SANs) field be configured for the certificate of your webhook server. Otherwise, kube-apiserver fails to call the webhook server after the upgrade, and containers cannot be started properly. | Before the upgrade, check whether the SAN field is configured in the certificate of your webhook server. | +| | | | +| | Root cause: X.509 `CommonName `__ is discarded in Go 1.15. kube-apiserver of CCE 1.19 is compiled using Go 1.15. If your webhook certificate does not have SANs, kube-apiserver does not process the **CommonName** field of the X.509 certificate as the host name by default. As a result, the authentication fails. | - If you do not have your own webhook server, you can skip this check. | +| | | - If the field is not set, you are advised to use the SAN field to specify the IP address and domain name supported by the certificate. | ++--------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ +| | Arm nodes are not supported in clusters of v1.21 and later. | Check whether your services will be affected if Arm nodes cannot be used. | ++--------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ +| Upgrade from v1.15 to v1.19 | The control plane of in the clusters v1.19 is incompatible with kubelet v1.15. If a node fails to be upgraded or the node to be upgraded restarts after the master node is successfully upgraded, there is a high probability that the node is in the **NotReady** status. | #. In normal cases, this scenario is not triggered. | +| | | #. After the master node is upgraded, do not suspend the upgrade so the node can be quickly upgraded. | +| | This is because the node failed to be upgraded restarts the kubelet and trigger the node registration. In clusters of v1.15, the default registration tags (**failure-domain.beta.kubernetes.io/is-baremetal** and **kubernetes.io/availablezone**) are regarded as invalid tags by the clusters of v1.19. | #. If a node fails to be upgraded and cannot be restored, evict applications on the node as soon as possible. Contact technical support and skip the node upgrade. After the upgrade is complete, reset the node. | +| | | | +| | The valid tags in the clusters of v1.19 are **node.kubernetes.io/baremetal** and **failure-domain.beta.kubernetes.io/zone**. | | ++--------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ +| | In CCE 1.15 and 1.19 clusters, the Docker storage driver file system is switched from XFS to Ext4. As a result, the import package sequence in the pods of the upgraded Java application may be abnormal, causing pod exceptions. | Before the upgrade, check the Docker configuration file **/etc/docker/daemon.json** on the node. Check whether the value of **dm.fs** is **xfs**. | +| | | | +| | | - If the value is **ext4** or the storage driver is Overlay, you can skip the next steps. | +| | | - If the value is **xfs**, you are advised to deploy applications in the cluster of the new version in advance to test whether the applications are compatible with the new cluster version. | +| | | | +| | | .. code-block:: | +| | | | +| | | { | +| | | "storage-driver": "devicemapper", | +| | | "storage-opts": [ | +| | | "dm.thinpooldev=/dev/mapper/vgpaas-thinpool", | +| | | "dm.use_deferred_removal=true", | +| | | "dm.fs=xfs", | +| | | "dm.use_deferred_deletion=true" | +| | | ] | +| | | } | ++--------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ +| | kube-apiserver of CCE 1.19 or later requires that the Subject Alternative Names (SANs) field be configured for the certificate of your webhook server. Otherwise, kube-apiserver fails to call the webhook server after the upgrade, and containers cannot be started properly. | Before the upgrade, check whether the SAN field is configured in the certificate of your webhook server. | +| | | | +| | Root cause: X.509 `CommonName `__ is discarded in Go 1.15. kube-apiserver of CCE 1.19 is compiled using Go 1.15. The **CommonName** field is processed as the host name. As a result, the authentication fails. | - If you do not have your own webhook server, you can skip this check. | +| | | - If the field is not set, you are advised to use the SAN field to specify the IP address and domain name supported by the certificate. | +| | | | +| | | .. important:: | +| | | | +| | | NOTICE: | +| | | To mitigate the impact of version differences on cluster upgrade, CCE performs special processing during the upgrade from 1.15 to 1.19 and still supports certificates without SANs. However, no special processing is required for subsequent upgrades. You are advised to rectify your certificate as soon as possible. | ++--------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ +| | In clusters of v1.17.17 and later, CCE automatically creates pod security policies (PSPs) for you, which restrict the creation of pods with unsafe configurations, for example, pods for which **net.core.somaxconn** under a sysctl is configured in the security context. | After an upgrade, you can allow insecure system configurations as required. For details, see :ref:`Configuring a Pod Security Policy `. | ++--------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ +| Upgrade from v1.13 to v1.15 | After a VPC network cluster is upgraded, the master node occupies an extra CIDR block due to the upgrade of network components. If no container CIDR block is available for the new node, the pod scheduled to the node cannot run. | This problem occurs when almost all CIDR blocks are occupied. For example, the container CIDR block is 10.0.0.0/16, the number of available IP addresses is 65,536, and the VPC network is allocated a CIDR block with the fixed size (using the mask to determine the maximum number of container IP addresses allocated to each node). If the upper limit is 128, the cluster supports a maximum of 512 (65536/128) nodes, including the three master nodes. After the cluster is upgraded, each of the three master nodes occupies one CIDR block. As a result, 506 nodes are supported. | ++--------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ diff --git a/umn/source/clusters/upgrading_a_cluster/troubleshooting_for_pre-upgrade_check_exceptions/containerd.sock_check.rst b/umn/source/clusters/upgrading_a_cluster/troubleshooting_for_pre-upgrade_check_exceptions/containerd.sock_check.rst new file mode 100644 index 0000000..b536554 --- /dev/null +++ b/umn/source/clusters/upgrading_a_cluster/troubleshooting_for_pre-upgrade_check_exceptions/containerd.sock_check.rst @@ -0,0 +1,21 @@ +:original_name: cce_10_0457.html + +.. _cce_10_0457: + +containerd.sock Check +===================== + +Check Item +---------- + +Check whether the containerd.sock file exists on the node. This file affects the startup of container runtime in the Euler OS. + +Solution +-------- + +**Scenario: The Docker used by the node is the customized Euler-docker.** + +#. Log in to the node. +#. Run the **rpm -qa \| grep docker \| grep euleros** command. If the command output is not empty, the Docker used on the node is Euler-docker. +#. Run the **ls /run/containerd/containerd.sock** command. If the file exists, Docker fails to be started. +#. Run the **rm -rf /run/containerd/containerd.sock** command and perform the cluster upgrade check again. diff --git a/umn/source/clusters/upgrading_a_cluster/troubleshooting_for_pre-upgrade_check_exceptions/controller_node_components_health.rst b/umn/source/clusters/upgrading_a_cluster/troubleshooting_for_pre-upgrade_check_exceptions/controller_node_components_health.rst new file mode 100644 index 0000000..16d08fc --- /dev/null +++ b/umn/source/clusters/upgrading_a_cluster/troubleshooting_for_pre-upgrade_check_exceptions/controller_node_components_health.rst @@ -0,0 +1,16 @@ +:original_name: cce_10_0485.html + +.. _cce_10_0485: + +Controller Node Components Health +================================= + +Check Item +---------- + +Check whether the Kubernetes, container runtime, and network components of the controller node are healthy. + +Solution +-------- + +If a component on the controller node is abnormal, contact technical support. diff --git a/umn/source/clusters/upgrading_a_cluster/troubleshooting_for_pre-upgrade_check_exceptions/crd_check.rst b/umn/source/clusters/upgrading_a_cluster/troubleshooting_for_pre-upgrade_check_exceptions/crd_check.rst new file mode 100644 index 0000000..1740da7 --- /dev/null +++ b/umn/source/clusters/upgrading_a_cluster/troubleshooting_for_pre-upgrade_check_exceptions/crd_check.rst @@ -0,0 +1,19 @@ +:original_name: cce_10_0444.html + +.. _cce_10_0444: + +CRD Check +========= + +Check Item +---------- + +Check the following aspects: + +- Check whether the key CRD **packageversions.version.cce.io** of the cluster is deleted. +- Check whether the cluster key CRD **network-attachment-definitions.k8s.cni.cncf.io** is deleted. + +Solution +-------- + +If check results are abnormal, contact technical support. diff --git a/umn/source/clusters/upgrading_a_cluster/troubleshooting_for_pre-upgrade_check_exceptions/discarded_kubernetes_resource.rst b/umn/source/clusters/upgrading_a_cluster/troubleshooting_for_pre-upgrade_check_exceptions/discarded_kubernetes_resource.rst new file mode 100644 index 0000000..ea69a7d --- /dev/null +++ b/umn/source/clusters/upgrading_a_cluster/troubleshooting_for_pre-upgrade_check_exceptions/discarded_kubernetes_resource.rst @@ -0,0 +1,35 @@ +:original_name: cce_10_0440.html + +.. _cce_10_0440: + +Discarded Kubernetes Resource +============================= + +Check Item +---------- + +Check whether there are discarded resources in the clusters. + +Solution +-------- + +**Scenario 1: The PodSecurityPolicy resource object has been discarded since clusters of v1.25.** + +|image1| + +Run the **kubectl get psp -A** command in the cluster to obtain the existing PSP object. + +If these two objects are not used, skip the check. Otherwise, upgrade the corresponding functions to PodSecurity by referring to :ref:`Pod Security `. + +**Scenario 2: The discarded annotation (tolerate-unready-endpoints) exists in Services in clusters of 1.25 or later.** + +|image2| + +Check whether the Service in the log information contains the annotation **tolerate-unready-endpoints**. If yes, delete the annotation and add the following field to the spec of the corresponding Service to replace the annotation: + +.. code-block:: + + publishNotReadyAddresses: true + +.. |image1| image:: /_static/images/en-us_image_0000001569022901.png +.. |image2| image:: /_static/images/en-us_image_0000001517903056.png diff --git a/umn/source/clusters/upgrading_a_cluster/troubleshooting_for_pre-upgrade_check_exceptions/enhanced_cpu_management_policy.rst b/umn/source/clusters/upgrading_a_cluster/troubleshooting_for_pre-upgrade_check_exceptions/enhanced_cpu_management_policy.rst new file mode 100644 index 0000000..fa08db3 --- /dev/null +++ b/umn/source/clusters/upgrading_a_cluster/troubleshooting_for_pre-upgrade_check_exceptions/enhanced_cpu_management_policy.rst @@ -0,0 +1,29 @@ +:original_name: cce_10_0480.html + +.. _cce_10_0480: + +Enhanced CPU Management Policy +============================== + +Check Item +---------- + +Check whether the current cluster version and the target version support enhanced CPU policy. + +Solution +-------- + +**Scenario**: The current cluster version uses the enhanced CPU management policy, but the target cluster version does not support the enhanced CPU management policy. + +Upgrade the cluster to a version that supports the enhanced CPU management policy. The following table lists the cluster versions that support the enhanced CPU management policy. + +.. table:: **Table 1** Cluster versions that support the enhanced CPU policy + + ================ ============================= + Cluster Version Enhanced CPU Policy Supported + ================ ============================= + v1.17 or earlier No + v1.19 No + v1.21 No + v1.23 or later Yes + ================ ============================= diff --git a/umn/source/clusters/upgrading_a_cluster/troubleshooting_for_pre-upgrade_check_exceptions/everest_restriction_check.rst b/umn/source/clusters/upgrading_a_cluster/troubleshooting_for_pre-upgrade_check_exceptions/everest_restriction_check.rst new file mode 100644 index 0000000..c5f52d6 --- /dev/null +++ b/umn/source/clusters/upgrading_a_cluster/troubleshooting_for_pre-upgrade_check_exceptions/everest_restriction_check.rst @@ -0,0 +1,28 @@ +:original_name: cce_10_0478.html + +.. _cce_10_0478: + +everest Restriction Check +========================= + +Check Item +---------- + +Check whether the current everest add-on has compatibility restrictions. See :ref:`Table 1 `. + +.. _cce_10_0478__table1126154011128: + +.. table:: **Table 1** List of everest add-on versions that have compatibility restrictions + + +-----------------------------------+-----------------------------------+ + | Add-on Name | Versions Involved | + +===================================+===================================+ + | everest | v1.0.2-v1.0.7 | + | | | + | | v1.1.1-v1.1.5 | + +-----------------------------------+-----------------------------------+ + +Solution +-------- + +The current everest add-on has compatibility restrictions and cannot be upgraded with the cluster upgrade. Contact technical support. diff --git a/umn/source/clusters/upgrading_a_cluster/troubleshooting_for_pre-upgrade_check_exceptions/index.rst b/umn/source/clusters/upgrading_a_cluster/troubleshooting_for_pre-upgrade_check_exceptions/index.rst new file mode 100644 index 0000000..71bf744 --- /dev/null +++ b/umn/source/clusters/upgrading_a_cluster/troubleshooting_for_pre-upgrade_check_exceptions/index.rst @@ -0,0 +1,96 @@ +:original_name: cce_10_0550.html + +.. _cce_10_0550: + +Troubleshooting for Pre-upgrade Check Exceptions +================================================ + +- :ref:`Performing Pre-upgrade Check ` +- :ref:`Checking the Node ` +- :ref:`Checking the Blocklist ` +- :ref:`Checking the Add-on ` +- :ref:`Checking the Helm Chart ` +- :ref:`Checking the Master Node SSH Connectivity ` +- :ref:`Checking the Node Pool ` +- :ref:`Checking the Security Group ` +- :ref:`To-Be-Migrated Node ` +- :ref:`Discarded Kubernetes Resource ` +- :ref:`Compatibility Risk ` +- :ref:`Node CCEAgent Version ` +- :ref:`Node CPU Usage ` +- :ref:`CRD Check ` +- :ref:`Node Disk ` +- :ref:`Node DNS ` +- :ref:`Node Key Directory File Permissions ` +- :ref:`Kubelet ` +- :ref:`Node Memory ` +- :ref:`Node Clock Synchronization Server ` +- :ref:`Node OS ` +- :ref:`Node CPU Count ` +- :ref:`Node Python Command ` +- :ref:`Node Readiness ` +- :ref:`Node journald ` +- :ref:`containerd.sock Check ` +- :ref:`Internal Error ` +- :ref:`Node Mount Point ` +- :ref:`Kubernetes Node Taint ` +- :ref:`everest Restriction Check ` +- :ref:`cce-hpa-controller Restriction Check ` +- :ref:`Enhanced CPU Management Policy ` +- :ref:`User Node Components Health ` +- :ref:`Controller Node Components Health ` +- :ref:`Memory Resource Limit of Kubernetes Components ` +- :ref:`Checking Deprecated Kubernetes APIs ` +- :ref:`IPv6 Capability of a CCE Turbo Cluster ` +- :ref:`Node NetworkManager ` +- :ref:`Node ID File ` +- :ref:`Node Configuration Consistency ` +- :ref:`Node Configuration File ` +- :ref:`Checking CoreDNS Configuration Consistency ` + +.. toctree:: + :maxdepth: 1 + :hidden: + + performing_pre-upgrade_check + checking_the_node + checking_the_blocklist + checking_the_add-on + checking_the_helm_chart + checking_the_master_node_ssh_connectivity + checking_the_node_pool + checking_the_security_group + to-be-migrated_node + discarded_kubernetes_resource + compatibility_risk + node_cceagent_version + node_cpu_usage + crd_check + node_disk + node_dns + node_key_directory_file_permissions + kubelet + node_memory + node_clock_synchronization_server + node_os + node_cpu_count + node_python_command + node_readiness + node_journald + containerd.sock_check + internal_error + node_mount_point + kubernetes_node_taint + everest_restriction_check + cce-hpa-controller_restriction_check + enhanced_cpu_management_policy + user_node_components_health + controller_node_components_health + memory_resource_limit_of_kubernetes_components + checking_deprecated_kubernetes_apis + ipv6_capability_of_a_cce_turbo_cluster + node_networkmanager + node_id_file + node_configuration_consistency + node_configuration_file + checking_coredns_configuration_consistency diff --git a/umn/source/clusters/upgrading_a_cluster/troubleshooting_for_pre-upgrade_check_exceptions/internal_error.rst b/umn/source/clusters/upgrading_a_cluster/troubleshooting_for_pre-upgrade_check_exceptions/internal_error.rst new file mode 100644 index 0000000..a8ae92d --- /dev/null +++ b/umn/source/clusters/upgrading_a_cluster/troubleshooting_for_pre-upgrade_check_exceptions/internal_error.rst @@ -0,0 +1,16 @@ +:original_name: cce_10_0458.html + +.. _cce_10_0458: + +Internal Error +============== + +Check Item +---------- + +Before the upgrade, check whether an internal error occurs. + +Solution +-------- + +If this check fails, contact technical support. diff --git a/umn/source/clusters/upgrading_a_cluster/troubleshooting_for_pre-upgrade_check_exceptions/ipv6_capability_of_a_cce_turbo_cluster.rst b/umn/source/clusters/upgrading_a_cluster/troubleshooting_for_pre-upgrade_check_exceptions/ipv6_capability_of_a_cce_turbo_cluster.rst new file mode 100644 index 0000000..cff094f --- /dev/null +++ b/umn/source/clusters/upgrading_a_cluster/troubleshooting_for_pre-upgrade_check_exceptions/ipv6_capability_of_a_cce_turbo_cluster.rst @@ -0,0 +1,22 @@ +:original_name: cce_10_0488.html + +.. _cce_10_0488: + +IPv6 Capability of a CCE Turbo Cluster +====================================== + +Check Item +---------- + +If IPv6 is enabled for a CCE Turbo cluster, check whether the target cluster version supports IPv6. + +Solution +-------- + +CCE Turbo clusters support IPv6 since v1.23. This feature is available in the following versions: + +- v1.23: 1.23.8-r0 or later +- v1.25: 1.25.3-r0 or later +- v1.25 or later + +If IPv6 has been enabled in the cluster before the upgrade, the target cluster version must also support IPv6. Select a proper cluster version. diff --git a/umn/source/clusters/upgrading_a_cluster/troubleshooting_for_pre-upgrade_check_exceptions/kubelet.rst b/umn/source/clusters/upgrading_a_cluster/troubleshooting_for_pre-upgrade_check_exceptions/kubelet.rst new file mode 100644 index 0000000..9c69cd3 --- /dev/null +++ b/umn/source/clusters/upgrading_a_cluster/troubleshooting_for_pre-upgrade_check_exceptions/kubelet.rst @@ -0,0 +1,22 @@ +:original_name: cce_10_0448.html + +.. _cce_10_0448: + +Kubelet +======= + +Check Item +---------- + +Check whether the kubelet on the node is running properly. + +Solution +-------- + +- **Scenario 1: The kubelet status is abnormal.** + + If the kubelet is abnormal, the node is unavailable. Restore the node by following the instructions provided in and check again. + +- **Scenario 2: The cce-pause version is abnormal.** + + The version of the pause container image on which kubelet depends is not cce-pause:3.1. If you continue the upgrade, pods will restart in batches. Currently, the upgrade is not supported. Contact technical support. diff --git a/umn/source/clusters/upgrading_a_cluster/troubleshooting_for_pre-upgrade_check_exceptions/kubernetes_node_taint.rst b/umn/source/clusters/upgrading_a_cluster/troubleshooting_for_pre-upgrade_check_exceptions/kubernetes_node_taint.rst new file mode 100644 index 0000000..eeb035e --- /dev/null +++ b/umn/source/clusters/upgrading_a_cluster/troubleshooting_for_pre-upgrade_check_exceptions/kubernetes_node_taint.rst @@ -0,0 +1,40 @@ +:original_name: cce_10_0460.html + +.. _cce_10_0460: + +Kubernetes Node Taint +===================== + +Check Item +---------- + +Check whether the taint, as shown in :ref:`Table 1 `, exists on the node. + +.. _cce_10_0460__table1126154011128: + +.. table:: **Table 1** Taint checklist + + ========================== ========== + Name Impact + ========================== ========== + node.kubernetes.io/upgrade NoSchedule + ========================== ========== + +Solution +-------- + +Scenario 1: The node is skipped during the cluster upgrade. + +#. For details about how to configure kubectl, see :ref:`Connecting to a Cluster Using kubectl `. + +#. Check the kubelet version of the corresponding node. If the following information is expected: + + |image1| + + If the version of the node is different from that of other nodes, the node is skipped during the upgrade. Reset the node and upgrade the cluster again. For details about how to reset a node, see :ref:`Resetting a Node `. + + .. note:: + + Resetting a node will reset all node labels, which may affect workload scheduling. Before resetting a node, check and retain the labels that you have manually added to the node. + +.. |image1| image:: /_static/images/en-us_image_0000001568902601.png diff --git a/umn/source/clusters/upgrading_a_cluster/troubleshooting_for_pre-upgrade_check_exceptions/memory_resource_limit_of_kubernetes_components.rst b/umn/source/clusters/upgrading_a_cluster/troubleshooting_for_pre-upgrade_check_exceptions/memory_resource_limit_of_kubernetes_components.rst new file mode 100644 index 0000000..f9bd8ec --- /dev/null +++ b/umn/source/clusters/upgrading_a_cluster/troubleshooting_for_pre-upgrade_check_exceptions/memory_resource_limit_of_kubernetes_components.rst @@ -0,0 +1,22 @@ +:original_name: cce_10_0486.html + +.. _cce_10_0486: + +Memory Resource Limit of Kubernetes Components +============================================== + +Check Item +---------- + +Check whether the resources of Kubernetes components, such as etcd and kube-controller-manager, exceed the upper limit. + +Solution +-------- + +Solution 1: Reducing Kubernetes resources + +Solution 2: :ref:`Expanding cluster scale ` + +|image1| + +.. |image1| image:: /_static/images/en-us_image_0000001579008782.png diff --git a/umn/source/clusters/upgrading_a_cluster/troubleshooting_for_pre-upgrade_check_exceptions/node_cceagent_version.rst b/umn/source/clusters/upgrading_a_cluster/troubleshooting_for_pre-upgrade_check_exceptions/node_cceagent_version.rst new file mode 100644 index 0000000..42b59db --- /dev/null +++ b/umn/source/clusters/upgrading_a_cluster/troubleshooting_for_pre-upgrade_check_exceptions/node_cceagent_version.rst @@ -0,0 +1,56 @@ +:original_name: cce_10_0442.html + +.. _cce_10_0442: + +Node CCEAgent Version +===================== + +Check Item +---------- + +Check whether cce-agent on the current node is of the latest version. + +Solution +-------- + +If cce-agent is not of the latest version, the automatic update fails. This problem is usually caused by invalid OBS address or the version of the component is outdated. + +#. Log in to a normal node that passes the check, obtain the path of the cce-agent configuration file, and check the OBS address. + + .. code-block:: + + cat `ps aux | grep cce-agent | grep -v grep | awk -F '-f ''{print $2}'` + + The OBS configuration address field in the configuration file is **packageFrom.addr**. + + |image1| + +#. Log in to an abnormal node where the check fails, obtain the OBS address again by referring to the previous step, and check whether the OBS address is consistent. If they are different, change the OBS address of the abnormal node to the correct address. + +#. Run the following commands to download the latest binary file: + + - ARM + + .. code-block:: + + curl -k "https://{OBS address you have obtained}/cluster-versions/base/cce-agent-arm" > /tmp/cce-agent-arm + +#. Replace the original cce-agent binary file. + + - ARM + + .. code-block:: + + mv -f /tmp/cce-agent-arm /usr/local/bin/cce-agent-arm + chmod 750 /usr/local/bin/cce-agent-arm + chown root:root /usr/local/bin/cce-agent-arm + +#. Restart cce-agent. + + .. code-block:: + + systemctl restart cce-agent + + If you have any questions about the preceding operations, contact technical support. + +.. |image1| image:: /_static/images/en-us_image_0000001629186693.png diff --git a/umn/source/clusters/upgrading_a_cluster/troubleshooting_for_pre-upgrade_check_exceptions/node_clock_synchronization_server.rst b/umn/source/clusters/upgrading_a_cluster/troubleshooting_for_pre-upgrade_check_exceptions/node_clock_synchronization_server.rst new file mode 100644 index 0000000..7b229c5 --- /dev/null +++ b/umn/source/clusters/upgrading_a_cluster/troubleshooting_for_pre-upgrade_check_exceptions/node_clock_synchronization_server.rst @@ -0,0 +1,37 @@ +:original_name: cce_10_0450.html + +.. _cce_10_0450: + +Node Clock Synchronization Server +================================= + +Check Item +---------- + +Check whether the clock synchronization server ntpd or chronyd of the node is running properly. + +Solution +-------- + +- **Scenario 1: ntpd is running abnormally.** + + Log in to the node and run the **systemctl status ntpd** command to query the running status of ntpd. If the command output is abnormal, run the **systemctl restart ntpd** command and query the status again. + + The normal command output is as follows: + + |image1| + + If the problem persists after ntpd is restarted, contact technical support. + +- **Scenario 2: chronyd is running abnormally.** + + Log in to the node and run the **systemctl status chronyd** command to query the running status of chronyd. If the command output is abnormal, run the **systemctl restart chronyd** command and query the status again. + + The normal command output is as follows: + + |image2| + + If the problem persists after chronyd is restarted, contact technical support. + +.. |image1| image:: /_static/images/en-us_image_0000001568902509.png +.. |image2| image:: /_static/images/en-us_image_0000001518062624.png diff --git a/umn/source/clusters/upgrading_a_cluster/troubleshooting_for_pre-upgrade_check_exceptions/node_configuration_consistency.rst b/umn/source/clusters/upgrading_a_cluster/troubleshooting_for_pre-upgrade_check_exceptions/node_configuration_consistency.rst new file mode 100644 index 0000000..5955129 --- /dev/null +++ b/umn/source/clusters/upgrading_a_cluster/troubleshooting_for_pre-upgrade_check_exceptions/node_configuration_consistency.rst @@ -0,0 +1,60 @@ +:original_name: cce_10_0491.html + +.. _cce_10_0491: + +Node Configuration Consistency +============================== + +Check Item +---------- + +When you upgrade a CCE cluster to v1.19 or later, the system checks whether the following configuration files have been modified in the background: + +- /opt/cloud/cce/kubernetes/kubelet/kubelet +- /opt/cloud/cce/kubernetes/kubelet/kubelet_config.yaml +- /opt/cloud/cce/kubernetes/kube-proxy/kube-proxy +- /etc/containerd/default_runtime_spec.json +- /etc/sysconfig/docker +- /etc/default/docker +- /etc/docker/daemon.json + +If you modify some parameters in these files, the cluster upgrade may fail or services may be abnormal after the upgrade. If you confirm that the modification does not affect services, continue the upgrade. + +.. note:: + + CCE uses the standard image script to check node configuration consistency. If you use other custom images, the check may fail. + +The expected modification will not be intercepted. The following table lists the parameters that can be modified. + +.. table:: **Table 1** Parameters that can be modified + + +-----------+-------------------------------------------------------+-----------------------+------------------+ + | Component | Configuration File | Parameter | Upgrade Version | + +===========+=======================================================+=======================+==================+ + | kubelet | /opt/cloud/cce/kubernetes/kubelet/kubelet_config.yaml | cpuManagerPolicy | Later than v1.19 | + +-----------+-------------------------------------------------------+-----------------------+------------------+ + | kubelet | /opt/cloud/cce/kubernetes/kubelet/kubelet_config.yaml | maxPods | Later than v1.19 | + +-----------+-------------------------------------------------------+-----------------------+------------------+ + | kubelet | /opt/cloud/cce/kubernetes/kubelet/kubelet_config.yaml | kubeAPIQPS | Later than v1.19 | + +-----------+-------------------------------------------------------+-----------------------+------------------+ + | kubelet | /opt/cloud/cce/kubernetes/kubelet/kubelet_config.yaml | kubeAPIBurst | Later than v1.19 | + +-----------+-------------------------------------------------------+-----------------------+------------------+ + | kubelet | /opt/cloud/cce/kubernetes/kubelet/kubelet_config.yaml | podPidsLimit | Later than v1.19 | + +-----------+-------------------------------------------------------+-----------------------+------------------+ + | kubelet | /opt/cloud/cce/kubernetes/kubelet/kubelet_config.yaml | topologyManagerPolicy | Later than v1.19 | + +-----------+-------------------------------------------------------+-----------------------+------------------+ + | kubelet | /opt/cloud/cce/kubernetes/kubelet/kubelet_config.yaml | resolvConf | Later than v1.19 | + +-----------+-------------------------------------------------------+-----------------------+------------------+ + | kubelet | /opt/cloud/cce/kubernetes/kubelet/kubelet_config.yaml | eventRecordQPS | Later than v1.21 | + +-----------+-------------------------------------------------------+-----------------------+------------------+ + | kubelet | /opt/cloud/cce/kubernetes/kubelet/kubelet_config.yaml | topologyManagerScope | Later than v1.21 | + +-----------+-------------------------------------------------------+-----------------------+------------------+ + | kubelet | /opt/cloud/cce/kubernetes/kubelet/kubelet_config.yaml | allowedUnsafeSysctls | Later than v1.19 | + +-----------+-------------------------------------------------------+-----------------------+------------------+ + | Docker | /etc/docker/daemon.json | dm.basesize | Later than v1.19 | + +-----------+-------------------------------------------------------+-----------------------+------------------+ + +Solution +-------- + +If you modify some parameters in these files, exceptions may occur after the upgrade. If you are not sure whether the modified parameters will affect the upgrade, contact technical support. diff --git a/umn/source/clusters/upgrading_a_cluster/troubleshooting_for_pre-upgrade_check_exceptions/node_configuration_file.rst b/umn/source/clusters/upgrading_a_cluster/troubleshooting_for_pre-upgrade_check_exceptions/node_configuration_file.rst new file mode 100644 index 0000000..2c9be9b --- /dev/null +++ b/umn/source/clusters/upgrading_a_cluster/troubleshooting_for_pre-upgrade_check_exceptions/node_configuration_file.rst @@ -0,0 +1,32 @@ +:original_name: cce_10_0492.html + +.. _cce_10_0492: + +Node Configuration File +======================= + +Check Item +---------- + +Check whether the configuration files of key components exist on the node. + +The following table lists the files to be checked. + ++-------------------------------------------------------+--------------------------------------------+------------------------------------------------------------------+ +| File Name | File Content | Remarks | ++=======================================================+============================================+==================================================================+ +| /opt/cloud/cce/kubernetes/kubelet/kubelet | kubelet command line startup parameters | ``-`` | ++-------------------------------------------------------+--------------------------------------------+------------------------------------------------------------------+ +| /opt/cloud/cce/kubernetes/kubelet/kubelet_config.yaml | kubelet startup parameters | ``-`` | ++-------------------------------------------------------+--------------------------------------------+------------------------------------------------------------------+ +| /opt/cloud/cce/kubernetes/kube-proxy/kube-proxy | kube-proxy command line startup parameters | ``-`` | ++-------------------------------------------------------+--------------------------------------------+------------------------------------------------------------------+ +| /etc/sysconfig/docker | Docker configuration file | Not checked when containerd or the Debain-Group machine is used. | ++-------------------------------------------------------+--------------------------------------------+------------------------------------------------------------------+ +| /etc/default/docker | Docker configuration file | Not checked when containerd or the Centos-Group machine is used. | ++-------------------------------------------------------+--------------------------------------------+------------------------------------------------------------------+ + +Solution +-------- + +Contact technical support to restore the configuration file and then perform the upgrade. diff --git a/umn/source/clusters/upgrading_a_cluster/troubleshooting_for_pre-upgrade_check_exceptions/node_cpu_count.rst b/umn/source/clusters/upgrading_a_cluster/troubleshooting_for_pre-upgrade_check_exceptions/node_cpu_count.rst new file mode 100644 index 0000000..6b3bbb7 --- /dev/null +++ b/umn/source/clusters/upgrading_a_cluster/troubleshooting_for_pre-upgrade_check_exceptions/node_cpu_count.rst @@ -0,0 +1,16 @@ +:original_name: cce_10_0452.html + +.. _cce_10_0452: + +Node CPU Count +============== + +Check Item +---------- + +Check whether the number of CPUs on the master node is greater than 2. + +Solution +-------- + +If the number of CPUs on the master node is 2, contact technical support to expand the number to 4 or more. diff --git a/umn/source/clusters/upgrading_a_cluster/troubleshooting_for_pre-upgrade_check_exceptions/node_cpu_usage.rst b/umn/source/clusters/upgrading_a_cluster/troubleshooting_for_pre-upgrade_check_exceptions/node_cpu_usage.rst new file mode 100644 index 0000000..61e3d71 --- /dev/null +++ b/umn/source/clusters/upgrading_a_cluster/troubleshooting_for_pre-upgrade_check_exceptions/node_cpu_usage.rst @@ -0,0 +1,17 @@ +:original_name: cce_10_0443.html + +.. _cce_10_0443: + +Node CPU Usage +============== + +Check Item +---------- + +Check whether the CPU usage of the node exceeds 90%. + +Solution +-------- + +- **Upgrade the cluster during off-peak hours.** +- Check whether too many pods are deployed on the node. If yes, reschedule pods to other idle nodes. diff --git a/umn/source/clusters/upgrading_a_cluster/troubleshooting_for_pre-upgrade_check_exceptions/node_disk.rst b/umn/source/clusters/upgrading_a_cluster/troubleshooting_for_pre-upgrade_check_exceptions/node_disk.rst new file mode 100644 index 0000000..8630d9a --- /dev/null +++ b/umn/source/clusters/upgrading_a_cluster/troubleshooting_for_pre-upgrade_check_exceptions/node_disk.rst @@ -0,0 +1,55 @@ +:original_name: cce_10_0445.html + +.. _cce_10_0445: + +Node Disk +========= + +Check Item +---------- + +Check the following aspects: + +- Check whether the key data disks on the node meet the upgrade requirements. +- Check whether the **/tmp** directory has 500 MB available space. + +Solution +-------- + +During the node upgrade, the key disks store the upgrade component package, and the **/tmp** directory stores temporary files. + +- **Scenario 1: Check whether the disk meets the upgrade requirements.** + + Run the following command to check the usage of each key disk. After ensuring that the available space meets the requirements and check again. If the space of the master node is insufficient, contact technical support. + + - Disk partition of Docker: 2 GB for master nodes and 1 GB for worker nodes + + .. code-block:: + + df -h /var/lib/docker + + - Disk partition of containerd: 2 GB for master nodes and 1 GB for worker nodes + + .. code-block:: + + df -h /var/lib/containerd + + - Disk partition of kubelet: 2 GB for master nodes and 1 GB for worker nodes + + .. code-block:: + + df -h /var/lib/docker + + - System disk: 10 GB for master nodes and 2 GB for worker nodes + + .. code-block:: + + df -h / + +- **Scenario 2: The /tmp directory space is insufficient.** + + Run the following command to check the space usage of the file system where the /tmp directory is located. Ensure that the space is greater than 500 MB and check again. + + .. code-block:: + + df -h /tmp diff --git a/umn/source/clusters/upgrading_a_cluster/troubleshooting_for_pre-upgrade_check_exceptions/node_dns.rst b/umn/source/clusters/upgrading_a_cluster/troubleshooting_for_pre-upgrade_check_exceptions/node_dns.rst new file mode 100644 index 0000000..69ab0fb --- /dev/null +++ b/umn/source/clusters/upgrading_a_cluster/troubleshooting_for_pre-upgrade_check_exceptions/node_dns.rst @@ -0,0 +1,19 @@ +:original_name: cce_10_0446.html + +.. _cce_10_0446: + +Node DNS +======== + +Check Item +---------- + +Check the following aspects: + +- Check whether the DNS configuration of the current node can resolve the OBS address. +- Check whether the current node can access the OBS address of the storage upgrade component package. + +Solution +-------- + +During the node upgrade, you need to obtain the upgrade component package from OBS. If this check fails, contact technical support. diff --git a/umn/source/clusters/upgrading_a_cluster/troubleshooting_for_pre-upgrade_check_exceptions/node_id_file.rst b/umn/source/clusters/upgrading_a_cluster/troubleshooting_for_pre-upgrade_check_exceptions/node_id_file.rst new file mode 100644 index 0000000..8649314 --- /dev/null +++ b/umn/source/clusters/upgrading_a_cluster/troubleshooting_for_pre-upgrade_check_exceptions/node_id_file.rst @@ -0,0 +1,39 @@ +:original_name: cce_10_0490.html + +.. _cce_10_0490: + +Node ID File +============ + +Check Item +---------- + +Check the ID file format. + +Solution +-------- + +#. On the **Nodes** page of the CCE console, click the name of the abnormal node to go to the ECS page. + + |image1| + +#. Copy the node ID and save it to the local host. + + |image2| + +#. Log in to the abnormal node and back up files. + + .. code-block:: + + cp /var/lib/cloud/data/instance-id /tmp/instance-id + cp /var/paas/conf/server.conf /tmp/server.conf + +#. Log in to the abnormal node and write the obtained node ID to the file. + + .. code-block:: + + echo "Node ID" >> /var/lib/cloud/data/instance-id + echo "Node ID" >> /var/paas/conf/server.conf + +.. |image1| image:: /_static/images/en-us_image_0000001504661902.png +.. |image2| image:: /_static/images/en-us_image_0000001504821802.png diff --git a/umn/source/clusters/upgrading_a_cluster/troubleshooting_for_pre-upgrade_check_exceptions/node_journald.rst b/umn/source/clusters/upgrading_a_cluster/troubleshooting_for_pre-upgrade_check_exceptions/node_journald.rst new file mode 100644 index 0000000..843a433 --- /dev/null +++ b/umn/source/clusters/upgrading_a_cluster/troubleshooting_for_pre-upgrade_check_exceptions/node_journald.rst @@ -0,0 +1,24 @@ +:original_name: cce_10_0456.html + +.. _cce_10_0456: + +Node journald +============= + +Check Item +---------- + +Check whether journald of a node is normal. + +Solution +-------- + +Log in to the node and run the **systemctl is-active systemd-journald** command to query the running status of journald. If the command output is abnormal, run the **systemctl restart systemd-journald** command and query the status again. + +The normal command output is as follows: + +|image1| + +If the problem persists after journald is restarted, contact technical support. + +.. |image1| image:: /_static/images/en-us_image_0000001517903128.png diff --git a/umn/source/clusters/upgrading_a_cluster/troubleshooting_for_pre-upgrade_check_exceptions/node_key_directory_file_permissions.rst b/umn/source/clusters/upgrading_a_cluster/troubleshooting_for_pre-upgrade_check_exceptions/node_key_directory_file_permissions.rst new file mode 100644 index 0000000..e862e80 --- /dev/null +++ b/umn/source/clusters/upgrading_a_cluster/troubleshooting_for_pre-upgrade_check_exceptions/node_key_directory_file_permissions.rst @@ -0,0 +1,20 @@ +:original_name: cce_10_0447.html + +.. _cce_10_0447: + +Node Key Directory File Permissions +=================================== + +Check Item +---------- + +Check whether the key directory **/var/paas** on the nodes contain files with abnormal owners or owner groups. + +Solution +-------- + +CCE uses the **/var/paas** directory to manage nodes and store file data whose owner and owner group are both paas. + +During the current cluster upgrade, the owner and owner group of the files in the **/var/paas** directory are reset to paas. + +Check whether file data is stored in the **/var/paas** directory. If yes, do not use this directory, remove abnormal files from this directory, and check again. Otherwise, the upgrade is prohibited. diff --git a/umn/source/clusters/upgrading_a_cluster/troubleshooting_for_pre-upgrade_check_exceptions/node_memory.rst b/umn/source/clusters/upgrading_a_cluster/troubleshooting_for_pre-upgrade_check_exceptions/node_memory.rst new file mode 100644 index 0000000..9411066 --- /dev/null +++ b/umn/source/clusters/upgrading_a_cluster/troubleshooting_for_pre-upgrade_check_exceptions/node_memory.rst @@ -0,0 +1,17 @@ +:original_name: cce_10_0449.html + +.. _cce_10_0449: + +Node Memory +=========== + +Check Item +---------- + +Check whether the memory usage of the node exceeds 90%. + +Solution +-------- + +- **Upgrade the cluster during off-peak hours.** +- Check whether too many pods are deployed on the node. If yes, reschedule pods to other idle nodes. diff --git a/umn/source/clusters/upgrading_a_cluster/troubleshooting_for_pre-upgrade_check_exceptions/node_mount_point.rst b/umn/source/clusters/upgrading_a_cluster/troubleshooting_for_pre-upgrade_check_exceptions/node_mount_point.rst new file mode 100644 index 0000000..f454540 --- /dev/null +++ b/umn/source/clusters/upgrading_a_cluster/troubleshooting_for_pre-upgrade_check_exceptions/node_mount_point.rst @@ -0,0 +1,41 @@ +:original_name: cce_10_0459.html + +.. _cce_10_0459: + +Node Mount Point +================ + +Check Item +---------- + +Check whether inaccessible mount points exist on the node. + +Solution +-------- + +**Scenario: There are inaccessible mount points on the node.** + +If network NFS (such as OBS, SFS, and SFS) is used by the node and the node is disconnected with the NFS server, the mount point would be inaccessible and all processes that access this mount point are suspended. + +#. Log in to the node. + +#. Run the following commands on the node in sequence: + + .. code-block:: + + - df -h + - for dir in `df -h | grep -v "Mounted on" | awk "{print \\$NF}"`;do cd $dir; done && echo "ok" + +#. If **ok** is returned, no problem occurs. + + Otherwise, start another terminal and run the following command to check whether the previous command is in the D state: + + .. code-block:: + + - ps aux | grep "D " + +#. If a process is in the D state, the problem occurs.You can only reset the node to solve the problem. Reset the node and upgrade the cluster again. For details about how to reset a node, see :ref:`Resetting a Node `. + + .. note:: + + Resetting a node will reset all node labels, which may affect workload scheduling. Before resetting a node, check and retain the labels that you have manually added to the node. diff --git a/umn/source/clusters/upgrading_a_cluster/troubleshooting_for_pre-upgrade_check_exceptions/node_networkmanager.rst b/umn/source/clusters/upgrading_a_cluster/troubleshooting_for_pre-upgrade_check_exceptions/node_networkmanager.rst new file mode 100644 index 0000000..310ae79 --- /dev/null +++ b/umn/source/clusters/upgrading_a_cluster/troubleshooting_for_pre-upgrade_check_exceptions/node_networkmanager.rst @@ -0,0 +1,18 @@ +:original_name: cce_10_0489.html + +.. _cce_10_0489: + +Node NetworkManager +=================== + +Check Item +---------- + +Check whether NetworkManager of a node is normal. + +Solution +-------- + +Log in to the node and run the **systemctl is-active NetworkManager** command to query the running status of NetworkManager. If the command output is abnormal, run the **systemctl restart NetworkManager** command and query the status again. + +If the problem persists after NetworkManager is restarted, contact technical support. diff --git a/umn/source/clusters/upgrading_a_cluster/troubleshooting_for_pre-upgrade_check_exceptions/node_os.rst b/umn/source/clusters/upgrading_a_cluster/troubleshooting_for_pre-upgrade_check_exceptions/node_os.rst new file mode 100644 index 0000000..70cdbad --- /dev/null +++ b/umn/source/clusters/upgrading_a_cluster/troubleshooting_for_pre-upgrade_check_exceptions/node_os.rst @@ -0,0 +1,18 @@ +:original_name: cce_10_0451.html + +.. _cce_10_0451: + +Node OS +======= + +Check Item +---------- + +Check whether the OS kernel version of the node is supported by CCE. + +Solution +-------- + +Running nodes depend on the initial standard kernel version when they are created. CCE has performed comprehensive compatibility tests based on this kernel version. A non-standard kernel version may cause unexpected compatibility issues during node upgrade and the node upgrade may fail. For details, see :ref:`High-Risk Operations and Solutions `. + +Currently, this type of nodes should not be upgraded. You are advised to reset the node to the standard kernel version before the upgrade by following the instructions in :ref:`Resetting a Node `. diff --git a/umn/source/clusters/upgrading_a_cluster/troubleshooting_for_pre-upgrade_check_exceptions/node_python_command.rst b/umn/source/clusters/upgrading_a_cluster/troubleshooting_for_pre-upgrade_check_exceptions/node_python_command.rst new file mode 100644 index 0000000..e2493dc --- /dev/null +++ b/umn/source/clusters/upgrading_a_cluster/troubleshooting_for_pre-upgrade_check_exceptions/node_python_command.rst @@ -0,0 +1,26 @@ +:original_name: cce_10_0453.html + +.. _cce_10_0453: + +Node Python Command +=================== + +Check Item +---------- + +Check whether the Python commands are available on a node. + +Check Method +------------ + +.. code-block:: + + /usr/bin/python --version + echo $? + +If the command output is not 0, the check fails. + +Solution +-------- + +Install Python before the upgrade. diff --git a/umn/source/clusters/upgrading_a_cluster/troubleshooting_for_pre-upgrade_check_exceptions/node_readiness.rst b/umn/source/clusters/upgrading_a_cluster/troubleshooting_for_pre-upgrade_check_exceptions/node_readiness.rst new file mode 100644 index 0000000..03e0274 --- /dev/null +++ b/umn/source/clusters/upgrading_a_cluster/troubleshooting_for_pre-upgrade_check_exceptions/node_readiness.rst @@ -0,0 +1,25 @@ +:original_name: cce_10_0455.html + +.. _cce_10_0455: + +Node Readiness +============== + +Check Item +---------- + +Check whether the nodes in the cluster are ready. + +Solution +-------- + +- **Scenario 1: The nodes are in the unavailable status.** + + Log in to the CCE console and access the cluster console. Choose **Nodes** in the navigation pane and filter out unavailable nodes, rectify the faulty nodes by referring to the suggestions provided by the console, and check again. + +- **Scenario 2: The displayed node status is inconsistent with the actual status.** + + The possible causes are as follows: + + #. The node status is normal on the nodes page, but the check result shows that the node is not ready. Check again. + #. The node is not found on the nodes page, but the check result shows that the node is in the cluster. Contact technical support. diff --git a/umn/source/clusters/upgrading_a_cluster/troubleshooting_for_pre-upgrade_check_exceptions/performing_pre-upgrade_check.rst b/umn/source/clusters/upgrading_a_cluster/troubleshooting_for_pre-upgrade_check_exceptions/performing_pre-upgrade_check.rst new file mode 100644 index 0000000..e64d1fd --- /dev/null +++ b/umn/source/clusters/upgrading_a_cluster/troubleshooting_for_pre-upgrade_check_exceptions/performing_pre-upgrade_check.rst @@ -0,0 +1,104 @@ +:original_name: cce_10_0549.html + +.. _cce_10_0549: + +Performing Pre-upgrade Check +============================ + +The system performs a comprehensive pre-upgrade check before the cluster upgrade. If the cluster does not meet the pre-upgrade check conditions, the upgrade cannot continue. To prevent upgrade risks, you can perform pre-upgrade check according to the check items provided by this section. + +.. table:: **Table 1** Check items + + +---------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | Check Item | Description | + +=====================================================================+===========================================================================================================================================================================================================================+ + | :ref:`Checking the Node ` | - Check whether the node is available. | + | | - Check whether the node OS supports the upgrade. | + | | - Check whether there are unexpected node pool tags in the node. | + | | - Check whether the Kubernetes node name is consistent with the ECS name. | + +---------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | :ref:`Checking the Blocklist ` | Check whether the current user is in the upgrade blocklist. | + +---------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | :ref:`Checking the Add-on ` | - Check whether the add-on status is normal. | + | | - Check whether the add-on support the target version. | + +---------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | :ref:`Checking the Helm Chart ` | Check whether the current HelmRelease record contains discarded Kubernetes APIs that are not supported by the target cluster version. If yes, the Helm chart may be unavailable after the upgrade. | + +---------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | :ref:`Checking the Master Node SSH Connectivity ` | Check whether CCE can connect to your master nodes. | + +---------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | :ref:`Checking the Node Pool ` | - Check the node status. | + | | - Check whether the auto scaling function of the node pool is disabled. | + +---------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | :ref:`Checking the Security Group ` | Check whether the security group allows the master node to access nodes using ICMP. | + +---------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | :ref:`To-Be-Migrated Node ` | Check whether the node needs to be migrated. | + +---------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | :ref:`Discarded Kubernetes Resource ` | Check whether there are discarded resources in the clusters. | + +---------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | :ref:`Compatibility Risk ` | Read the version compatibility differences and ensure that they are not affected. | + +---------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | :ref:`Node CCEAgent Version ` | Check whether cce-agent on the current node is of the latest version. | + +---------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | :ref:`Node CPU Usage ` | Check whether the CPU usage of the node exceeds 90%. | + +---------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | :ref:`CRD Check ` | - Check whether the key CRD **packageversions.version.cce.io** of the cluster is deleted. | + | | - Check whether the cluster key CRD **network-attachment-definitions.k8s.cni.cncf.io** is deleted. | + +---------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | :ref:`Node Disk ` | - Check whether the key data disks on the node meet the upgrade requirements. | + | | - Check whether the **/tmp** directory has 500 MB available space. | + +---------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | :ref:`Node DNS ` | - Check whether the DNS configuration of the current node can resolve the OBS address. | + | | - Check whether the current node can access the OBS address of the storage upgrade component package. | + +---------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | :ref:`Node Key Directory File Permissions ` | Check whether the key directory **/var/paas** on the nodes contain files with abnormal owners or owner groups. | + +---------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | :ref:`Kubelet ` | Check whether the kubelet on the node is running properly. | + +---------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | :ref:`Node Memory ` | Check whether the memory usage of the node exceeds 90%. | + +---------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | :ref:`Node Clock Synchronization Server ` | Check whether the clock synchronization server ntpd or chronyd of the node is running properly. | + +---------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | :ref:`Node OS ` | Check whether the OS kernel version of the node is supported by CCE. | + +---------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | :ref:`Node CPU Count ` | Check whether the number of CPUs on the master node is greater than 2. | + +---------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | :ref:`Node Python Command ` | Check whether the Python commands are available on a node. | + +---------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | :ref:`Node Readiness ` | Check whether the nodes in the cluster are ready. | + +---------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | :ref:`Node journald ` | Check whether journald of a node is normal. | + +---------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | :ref:`containerd.sock Check ` | Check whether the containerd.sock file exists on the node. This file affects the startup of container runtime in the Euler OS. | + +---------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | :ref:`Internal Error ` | Before the upgrade, check whether an internal error occurs. | + +---------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | :ref:`Node Mount Point ` | Check whether inaccessible mount points exist on the node. | + +---------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | :ref:`Kubernetes Node Taint ` | Check whether the taint needed for cluster upgrade exists on the node. | + +---------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | :ref:`everest Restriction Check ` | Check whether the current everest add-on has compatibility restrictions. | + +---------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | :ref:`cce-hpa-controller Restriction Check ` | Check whether the current cce-controller-hpa add-on has compatibility restrictions. | + +---------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | :ref:`Enhanced CPU Management Policy ` | Check whether the current cluster version and the target version support enhanced CPU policy. | + +---------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | :ref:`User Node Components Health ` | Check whether the container runtime and network components on the user node are healthy. | + +---------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | :ref:`Controller Node Components Health ` | Check whether the Kubernetes, container runtime, and network components of the controller node are healthy. | + +---------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | :ref:`Memory Resource Limit of Kubernetes Components ` | Check whether the resources of Kubernetes components, such as etcd and kube-controller-manager, exceed the upper limit. | + +---------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | :ref:`Checking Deprecated Kubernetes APIs ` | Check whether the called API has been discarded in the target Kubernetes version. | + +---------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | :ref:`IPv6 Capability of a CCE Turbo Cluster ` | If IPv6 is enabled for a CCE Turbo cluster, check whether the target cluster version supports IPv6. | + +---------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | :ref:`Node NetworkManager ` | Check whether NetworkManager of a node is normal. | + +---------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | :ref:`Node ID File ` | Check the ID file format. | + +---------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | :ref:`Node Configuration Consistency ` | When you upgrade a CCE cluster to v1.19 or later, the system checks whether the following configuration files have been modified in the background: | + +---------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | :ref:`Node Configuration File ` | Check whether the configuration files of key components exist on the node. | + +---------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | :ref:`Checking CoreDNS Configuration Consistency ` | Check whether the current CoreDNS key configuration Corefile is different from the Helm release record. The difference may be overwritten during the add-on upgrade, **affecting domain name resolution in the cluster**. | + +---------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ diff --git a/umn/source/clusters/upgrading_a_cluster/troubleshooting_for_pre-upgrade_check_exceptions/to-be-migrated_node.rst b/umn/source/clusters/upgrading_a_cluster/troubleshooting_for_pre-upgrade_check_exceptions/to-be-migrated_node.rst new file mode 100644 index 0000000..247cdb3 --- /dev/null +++ b/umn/source/clusters/upgrading_a_cluster/troubleshooting_for_pre-upgrade_check_exceptions/to-be-migrated_node.rst @@ -0,0 +1,28 @@ +:original_name: cce_10_0439.html + +.. _cce_10_0439: + +To-Be-Migrated Node +=================== + +Check Item +---------- + +Check whether the node needs to be migrated. + +Solution +-------- + +For the 1.15 cluster that is upgraded from 1.13 in rolling mode, you need to migrate (reset or create and replace) all nodes before performing the upgrade again. + +**Solution 1** + +Go the CCE console and access the cluster console. Choose **Nodes** in the navigation pane and click **More** > **Reset Node** in the **Operation** column of the corresponding node. For details, see :ref:`Resetting a Node `. After the node is reset, retry the check task. + +.. note:: + + Resetting a node will reset all node labels, which may affect workload scheduling. Before resetting a node, check and retain the labels that you have manually added to the node. + +**Solution 2** + +After creating a node, delete the faulty node. diff --git a/umn/source/clusters/upgrading_a_cluster/troubleshooting_for_pre-upgrade_check_exceptions/user_node_components_health.rst b/umn/source/clusters/upgrading_a_cluster/troubleshooting_for_pre-upgrade_check_exceptions/user_node_components_health.rst new file mode 100644 index 0000000..8d972ec --- /dev/null +++ b/umn/source/clusters/upgrading_a_cluster/troubleshooting_for_pre-upgrade_check_exceptions/user_node_components_health.rst @@ -0,0 +1,16 @@ +:original_name: cce_10_0484.html + +.. _cce_10_0484: + +User Node Components Health +=========================== + +Check Item +---------- + +Check whether the container runtime and network components on the user node are healthy. + +Solution +-------- + +If a component is abnormal, log in to the node to check the status of the abnormal component and rectify the fault. diff --git a/umn/source/clusters/upgrading_a_cluster/upgrade_overview.rst b/umn/source/clusters/upgrading_a_cluster/upgrade_overview.rst index 6dcb5f3..7664f48 100644 --- a/umn/source/clusters/upgrading_a_cluster/upgrade_overview.rst +++ b/umn/source/clusters/upgrading_a_cluster/upgrade_overview.rst @@ -18,7 +18,7 @@ An upgrade flag will be displayed on the cluster card view if there is a new ver Log in to the CCE console and check whether the message "New version available" is displayed in the lower left corner of the cluster. If yes, the cluster can be upgraded. If no, the cluster cannot be upgraded. -.. figure:: /_static/images/en-us_image_0000001482796460.png +.. figure:: /_static/images/en-us_image_0000001568902653.png :alt: **Figure 1** Cluster with the upgrade flag **Figure 1** Cluster with the upgrade flag @@ -32,19 +32,27 @@ The following table describes the target version to which each cluster version c .. table:: **Table 1** Cluster upgrade paths and impacts - +-----------------+-----------------+------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------+ - | Source Version | Target Version | Upgrade Modes | Impacts | - +=================+=================+==================+================================================================================================================================================================+ - | v1.19 | v1.21 | In-place upgrade | You need to learn about the differences between versions. For details, see :ref:`Precautions for Major Version Upgrade `. | - +-----------------+-----------------+------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------+ - | v1.17 | v1.19 | In-place upgrade | You need to learn about the differences between versions. For details, see :ref:`Precautions for Major Version Upgrade `. | - | | | | | - | v1.15 | | | | - +-----------------+-----------------+------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------+ - | v1.13 | v1.15 | Rolling upgrade | - **proxy** in the coredns add-on cannot be configured and needs to be replaced with **forward**. | - | | | | - The storage add-on is changed from storage-driver to everest. | - | | | Replace upgrade | | - +-----------------+-----------------+------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------+ + +-----------------------+-----------------------+-----------------------+ + | Source Version | Target Version | Upgrade Modes | + +=======================+=======================+=======================+ + | v1.23 | v1.25 | In-place upgrade | + +-----------------------+-----------------------+-----------------------+ + | v1.21 | v1.25 | In-place upgrade | + | | | | + | | v1.23 | | + +-----------------------+-----------------------+-----------------------+ + | v1.19 | v1.23 | In-place upgrade | + | | | | + | | v1.21 | | + +-----------------------+-----------------------+-----------------------+ + | v1.17 | v1.19 | In-place upgrade | + | | | | + | v1.15 | | | + +-----------------------+-----------------------+-----------------------+ + | v1.13 | v1.15 | Rolling upgrade | + | | | | + | | | Replace upgrade | + +-----------------------+-----------------------+-----------------------+ Upgrade Modes ------------- @@ -68,56 +76,3 @@ The upgrade processes are the same for master nodes. The differences between the +----------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | **Replace upgrade** | The latest worker node image is used to reset the node OS. | This is the fastest upgrade mode and requires few manual interventions. | Data or configurations on the node will be lost, and services will be interrupted for a period of time. | +----------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ - -.. _cce_10_0197__section191131551162610: - -Precautions for Major Version Upgrade -------------------------------------- - -+-----------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ -| Upgrade Path | Difference | Self-Check | -+=======================+==============================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================+================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================+ -| v1.19 to v1.21 | The bug of **exec probe timeouts** is fixed in Kubernetes 1.21. Before this bug fix, the exec probe does not consider the **timeoutSeconds** field. Instead, the probe will run indefinitely, even beyond its configured deadline. It will stop until the result is returned. If this field is not specified, the default value **1** is used. This field takes effect after the upgrade. If the probe runs over 1 second, the application health check may fail and the application may restart frequently. | Before the upgrade, check whether the timeout is properly set for the exec probe. | -+-----------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ -| | kube-apiserver of CCE 1.19 or later requires that the Subject Alternative Names (SANs) field be configured for the certificate of your webhook server. Otherwise, kube-apiserver fails to call the webhook server after the upgrade, and containers cannot be started properly. | Before the upgrade, check whether the SAN field is configured in the certificate of your webhook server. | -| | | | -| | Root cause: X.509 `CommonName `__ is discarded in Go 1.15. kube-apiserver of CCE 1.19 is compiled using Go 1.15. If your webhook certificate does not have SANs, kube-apiserver does not process the **CommonName** field of the X.509 certificate as the host name by default. As a result, the authentication fails. | - If you do not have your own webhook server, you can skip this check. | -| | | - If the field is not set, you are advised to use the SAN field to specify the IP address and domain name supported by the certificate. | -+-----------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ -| v1.15 to v1.19 | The control plane of CCE 1.19 is incompatible with Kubelet 1.15. If the master node fails to be upgraded or the node to be upgraded restarts after the master node is successfully upgraded, there is a high probability that the node is in the **NotReady** status. | #. In normal cases, this scenario is not triggered. | -| | | #. After the master node is upgraded, do not suspend the upgrade. Upgrade the node quickly. | -| | There is a high probability that kubelet restarts on the node that fails to be upgraded, triggering the node registration process. The default registration labels of kubelet 1.15 (**failure-domain.beta.kubernetes.io/is-baremetal** and **kubernetes.io/availablezone**) are regarded as an invalid label by kube-apiserver 1.19. | #. If a node fails to be upgraded and cannot be restored, evict applications on the node as soon as possible. Contact technical support and skip the node upgrade. After the upgrade is complete, reset the node. | -| | | | -| | The valid labels in v1.19 are **node.kubernetes.io/baremetal** and **failure-domain.beta.kubernetes.io/zone**. | | -+-----------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ -| | In CCE 1.15 and 1.19 clusters, the Docker storage driver file system is switched from XFS to Ext4. As a result, the import package sequence in the pods of the upgraded Java application may be abnormal, causing pod exceptions. | Before the upgrade, check the Docker configuration file **/etc/docker/daemon.json** on the node. Check whether the value of **dm.fs** is **xfs**. | -| | | | -| | | - If the value is **ext4** or the storage driver is Overlay, you can skip the next steps. | -| | | - If the value is **xfs**, you are advised to deploy applications in the cluster of the new version in advance to test whether the applications are compatible with the new cluster version. | -| | | | -| | | .. code-block:: | -| | | | -| | | { | -| | | "storage-driver": "devicemapper", | -| | | "storage-opts": [ | -| | | "dm.thinpooldev=/dev/mapper/vgpaas-thinpool", | -| | | "dm.use_deferred_removal=true", | -| | | "dm.fs=xfs", | -| | | "dm.use_deferred_deletion=true" | -| | | ] | -| | | } | -+-----------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ -| | kube-apiserver of CCE 1.19 or later requires that the Subject Alternative Names (SANs) field be configured for the certificate of your webhook server. Otherwise, kube-apiserver fails to call the webhook server after the upgrade, and containers cannot be started properly. | Before the upgrade, check whether the SAN field is configured in the certificate of your webhook server. | -| | | | -| | Root cause: X.509 `CommonName `__ is discarded in Go 1.15. kube-apiserver of CCE 1.19 is compiled using Go 1.15. The **CommonName** field is processed as the host name. As a result, the authentication fails. | - If you do not have your own webhook server, you can skip this check. | -| | | - If the field is not set, you are advised to use the SAN field to specify the IP address and domain name supported by the certificate. | -| | | | -| | | .. important:: | -| | | | -| | | NOTICE: | -| | | To mitigate the impact of version differences on cluster upgrade, CCE performs special processing during the upgrade from 1.15 to 1.19 and still supports certificates without SANs. However, no special processing is required for subsequent upgrades. You are advised to rectify your certificate as soon as possible. | -+-----------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ -| | In clusters of v1.17.17 and later, CCE automatically creates pod security policies (PSPs) for you, which restrict the creation of pods with unsafe configurations, for example, pods for which **net.core.somaxconn** under a sysctl is configured in the security context. | After an upgrade, you can allow insecure system configurations as required. For details, see :ref:`Configuring a Pod Security Policy `. | -+-----------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ -| v1.13 to v1.15 | After a VPC network cluster is upgraded, the master node occupies an extra CIDR block due to the upgrade of network components. If no container CIDR block is available for the new node, the pod scheduled to the node cannot run. | Generally, this problem occurs when the nodes in the cluster are about to fully occupy the container CIDR block. For example, the container CIDR block is 10.0.0.0/16, the number of available IP addresses is 65,536, and the VPC network is allocated a CIDR block with the fixed size (using the mask to determine the maximum number of container IP addresses allocated to each node). If the upper limit is 128, the cluster supports a maximum of 512 (65536/128) nodes, including the three master nodes. After the cluster is upgraded, each of the three master nodes occupies one CIDR block. As a result, 506 nodes are supported. | -+-----------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ diff --git a/umn/source/clusters/using_kubectl_to_run_a_cluster/connecting_to_a_cluster_using_kubectl.rst b/umn/source/clusters/using_kubectl_to_run_a_cluster/connecting_to_a_cluster_using_kubectl.rst index 0be6fa1..814dae3 100644 --- a/umn/source/clusters/using_kubectl_to_run_a_cluster/connecting_to_a_cluster_using_kubectl.rst +++ b/umn/source/clusters/using_kubectl_to_run_a_cluster/connecting_to_a_cluster_using_kubectl.rst @@ -33,17 +33,27 @@ CCE allows you to access a cluster through a **VPC network** or a **public netwo Download kubectl and the configuration file. Copy the file to your client, and configure kubectl. After the configuration is complete, you can access your Kubernetes clusters. Procedure: -#. .. _cce_10_0107__li194691356201712: +#. Download kubectl. - Download kubectl. + Prepare a computer that can access the public network and install kubectl in CLI mode. You can run the **kubectl version** command to check whether kubectl has been installed. If kubectl has been installed, skip this step. - On the `Kubernetes release `__ page, click the corresponding link based on the cluster version, click **Client Binaries**, and download the corresponding platform software package. Alternatively, you can install kubectl with curl following the guide in `Install Tools `__. + This section uses the Linux environment as an example to describe how to install and configure kubectl. For details, see `Installing kubectl `__. + a. Log in to your client and download kubectl. - .. figure:: /_static/images/en-us_image_0000001336475537.png - :alt: **Figure 1** Downloading kubectl + .. code-block:: - **Figure 1** Downloading kubectl + cd /home + curl -LO https://dl.k8s.io/release/{v1.25.0}/bin/linux/amd64/kubectl + + **{v1.25.0}** specifies the version number. Replace it as required. + + b. Install kubectl. + + .. code-block:: + + chmod +x kubectl + mv -f kubectl /usr/local/bin #. .. _cce_10_0107__li34691156151712: @@ -58,21 +68,15 @@ Download kubectl and the configuration file. Copy the file to your client, and c - The Kubernetes permissions assigned by the configuration file downloaded by IAM users are the same as those assigned to the IAM users on the CCE console. - If the KUBECONFIG environment variable is configured in the Linux OS, kubectl preferentially loads the KUBECONFIG environment variable instead of **$home/.kube/config**. -#. Configure kubectl. +#. .. _cce_10_0107__li25451059122317: - Install and configure kubectl (A Linux OS is used as an example). + Configure kubectl. - a. Copy the kubectl downloaded in :ref:`1 ` and the configuration file downloaded in :ref:`2 ` to the **/home** directory on your client. + Configure kubectl (A Linux OS is used). - b. Log in to your client and configure kubectl. If you have installed kubectl, skip this step. + a. Log in to your client and copy the kubeconfig.json configuration file downloaded in :ref:`2 ` to the **/home** directory on your client. - .. code-block:: - - cd /home - chmod +x kubectl - mv -f kubectl /usr/local/bin - - c. Log in to your client and configure the kubeconfig file. + b. Configure the kubectl authentication file. .. code-block:: @@ -80,7 +84,7 @@ Download kubectl and the configuration file. Copy the file to your client, and c mkdir -p $HOME/.kube mv -f kubeconfig.json $HOME/.kube/config - d. Switch the kubectl access mode based on service scenarios. + c. Switch the kubectl access mode based on service scenarios. - Run this command to enable intra-VPC access: @@ -117,20 +121,34 @@ Currently, CCE supports two-way authentication for domain names. - For a cluster that has been bound to an EIP, if the authentication fails (x509: certificate is valid) when two-way authentication is used, you need to bind the EIP again and download **kubeconfig.json** again. -- If the domain name two-way authentication is not supported, **kubeconfig.json** contains the **"insecure-skip-tls-verify": true** field, as shown in :ref:`Figure 2 `. To use two-way authentication, you can download the **kubeconfig.json** file again and enable two-way authentication for the domain names. +- If the domain name two-way authentication is not supported, **kubeconfig.json** contains the **"insecure-skip-tls-verify": true** field, as shown in :ref:`Figure 1 `. To use two-way authentication, you can download the **kubeconfig.json** file again and enable two-way authentication for the domain names. .. _cce_10_0107__fig1941342411: - .. figure:: /_static/images/en-us_image_0000001199021320.png - :alt: **Figure 2** Two-way authentication disabled for domain names + .. figure:: /_static/images/en-us_image_0000001568822965.png + :alt: **Figure 1** Two-way authentication disabled for domain names - **Figure 2** Two-way authentication disabled for domain names + **Figure 1** Two-way authentication disabled for domain names -Common Issue (Error from server Forbidden) ------------------------------------------- +Common Issues +------------- -When you use kubectl to create or query Kubernetes resources, the following output is returned: +- **Error from server Forbidden** -# kubectl get deploy Error from server (Forbidden): deployments.apps is forbidden: User "0c97ac3cb280f4d91fa7c0096739e1f8" cannot list resource "deployments" in API group "apps" in the namespace "default" + When you use kubectl to create or query Kubernetes resources, the following output is returned: -The cause is that the user does not have the permissions to operate the Kubernetes resources. For details about how to assign permissions, see :ref:`Namespace Permissions (Kubernetes RBAC-based) `. + .. code-block:: + + # kubectl get deploy Error from server (Forbidden): deployments.apps is forbidden: User "0c97ac3cb280f4d91fa7c0096739e1f8" cannot list resource "deployments" in API group "apps" in the namespace "default" + + The cause is that the user does not have the permissions to operate the Kubernetes resources. For details about how to assign permissions, see :ref:`Namespace Permissions (Kubernetes RBAC-based) `. + +- **The connection to the server localhost:8080 was refused** + + When you use kubectl to create or query Kubernetes resources, the following output is returned: + + .. code-block:: + + The connection to the server localhost:8080 was refused - did you specify the right host or port? + + The cause is that cluster authentication is not configured for the kubectl client. For details, see :ref:`3 `. diff --git a/umn/source/clusters/using_kubectl_to_run_a_cluster/customizing_a_cluster_certificate_san.rst b/umn/source/clusters/using_kubectl_to_run_a_cluster/customizing_a_cluster_certificate_san.rst index d0e4f39..f56d612 100644 --- a/umn/source/clusters/using_kubectl_to_run_a_cluster/customizing_a_cluster_certificate_san.rst +++ b/umn/source/clusters/using_kubectl_to_run_a_cluster/customizing_a_cluster_certificate_san.rst @@ -39,4 +39,4 @@ Typical Domain Name Access Scenarios - Use domain name access in the intranet. DNS allows you to configure mappings between cluster EIPs and custom domain names. After an EIP is updated, you can continue to use two-way authentication and the domain name to access the cluster without downloading the **kubeconfig.json** file again. - Add A records on a self-built DNS server. -.. |image1| image:: /_static/images/en-us_image_0000001199341268.png +.. |image1| image:: /_static/images/en-us_image_0000001517743644.png diff --git a/umn/source/configuration_center/cluster_secrets.rst b/umn/source/configmaps_and_secrets/cluster_secrets.rst similarity index 100% rename from umn/source/configuration_center/cluster_secrets.rst rename to umn/source/configmaps_and_secrets/cluster_secrets.rst diff --git a/umn/source/configuration_center/creating_a_configmap.rst b/umn/source/configmaps_and_secrets/creating_a_configmap.rst similarity index 86% rename from umn/source/configuration_center/creating_a_configmap.rst rename to umn/source/configmaps_and_secrets/creating_a_configmap.rst index 0124ef5..3e7c1a2 100644 --- a/umn/source/configuration_center/creating_a_configmap.rst +++ b/umn/source/configmaps_and_secrets/creating_a_configmap.rst @@ -18,6 +18,12 @@ Benefits of ConfigMaps: - Deploy workloads in different environments. Multiple versions are supported for configuration files so that you can update and roll back workloads easily. - Quickly import configurations in the form of files to containers. +Notes and Constraints +--------------------- + +- The size of a ConfigMap resource file cannot exceed 2 MB. +- ConfigMaps cannot be used in `static pods `__. + Procedure --------- @@ -51,23 +57,6 @@ Procedure The new ConfigMap is displayed in the ConfigMap list. -ConfigMap Requirements ----------------------- - -A ConfigMap resource file must be in YAML format, and the file size cannot exceed 2 MB. - -The file name is **configmap.yaml** and the following shows a configuration example. - -.. code-block:: - - apiVersion: v1 - kind: ConfigMap - metadata: - name: test-configmap - data: - data-1: value-1 - data-2: value-2 - Creating a ConfigMap Using kubectl ---------------------------------- @@ -87,26 +76,38 @@ Creating a ConfigMap Using kubectl SPECIAL_LEVEL: Hello SPECIAL_TYPE: CCE + .. table:: **Table 2** Key parameters + + ============= ================================================== + Parameter Description + ============= ================================================== + apiVersion The value is fixed at **v1**. + kind The value is fixed at **ConfigMap**. + metadata.name ConfigMap name, which can be customized. + data ConfigMap data. The value must be key-value pairs. + ============= ================================================== + #. Run the following commands to create a ConfigMap. **kubectl create -f cce-configmap.yaml** + Run the following commands to view the created ConfigMap: + **kubectl get cm** .. code-block:: NAME DATA AGE - cce-configmap 3 3h - cce-configmap1 3 7m + cce-configmap 3 7m Related Operations ------------------ -After creating a configuration item, you can update or delete it as described in :ref:`Table 2 `. +After creating a configuration item, you can update or delete it as described in :ref:`Table 3 `. .. _cce_10_0152__table1619535674020: -.. table:: **Table 2** Related operations +.. table:: **Table 3** Related operations +-----------------------------------+------------------------------------------------------------------------------------------------------+ | Operation | Description | @@ -122,4 +123,4 @@ After creating a configuration item, you can update or delete it as described in | | Follow the prompts to delete the ConfigMap. | +-----------------------------------+------------------------------------------------------------------------------------------------------+ -.. |image1| image:: /_static/images/en-us_image_0000001205757902.png +.. |image1| image:: /_static/images/en-us_image_0000001568902541.png diff --git a/umn/source/configuration_center/creating_a_secret.rst b/umn/source/configmaps_and_secrets/creating_a_secret.rst similarity index 68% rename from umn/source/configuration_center/creating_a_secret.rst rename to umn/source/configmaps_and_secrets/creating_a_secret.rst index 877105a..d6f061d 100644 --- a/umn/source/configuration_center/creating_a_secret.rst +++ b/umn/source/configmaps_and_secrets/creating_a_secret.rst @@ -10,6 +10,11 @@ Scenario A secret is a type of resource that holds sensitive data, such as authentication and key information. Its content is user-defined. After creating secrets, you can use them as files or environment variables in a containerized workload. +Notes and Constraints +--------------------- + +Secrets cannot be used in `static pods `__. + Procedure --------- @@ -36,14 +41,15 @@ Procedure | | | | | - Opaque: common secret. | | | - kubernetes.io/dockerconfigjson: a secret that stores the authentication information required for pulling images from a private repository. | - | | - IngressTLS: a secret that stores the certificate required by ingresses (layer-7 load balancing Services). | + | | - **kubernetes.io/tls**: Kubernetes TLS secret, which is used to store the certificate required by layer-7 load balancing Services. | + | | - **IngressTLS**: TLS secret provided by CCE to store the certificate required by layer-7 load balancing Services. | | | - Other: another type of secret, which is specified manually. | +-----------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------+ | Secret Data | Workload secret data can be used in containers. | | | | | | - If **Secret Type** is **Opaque**, click |image1|. In the dialog box displayed, enter a key-value pair and select **Auto Base64 Encoding**. | | | - If the secret type is kubernetes.io/dockerconfigjson, enter the account and password of the private image repository. | - | | - If the secret type is IngressTLS, upload the certificate file and private key file. | + | | - If **Secret Type** is **kubernetes.io/tls** or **IngressTLS**, upload the certificate file and private key file. | | | | | | .. note:: | | | | @@ -57,16 +63,16 @@ Procedure The new secret is displayed in the key list. +.. _cce_10_0153__section187197531454: + Secret Resource File Configuration ---------------------------------- This section describes configuration examples of secret resource description files. -For example, you can retrieve the username and password for a workload through a secret. +- Opaque -- YAML format - - The **secret.yaml** file is defined as shown below. The value must be based on the Base64 coding method. For details about the method, see :ref:`Base64 Encoding `. + The **secret.yaml** file is defined as shown below. The **data** field is filled in as a key-value pair, and the **value** field must be encoded using Base64. For details about the Base64 encoding method, see :ref:`Base64 Encoding `. .. code-block:: @@ -76,9 +82,91 @@ For example, you can retrieve the username and password for a workload through a name: mysecret #Secret name namespace: default #Namespace. The default value is default. data: - username: ****** #The value must be Base64-encoded. - password: ****** #The value must be encoded using Base64. - type: Opaque #You are advised not to change this parameter value. + : # Enter a key-value pair. The value must be encoded using Base64. + type: Opaque + +- kubernetes.io/dockerconfigjson + + The **secret.yaml** file is defined as shown below. The value of **.dockerconfigjson** must be encoded using Base64. For details, see :ref:`Base64 Encoding `. + + .. code-block:: + + apiVersion: v1 + kind: Secret + metadata: + name: mysecret #Secret name + namespace: default #Namespace. The default value is default. + data: + .dockerconfigjson: eyJh***** # Content encoded using Base64. + type: kubernetes.io/dockerconfigjson + + To obtain the **.dockerconfigjson** content, perform the following steps: + + #. Obtain the login information of the image repository. + + - Image repository address: The section uses *address* as an example. Replace it with the actual address. + - Username: The section uses *username* as an example. Replace it with the actual username. + - Password: The section uses *password* as an example. Replace it with the actual password. + + #. Use Base64 to encode the key-value pair **username:password** and fill the encoded content in step :ref:`3 `. + + .. code-block:: + + echo -n "username:password" | base64 + + Command output: + + .. code-block:: + + dXNlcm5hbWU6cGFzc3dvcmQ= + + #. .. _cce_10_0153__li157901847113720: + + Use Base64 to encode the following JSON content: + + .. code-block:: + + echo -n '{"auths":{"address":{"username":"username","password":"password","auth":"dXNlcm5hbWU6cGFzc3dvcmQ="}}}' | base64 + + Command output: + + .. code-block:: + + eyJhdXRocyI6eyJhZGRyZXNzIjp7InVzZXJuYW1lIjoidXNlcm5hbWUiLCJwYXNzd29yZCI6InBhc3N3b3JkIiwiYXV0aCI6ImRYTmxjbTVoYldVNmNHRnpjM2R2Y21RPSJ9fX0= + + The encoded content is the **.dockerconfigjson** content. + +- kubernetes.io/tls + + The value of **tls.crt** and **tls.key** must be encoded using Base64. For details, see :ref:`Base64 Encoding `. + + .. code-block:: + + kind: Secret + apiVersion: v1 + metadata: + name: mysecret #Secret name + namespace: default #Namespace. The default value is default. + data: + tls.crt: LS0tLS1CRU*****FURS0tLS0t # Certificate content, which must be encoded using Base64. + tls.key: LS0tLS1CRU*****VZLS0tLS0= # Private key content, which must be encoded using Base64. + type: kubernetes.io/tls + +- IngressTLS + + The value of **tls.crt** and **tls.key** must be encoded using Base64. For details, see :ref:`Base64 Encoding `. + + .. code-block:: + + kind: Secret + apiVersion: v1 + metadata: + name: mysecret #Secret name + namespace: default #Namespace. The default value is default. + data: + tls.crt: LS0tLS1CRU*****FURS0tLS0t # Certificate content, which must be encoded using Base64. + tls.key: LS0tLS1CRU*****VZLS0tLS0= # Private key content, which must be encoded using Base64. + type: IngressTLS Creating a Secret Using kubectl ------------------------------- @@ -94,6 +182,8 @@ Creating a Secret Using kubectl **vi cce-secret.yaml** + The following YAML file uses the Opaque type as an example. For details about other types, see :ref:`Secret Resource File Configuration `. + .. code-block:: apiVersion: v1 @@ -102,8 +192,7 @@ Creating a Secret Using kubectl name: mysecret type: Opaque data: - username: ****** - password: ****** + : # Enter a key-value pair. The value must be encoded using Base64. #. Create a secret. @@ -111,7 +200,7 @@ Creating a Secret Using kubectl You can query the secret after creation. - **kubectl get secret** + **kubectl get secret -n default** Related Operations ------------------ @@ -156,4 +245,4 @@ To Base64-encode a string, run the **echo -n content to be encoded \| base64** c root@ubuntu:~# echo -n "content to be encoded" | base64 ****** -.. |image1| image:: /_static/images/en-us_image_0000001249958645.png +.. |image1| image:: /_static/images/en-us_image_0000001518222636.png diff --git a/umn/source/configuration_center/index.rst b/umn/source/configmaps_and_secrets/index.rst similarity index 89% rename from umn/source/configuration_center/index.rst rename to umn/source/configmaps_and_secrets/index.rst index 7690d2a..921ee8f 100644 --- a/umn/source/configuration_center/index.rst +++ b/umn/source/configmaps_and_secrets/index.rst @@ -2,8 +2,8 @@ .. _cce_10_0045: -Configuration Center -==================== +ConfigMaps and Secrets +====================== - :ref:`Creating a ConfigMap ` - :ref:`Using a ConfigMap ` diff --git a/umn/source/configmaps_and_secrets/using_a_configmap.rst b/umn/source/configmaps_and_secrets/using_a_configmap.rst new file mode 100644 index 0000000..8cf3dd6 --- /dev/null +++ b/umn/source/configmaps_and_secrets/using_a_configmap.rst @@ -0,0 +1,407 @@ +:original_name: cce_10_0015.html + +.. _cce_10_0015: + +Using a ConfigMap +================= + +- :ref:`Setting Workload Environment Variables ` +- :ref:`Setting Command Line Parameters ` +- :ref:`Attaching a ConfigMap to the Workload Data Volume ` + +The following example shows how to use a ConfigMap. + +.. code-block:: + + apiVersion: v1 + kind: ConfigMap + metadata: + name: cce-configmap + data: + SPECIAL_LEVEL: Hello + SPECIAL_TYPE: CCE + +.. important:: + + - When a ConfigMap is used in a workload, the workload and ConfigMap must be in the same cluster and namespace. + + - When a ConfigMap is mounted as a data volume and is updated, Kubernetes updates the data in the data volume at the same time. + + When a ConfigMap data volume mounted in `subPath `__ mode is updated, Kubernetes cannot automatically update the data in the data volume. + + - When a ConfigMap is used as an environment variable, data can not be automatically updated when the ConfigMap is updated. To update the data, you need to restart the pod. + +.. _cce_10_0015__section1737733192813: + +Setting Workload Environment Variables +-------------------------------------- + +**Using the console** + +#. Log in to the CCE console and access the cluster console. + +#. In the navigation pane, choose **Workloads**. Then, click **Create Workload**. + + When creating a workload, click **Environment Variables** in the **Container Settings** area, and click |image1|. + + - **Added from ConfigMap**: Select a ConfigMap to import all of its keys as environment variables. + + - **Added from ConfigMap key**: Import a key in a ConfigMap as the value of an environment variable. + + - **Variable Name**: name of an environment variable in the workload. The name can be customized and is set to the key name selected in the ConfigMap by default. + - **Variable Value/Reference**: Select a ConfigMap and the key to be imported. The corresponding value is imported as a workload environment variable. + + For example, after you import the value **Hello** of **SPECIAL_LEVEL** in ConfigMap **cce-configmap** as the value of workload environment variable **SPECIAL_LEVEL**, an environment variable named **SPECIAL_LEVEL** with its value **Hello** exists in the container. + +#. Configure other workload parameters and click **Create Workload**. + + After the workload runs properly, :ref:`access the container ` and run the following command to check whether the ConfigMap has been set as an environment variable of the workload: + + .. code-block:: + + printenv SPECIAL_LEVEL + + The example output is as follows: + + .. code-block:: + + Hello + +**Using kubectl** + +#. According to :ref:`Connecting to a Cluster Using kubectl `, configure the **kubectl** command to connect an ECS to the cluster. + +#. Create a file named **nginx-configmap.yaml** and edit it. + + **vi nginx-configmap.yaml** + + Content of the YAML file: + + - **Added from ConfigMap**: To add all data in a ConfigMap to environment variables, use the **envFrom** parameter. The keys in the ConfigMap will become names of environment variables in a pod. + + .. code-block:: + + apiVersion: apps/v1 + kind: Deployment + metadata: + name: nginx-configmap + spec: + replicas: 1 + selector: + matchLabels: + app: nginx-configmap + template: + metadata: + labels: + app: nginx-configmap + spec: + containers: + - name: container-1 + image: nginx:latest + envFrom: # Use envFrom to specify a ConfigMap to be referenced by environment variables. + - configMapRef: + name: cce-configmap # Name of the referenced ConfigMap. + imagePullSecrets: + - name: default-secret + + - **Added from a ConfigMap key**: When creating a workload, you can use a ConfigMap to set environment variables and use the **valueFrom** parameter to reference the key-value pair in the ConfigMap separately. + + .. code-block:: + + apiVersion: apps/v1 + kind: Deployment + metadata: + name: nginx-configmap + spec: + replicas: 1 + selector: + matchLabels: + app: nginx-configmap + template: + metadata: + labels: + app: nginx-configmap + spec: + containers: + - name: container-1 + image: nginx:latest + env: # Set environment variables in the workload. + - name: SPECIAL_LEVEL # Name of the environment variable in the workload. + valueFrom: # Use valueFrom to specify an environment variable to reference a ConfigMap. + configMapKeyRef: + name: cce-configmap # Name of the referenced ConfigMap. + key: SPECIAL_LEVEL # Key in the referenced ConfigMap. + - name: SPECIAL_TYPE # Add multiple environment variables. Multiple environment variables can be imported at the same time. + valueFrom: + configMapKeyRef: + name: cce-configmap + key: SPECIAL_TYPE + imagePullSecrets: + - name: default-secret + +#. Create a workload. + + **kubectl apply -f nginx-configmap.yaml** + +#. View the environment variables in the pod. + + a. Run the following command to view the created pod: + + .. code-block:: + + kubectl get pod | grep nginx-configmap + + Expected output: + + .. code-block:: + + nginx-configmap-*** 1/1 Running 0 2m18s + + b. Run the following command to view the environment variables in the pod: + + .. code-block:: + + kubectl exec nginx-configmap-*** -- printenv SPECIAL_LEVEL SPECIAL_TYPE + + Expected output: + + .. code-block:: + + Hello + CCE + + The ConfigMap has been set as an environment variable of the workload. + +.. _cce_10_0015__section17930105710189: + +Setting Command Line Parameters +------------------------------- + +You can use a ConfigMap as an environment variable to set commands or parameter values for a container by using the environment variable substitution syntax $VAR_NAME. + +**Using the console** + +#. Log in to the CCE console and access the cluster console. + +#. In the navigation pane, choose **Workloads**. Then, click **Create Workload**. + + When creating a workload, click **Environment Variables** in the **Container Settings** area, and click |image2|. In this example, select **Added from ConfigMap**. + + - **Added from ConfigMap**: Select a ConfigMap to import all of its keys as environment variables. + +#. Click **Lifecycle** in the **Container Settings** area, click the **Post-Start** tab on the right, and set the following parameters: + + - **Processing Method**: **CLI** + + - **Command**: Enter the following three command lines. *SPECIAL_LEVEL* and *SPECIAL_TYPE* are the environment variable names in the workload, that is, the key names in the **cce-configmap** ConfigMap. + + .. code-block:: + + /bin/bash + -c + echo $SPECIAL_LEVEL $SPECIAL_TYPE > /usr/share/nginx/html/index.html + +#. Configure other workload parameters and click **Create Workload**. + + After the workload runs properly, :ref:`access the container ` and run the following command to check whether the ConfigMap has been set as an environment variable of the workload: + + .. code-block:: + + cat /usr/share/nginx/html/index.html + + The example output is as follows: + + .. code-block:: + + Hello CCE + +**Using kubectl** + +#. According to :ref:`Connecting to a Cluster Using kubectl `, configure the **kubectl** command to connect an ECS to the cluster. + +#. Create a file named **nginx-configmap.yaml** and edit it. + + **vi nginx-configmap.yaml** + + As shown in the following example, the **cce-configmap** ConfigMap is imported to the workload. **SPECIAL_LEVEL** and **SPECIAL_TYPE** are environment variable names, that is, key names in the **cce-configmap** ConfigMap. + + .. code-block:: + + apiVersion: apps/v1 + kind: Deployment + metadata: + name: nginx-configmap + spec: + replicas: 1 + selector: + matchLabels: + app: nginx-configmap + template: + metadata: + labels: + app: nginx-configmap + spec: + containers: + - name: container-1 + image: nginx:latest + lifecycle: + postStart: + exec: + command: [ "/bin/sh", "-c", "echo $SPECIAL_LEVEL $SPECIAL_TYPE > /usr/share/nginx/html/index.html" ] + envFrom: # Use envFrom to specify a ConfigMap to be referenced by environment variables. + - configMapRef: + name: cce-configmap # Name of the referenced ConfigMap. + imagePullSecrets: + - name: default-secret + +#. Create a workload. + + **kubectl apply -f nginx-configmap.yaml** + +#. After the workload runs properly, the following content is entered into the **/usr/share/nginx/html/index.html** file in the container: + + a. Run the following command to view the created pod: + + .. code-block:: + + kubectl get pod | grep nginx-configmap + + Expected output: + + .. code-block:: + + nginx-configmap-*** 1/1 Running 0 2m18s + + b. Run the following command to view the environment variables in the pod: + + .. code-block:: + + kubectl exec nginx-configmap-*** -- cat /usr/share/nginx/html/index.html + + Expected output: + + .. code-block:: + + Hello CCE + +.. _cce_10_0015__section1490261161916: + +Attaching a ConfigMap to the Workload Data Volume +------------------------------------------------- + +The data stored in a ConfigMap can be referenced in a volume of type ConfigMap. You can mount such a volume to a specified container path. The platform supports the separation of workload codes and configuration files. ConfigMap volumes are used to store workload configuration parameters. Before that, you need to create ConfigMaps in advance. For details, see :ref:`Creating a ConfigMap `. + +**Using the console** + +#. Log in to the CCE console and access the cluster console. + +#. In the navigation pane, choose **Workloads**. Then, click **Create Workload**. + + When creating a workload, click **Data Storage** in the **Container Settings** area. Click **Add Volume** and select **ConfigMap** from the drop-down list. + +#. Set the local volume type to **ConfigMap** and set parameters for adding a local volume, as shown in :ref:`Table 1 `. + + .. _cce_10_0015__table1776324831114: + + .. table:: **Table 1** Mounting a ConfigMap volume + + +-----------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | Parameter | Description | + +===================================+=====================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================+ + | Option | Select the desired ConfigMap name. | + | | | + | | A ConfigMap must be created in advance. For details, see :ref:`Creating a ConfigMap `. | + +-----------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | Add Container Path | Configure the following parameters: | + | | | + | | a. **Container Path**: Enter the path of the container, for example, **/tmp**. | + | | | + | | This parameter indicates the container path to which a data volume will be mounted. Do not mount the volume to a system directory such as **/** or **/var/run**; this action may cause container errors. You are advised to mount the container to an empty directory. If the directory is not empty, ensure that there are no files affecting container startup in the directory. Otherwise, such files will be replaced, resulting in failures to start the container and create the workload. | + | | | + | | .. important:: | + | | | + | | NOTICE: | + | | When the container is mounted to a high-risk directory, you are advised to use an account with minimum permissions to start the container; otherwise, high-risk files on the host machine may be damaged. | + | | | + | | b. **subPath**: Enter a subpath, for example, **tmp**. | + | | | + | | - A subpath is used to mount a local volume so that the same data volume is used in a single pod. | + | | - The subpath can be the key and value of a ConfigMap or secret. If the subpath is a key-value pair that does not exist, the data import does not take effect. | + | | - The data imported by specifying a subpath will not be updated along with the ConfigMap/secret updates. | + | | | + | | c. Set the permission to **Read-only**. Data volumes in the path are read-only. | + | | | + | | You can click |image3| to add multiple paths and subpaths. | + +-----------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + +**Using kubectl** + +#. According to :ref:`Connecting to a Cluster Using kubectl `, configure the **kubectl** command to connect an ECS to the cluster. + +#. Create a file named **nginx-configmap.yaml** and edit it. + + **vi nginx-configmap.yaml** + + As shown in the following example, after the ConfigMap volume is mounted, a configuration file with the key as the file name and value as the file content is generated in the **/etc/config** directory of the container. + + .. code-block:: + + apiVersion: apps/v1 + kind: Deployment + metadata: + name: nginx-configmap + spec: + replicas: 1 + selector: + matchLabels: + app: nginx-configmap + template: + metadata: + labels: + app: nginx-configmap + spec: + containers: + - name: container-1 + image: nginx:latest + volumeMounts: + - name: config-volume + mountPath: /etc/config # Mount to the /etc/config directory. + readOnly: true + volumes: + - name: config-volume + configMap: + name: cce-configmap # Name of the referenced ConfigMap. + +#. Create a workload. + + **kubectl apply -f nginx-configmap.yaml** + +#. After the workload runs properly, the **SPECIAL_LEVEL** and **SPECIAL_TYPE** files are generated in the **/etc/config** directory. The contents of the files are **Hello** and **CCE**, respectively. + + a. Run the following command to view the created pod: + + .. code-block:: + + kubectl get pod | grep nginx-configmap + + Expected output: + + .. code-block:: + + nginx-configmap-*** 1/1 Running 0 2m18s + + b. Run the following command to view the **SPECIAL_LEVEL** or **SPECIAL_TYPE** file in the pod: + + .. code-block:: + + kubectl exec nginx-configmap-*** -- /etc/config/SPECIAL_LEVEL + + Expected output: + + .. code-block:: + + Hello + +.. |image1| image:: /_static/images/en-us_image_0000001568822917.png +.. |image2| image:: /_static/images/en-us_image_0000001568902649.png +.. |image3| image:: /_static/images/en-us_image_0000001569023025.png diff --git a/umn/source/configmaps_and_secrets/using_a_secret.rst b/umn/source/configmaps_and_secrets/using_a_secret.rst new file mode 100644 index 0000000..dc9c5fd --- /dev/null +++ b/umn/source/configmaps_and_secrets/using_a_secret.rst @@ -0,0 +1,323 @@ +:original_name: cce_10_0016.html + +.. _cce_10_0016: + +Using a Secret +============== + +.. important:: + + Do not perform any operation on the following secrets. For details, see :ref:`Cluster Secrets `. + + - Do not operate secrets under kube-system. + - Do not operate default-secret and paas.elb in any of the namespaces. The default-secret is used to pull the private image of SWR, and the paas.elb is used to connect the service in the namespace to the ELB service. + +- :ref:`Setting Environment Variables of a Workload ` +- :ref:`Configuring the Data Volume of a Workload ` + +The following example shows how to use a secret. + +.. code-block:: + + apiVersion: v1 + kind: Secret + metadata: + name: mysecret + type: Opaque + data: + username: ****** #The value must be Base64-encoded. + password: ****** #The value must be encoded using Base64. + +.. important:: + + - When a secret is used in a pod, the pod and secret must be in the same cluster and namespace. + + - When a secret is updated, Kubernetes updates the data in the data volume at the same time. + + However, when a secret data volume mounted in `subPath `__ mode is updated, Kubernetes cannot automatically update the data in the data volume. + +.. _cce_10_0016__section207271352141216: + +Setting Environment Variables of a Workload +------------------------------------------- + +**Using the console** + +#. Log in to the CCE console and access the cluster console. + +#. In the navigation pane, choose **Workloads**. Then, click **Create Workload**. + + When creating a workload, click **Environment Variables** in the **Container Settings** area, and click |image1|. + + - **Added from secret**: Select a secret and import all keys in the secret as environment variables. + + - **Added from secret key**: Import the value of a key in a secret as the value of an environment variable. + + - **Variable Name**: name of an environment variable in the workload. The name can be customized and is set to the key name selected in the secret by default. + - **Variable Value/Reference**: Select a secret and the key to be imported. The corresponding value is imported as a workload environment variable. + + For example, after you import the value of **username** in secret **mysecret** as the value of workload environment variable **username**, an environment variable named **username** exists in the container. + +#. Configure other workload parameters and click **Create Workload**. + + After the workload runs properly, :ref:`access the container ` and run the following command to check whether the secret has been set as an environment variable of the workload: + + .. code-block:: + + printenv username + + If the output is the same as that in the secret, the secret has been set as an environment variable of the workload. + +**Using kubectl** + +#. According to :ref:`Connecting to a Cluster Using kubectl `, configure the **kubectl** command to connect an ECS to the cluster. + +#. Create a file named **nginx-secret.yaml** and edit it. + + **vi nginx-secret.yaml** + + Content of the YAML file: + + - **Added from a secret**: To add all data in a secret to environment variables, use the **envFrom** parameter. The keys in the ConfigMap will become names of environment variables in a workload. + + .. code-block:: + + apiVersion: apps/v1 + kind: Deployment + metadata: + name: nginx-secret + spec: + replicas: 1 + selector: + matchLabels: + app: nginx-secret + template: + metadata: + labels: + app: nginx-secret + spec: + containers: + - name: container-1 + image: nginx:latest + envFrom: # Use envFrom to specify a secret to be referenced by environment variables. + - secretRef: + name: mysecret # Name of the referenced secret. + imagePullSecrets: + - name: default-secret + + - **Added from a secret key**: When creating a workload, you can set a secret to set environment variables and use the **valueFrom** parameter to reference the key-value pair in the secret separately. + + .. code-block:: + + apiVersion: apps/v1 + kind: Deployment + metadata: + name: nginx-secret + spec: + replicas: 1 + selector: + matchLabels: + app: nginx-secret + template: + metadata: + labels: + app: nginx-secret + spec: + containers: + - name: container-1 + image: nginx:latest + env: # Set environment variables in the workload. + - name: SECRET_USERNAME # Name of the environment variable in the workload. + valueFrom: # Use envFrom to specify a secret to be referenced by environment variables. + secretKeyRef: + name: mysecret # Name of the referenced secret. + key: username # Name of the referenced key. + - name: SECRET_PASSWORD # Add multiple environment variables. Multiple environment variables can be imported at the same time. + valueFrom: + secretKeyRef: + name: mysecret + key: password + imagePullSecrets: + - name: default-secret + +#. Create a workload. + + **kubectl apply -f nginx-secret.yaml** + +#. View the environment variables in the pod. + + a. Run the following command to view the created pod: + + .. code-block:: + + kubectl get pod | grep nginx-secret + + Expected output: + + .. code-block:: + + nginx-secret-*** 1/1 Running 0 2m18s + + b. Run the following command to view the environment variables in the pod: + + .. code-block:: + + kubectl exec nginx-secret-*** -- printenv SPECIAL_USERNAME SPECIAL_PASSWORD + + If the output is the same as that in the secret, the secret has been set as an environment variable of the workload. + +.. _cce_10_0016__section472505211214: + +Configuring the Data Volume of a Workload +----------------------------------------- + +You can mount a secret as a volume to the specified container path. Contents in a secret are user-defined. Before that, you need to create a secret. For details, see :ref:`Creating a Secret `. + +**Using the console** + +#. Log in to the CCE console and access the cluster console. + +#. In the navigation pane on the left, click **Workloads**. In the right pane, click the **Deployments** tab. Click **Create Workload** in the upper right corner. + + When creating a workload, click **Data Storage** in the **Container Settings** area. Click **Add Volume** and select **Secret** from the drop-down list. + +#. Set the local volume type to **Secret** and set parameters for adding a local volume, as shown in :ref:`Table 1 `. + + .. _cce_10_0016__table861818920109: + + .. table:: **Table 1** Secret + + +-----------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | Parameter | Description | + +===================================+=====================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================+ + | Secret | Select the desired secret name. | + | | | + | | A secret must be created in advance. For details, see :ref:`Creating a Secret `. | + +-----------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | Add Container Path | Configure the following parameters: | + | | | + | | a. **Container Path**: Enter the path of the container, for example, **/tmp**. | + | | | + | | This parameter indicates the container path to which a data volume will be mounted. Do not mount the volume to a system directory such as **/** or **/var/run**; this action may cause container errors. You are advised to mount the container to an empty directory. If the directory is not empty, ensure that there are no files affecting container startup in the directory. Otherwise, such files will be replaced, resulting in failures to start the container and create the workload. | + | | | + | | .. important:: | + | | | + | | NOTICE: | + | | When the container is mounted to a high-risk directory, you are advised to use an account with minimum permissions to start the container; otherwise, high-risk files on the host machine may be damaged. | + | | | + | | b. **subPath**: Enter a subpath, for example, **tmp**. | + | | | + | | - A subpath is used to mount a local volume so that the same data volume is used in a single pod. | + | | - The subpath can be the key and value of a ConfigMap or secret. If the subpath is a key-value pair that does not exist, the data import does not take effect. | + | | - The data imported by specifying a subpath will not be updated along with the ConfigMap/secret updates. | + | | | + | | c. Set the permission to **Read-only**. Data volumes in the path are read-only. | + | | | + | | You can click |image2| to add multiple paths and subpaths. | + +-----------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + +**Using kubectl** + +#. According to :ref:`Connecting to a Cluster Using kubectl `, configure the **kubectl** command to connect an ECS to the cluster. + +#. Create a file named **nginx-secret.yaml** and edit it. + + **vi nginx-secret.yaml** + + In the following example, the username and password in the **mysecret** secret are saved in the **/etc/foo** directory as files. + + .. code-block:: + + apiVersion: apps/v1 + kind: Deployment + metadata: + name: nginx-secret + spec: + replicas: 1 + selector: + matchLabels: + app: nginx-secret + template: + metadata: + labels: + app: nginx-secret + spec: + containers: + - name: container-1 + image: nginx:latest + volumeMounts: + - name: foo + mountPath: /etc/foo # Mount to the /etc/foo directory. + readOnly: true + volumes: + - name: foo + secret: + secretName: mysecret # Name of the referenced secret. + + You can also use the **items** field to control the mapping path of the secret key. For example, store the username is stored in the **/etc/foo/my-group/my-username** directory of the container. + + .. note:: + + - After the **items** field is used to specify the mapping path of the secret key, the keys that are not specified will not be created as files. For example, if the password key in the following example is not specified, the file will not be created. + - If you want to use all keys in a secret, you must list all keys in the **items** field. + - All keys listed in the **items** field must exist in the corresponding secret. Otherwise, the volume is not created. + + .. code-block:: + + apiVersion: apps/v1 + kind: Deployment + metadata: + name: nginx-secret + spec: + replicas: 1 + selector: + matchLabels: + app: nginx-secret + template: + metadata: + labels: + app: nginx-secret + spec: + containers: + - name: container-1 + image: nginx:latest + volumeMounts: + - name: foo + mountPath: /etc/foo # Mount to the /etc/foo directory. + readOnly: true + volumes: + - name: foo + secret: + secretName: mysecret # Name of the referenced secret. + items: + - key: username # Name of the referenced key. + path: my-group/my-username # Mapping path of the secret key. + +#. Create a workload. + + **kubectl apply -f nginx-secret.yaml** + +#. After the workload runs properly, the **username** and **password** files are generated in the **/etc/foo** directory. + + a. Run the following command to view the created pod: + + .. code-block:: + + kubectl get pod | grep nginx-secret + + Expected output: + + .. code-block:: + + nginx-secret-*** 1/1 Running 0 2m18s + + b. Run the following command to view the **username** or **password** file in the pod: + + .. code-block:: + + kubectl exec nginx-secret-*** -- /etc/foo/username + + The expected output is the same as that in the secret. + +.. |image1| image:: /_static/images/en-us_image_0000001518062644.png +.. |image2| image:: /_static/images/en-us_image_0000001569182625.png diff --git a/umn/source/configuration_center/using_a_configmap.rst b/umn/source/configuration_center/using_a_configmap.rst deleted file mode 100644 index 0a3664b..0000000 --- a/umn/source/configuration_center/using_a_configmap.rst +++ /dev/null @@ -1,159 +0,0 @@ -:original_name: cce_10_0015.html - -.. _cce_10_0015: - -Using a ConfigMap -================= - -- :ref:`Setting Workload Environment Variables ` -- :ref:`Setting Command Line Parameters ` -- :ref:`Attaching a ConfigMap to the Workload Data Volume ` - -The following example shows how to use a ConfigMap. - -.. code-block:: - - apiVersion: v1 - kind: ConfigMap - metadata: - name: cce-configmap - data: - SPECIAL_LEVEL: Hello - SPECIAL_TYPE: CCE - -.. important:: - - When a ConfigMap is used in a pod, the pod and ConfigMap must be in the same cluster and namespace. - -.. _cce_10_0015__section1737733192813: - -Setting Workload Environment Variables --------------------------------------- - -When creating a workload, you can use a ConfigMap to set environment variables. The **valueFrom** parameter indicates the key-value pair to be referenced. - -.. code-block:: - - apiVersion: v1 - kind: Pod - metadata: - name: configmap-pod-1 - spec: - containers: - - name: test-container - image: busybox - command: [ "/bin/sh", "-c", "env" ] - env: - - name: SPECIAL_LEVEL_KEY - valueFrom: ## Use valueFrom to specify the value of the env that refers to the ConfigMap. - configMapKeyRef: - name: cce-configmap ## Name of the referenced configuration file. - key: SPECIAL_LEVEL ## Key of the referenced ConfigMap. - restartPolicy: Never - -If you need to define the values of multiple ConfigMaps as the environment variables of the pods, add multiple environment variable parameters to the pods. - -.. code-block:: - - env: - - name: SPECIAL_LEVEL_KEY - valueFrom: - configMapKeyRef: - name: cce-configmap - key: SPECIAL_LEVEL - - name: SPECIAL_TYPE_KEY - valueFrom: - configMapKeyRef: - name: cce-configmap - key: SPECIAL_TYPE - -To add all data in a ConfigMap to environment variables, use the **envFrom** parameter. The keys in the ConfigMap will become names of environment variables in a pod. - -.. code-block:: - - apiVersion: v1 - kind: Pod - metadata: - name: configmap-pod-2 - spec: - containers: - - name: test-container - image: busybox - command: [ "/bin/sh", "-c", "env" ] - envFrom: - - configMapRef: - name: cce-configmap - restartPolicy: Never - -.. _cce_10_0015__section17930105710189: - -Setting Command Line Parameters -------------------------------- - -You can use a ConfigMap to set commands or parameter values for a container by using the environment variable substitution syntax $(VAR_NAME). The following shows an example. - -.. code-block:: - - apiVersion: v1 - kind: Pod - metadata: - name: configmap-pod-3 - spec: - containers: - - name: test-container - image: busybox - command: [ "/bin/sh", "-c", "echo $(SPECIAL_LEVEL_KEY) $(SPECIAL_TYPE_KEY)" ] - env: - - name: SPECIAL_LEVEL_KEY - valueFrom: - configMapKeyRef: - name: cce-configmap - key: SPECIAL_LEVEL - - name: SPECIAL_TYPE_KEY - valueFrom: - configMapKeyRef: - name: cce-configmap - key: SPECIAL_TYPE - restartPolicy: Never - -After the pod runs, the following information is displayed: - -.. code-block:: - - Hello CCE - -.. _cce_10_0015__section1490261161916: - -Attaching a ConfigMap to the Workload Data Volume -------------------------------------------------- - -A ConfigMap can also be used in the data volume. You only need to attach the ConfigMap to the workload when creating the workload. After the mounting is complete, a configuration file with key as the file name and value as the file content is generated. - -.. code-block:: - - apiVersion: v1 - kind: Pod - metadata: - name: configmap-pod-4 - spec: - containers: - - name: test-container - image: busybox - command: [ "/bin/sh", "-c", "ls /etc/config/" ] ## Lists the file names in the directory. - volumeMounts: - - name: config-volume - mountPath: /etc/config ## Attaches to the /etc/config directory. - volumes: - - name: config-volume - configMap: - name: cce-configmap - restartPolicy: Never - -After the pod is run, the **SPECIAL_LEVEL** and **SPECIAL_TYPE** files are generated in the **/etc/config** directory. The contents of the files are Hello and CCE, respectively. Also, the following file names will be displayed. - -.. code-block:: - - SPECIAL_TYPE - SPECIAL_LEVEL - -To mount a ConfigMap to a data volume, you can also perform operations on the CCE console. When creating a workload, set advanced settings for the container, choose **Data Storage** > **Local Volume**, click **Add Local Volume**, and select **ConfigMap**. For details, see :ref:`ConfigMap `. diff --git a/umn/source/configuration_center/using_a_secret.rst b/umn/source/configuration_center/using_a_secret.rst deleted file mode 100644 index 9945789..0000000 --- a/umn/source/configuration_center/using_a_secret.rst +++ /dev/null @@ -1,115 +0,0 @@ -:original_name: cce_10_0016.html - -.. _cce_10_0016: - -Using a Secret -============== - -.. important:: - - The following secrets are used by the CCE system. Do not perform any operations on them. - - - Do not operate secrets under kube-system. - - Do not operate default-secret and paas.elb in any of the namespaces. The default-secret is used to pull the private image of SWR, and the paas.elb is used to connect the service in the namespace to the ELB service. - -- :ref:`Configuring the Data Volume of a Pod ` -- :ref:`Setting Environment Variables of a Pod ` - -The following example shows how to use a secret. - -.. code-block:: - - apiVersion: v1 - kind: Secret - metadata: - name: mysecret - type: Opaque - data: - username: ****** #The value must be Base64-encoded. - password: ****** #The value must be encoded using Base64. - -.. important:: - - When a secret is used in a pod, the pod and secret must be in the same cluster and namespace. - -.. _cce_10_0016__section472505211214: - -Configuring the Data Volume of a Pod ------------------------------------- - -A secret can be used as a file in a pod. As shown in the following example, the username and password of the **mysecret** secret are saved in the **/etc/foo** directory as files. - -.. code-block:: - - apiVersion: v1 - kind: Pod - metadata: - name: mypod - spec: - containers: - - name: mypod - image: redis - volumeMounts: - - name: foo - mountPath: "/etc/foo" - readOnly: true - volumes: - - name: foo - secret: - secretName: mysecret - -In addition, you can specify the directory and permission to access a secret. The username is stored in the **/etc/foo/my-group/my-username** directory of the container. - -.. code-block:: - - apiVersion: v1 - kind: Pod - metadata: - name: mypod - spec: - containers: - - name: mypod - image: redis - volumeMounts: - - name: foo - mountPath: "/etc/foo" - volumes: - - name: foo - secret: - secretName: mysecret - items: - - key: username - path: my-group/my-username - mode: 511 - -To mount a secret to a data volume, you can also perform operations on the CCE console. When creating a workload, set advanced settings for the container, choose **Data Storage > Local Volume**, click **Add Local Volume**, and select **Secret**. For details, see :ref:`Secret `. - -.. _cce_10_0016__section207271352141216: - -Setting Environment Variables of a Pod --------------------------------------- - -A secret can be used as an environment variable of a pod. As shown in the following example, the username and password of the **mysecret** secret are defined as an environment variable of the pod. - -.. code-block:: - - apiVersion: v1 - kind: Pod - metadata: - name: secret-env-pod - spec: - containers: - - name: mycontainer - image: redis - env: - - name: SECRET_USERNAME - valueFrom: - secretKeyRef: - name: mysecret - key: username - - name: SECRET_PASSWORD - valueFrom: - secretKeyRef: - name: mysecret - key: password - restartPolicy: Never diff --git a/umn/source/getting_started/creating_a_deployment_nginx_from_an_image.rst b/umn/source/getting_started/creating_a_deployment_nginx_from_an_image.rst new file mode 100644 index 0000000..ba1cc01 --- /dev/null +++ b/umn/source/getting_started/creating_a_deployment_nginx_from_an_image.rst @@ -0,0 +1,91 @@ +:original_name: cce_qs_0003.html + +.. _cce_qs_0003: + +Creating a Deployment (Nginx) from an Image +=========================================== + +You can use images to quickly create a single-pod workload that can be accessed from public networks. This section describes how to use CCE to quickly deploy an Nginx application and manage its life cycle. + +Prerequisites +------------- + +- The Nginx image has been pushed to SWR. +- You have created a CCE cluster that contains a node with 4 vCPUs and 8 GB memory. The node has an elastic IP address (EIP). + +- A cluster is a logical group of cloud servers that run workloads. Each cloud server is a node in the cluster. +- For details on how to create a cluster, see :ref:`Creating a Kubernetes Cluster `. + +Nginx Overview +-------------- + +Nginx is a lightweight web server. On CCE, you can quickly set up a Nginx web server. + +This section uses the Nginx application as an example to describe how to create a workload. The creation takes about 5 minutes. + +After Nginx is created successfully, you can access the Nginx web page. + + +.. figure:: /_static/images/en-us_image_0000001550558281.png + :alt: **Figure 1** Nginx web page + + **Figure 1** Nginx web page + +Procedure +--------- + +The following is the procedure for creating a containerized workload from a container image. + +#. Log in to the CCE console. + +#. Choose the target cluster. + +#. In the navigation pane, choose **Workloads**. Then, click **Create Workload**. + +#. Configure the following parameters and retain the default value for other parameters: + + **Basic Info** + + - **Workload Type**: Select **Deployment**. + - **Workload Name**: Set it to **nginx**. + - **Namespace**: Select **default**. + - **Pods**: Set the quantity of pods to **1**. + + **Container Settings** + + Enter **nginx:latest** in the **Image Name** text box. + + **Service Settings** + + Click the plus sign (+) to create a Service for accessing the workload from an external network. In this example, create a LoadBalancer Service. Set the following parameters: + + - **Service Name**: name of the Service exposed to external networks. In this example, the Service name is **nginx**. + - **Service Type**: Select **LoadBalancer**. + - **Service Affinity**: Retain the default value. + - **Load Balancer**: If a load balancer is available, select an existing load balancer. If not, choose **Auto create** to create one on the ELB console. + - **Port**: + + - **Protocol**: Select **TCP**. + - **Service Port**: Set this parameter to **8080**, which is mapped to the container port. + - **Container Port**: port on which the application listens. For containers created using the Nginx image, set this parameter to **80**. For other applications, set this parameter to the port of the application. + +#. Click **Create Workload**. + + Wait until the workload is created. + + The created Deployment will be displayed on the **Deployments** page. + +Accessing Nginx +--------------- + +#. Obtain the external access address of Nginx. + + Click the Nginx workload to enter its details page. On the **Access Mode** tab page, you can view the IP address of Nginx. The public IP address is the external access address. + +#. Enter the **external access address** in the address box of a browser. The following shows the welcome page if you successfully access the workload. + + + .. figure:: /_static/images/en-us_image_0000001550558289.png + :alt: **Figure 2** Accessing Nginx + + **Figure 2** Accessing Nginx diff --git a/umn/source/getting_started/creating_a_kubernetes_cluster.rst b/umn/source/getting_started/creating_a_kubernetes_cluster.rst new file mode 100644 index 0000000..5393d63 --- /dev/null +++ b/umn/source/getting_started/creating_a_kubernetes_cluster.rst @@ -0,0 +1,112 @@ +:original_name: cce_qs_0008.html + +.. _cce_qs_0008: + +Creating a Kubernetes Cluster +============================= + +Context +------- + +This section describes how to quickly create a CCE cluster. In this example, the default or simple configurations are in use. + +Creating a Cluster +------------------ + +#. Log in to the CCE console. + + - If you have not created a cluster, a wizard page is displayed. Click **Create** under **CCE cluster**. + - If you have created a cluster, choose **Clusters** from the navigation pane on the left and click **Create** next to **CCE cluster**. + +#. On the **Configure Cluster** page, configure cluster parameters. + + In this example, a majority of parameters retain default values. Only mandatory parameters are described. For details, see :ref:`Table 1 `. + + .. _cce_qs_0008__table462753513248: + + .. table:: **Table 1** Parameters for creating a cluster + + +-----------------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | Parameter | Description | + +===================================+================================================================================================================================================================================================================+ + | **Basic Settings** | | + +-----------------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | \*Cluster Name | Name of the cluster to be created. A cluster name contains 4 to 128 characters starting with a lowercase letter and not ending with a hyphen (-). Only lowercase letters, digits, and hyphens (-) are allowed. | + +-----------------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | \* Enterprise Project | This parameter is displayed only for enterprise users who have enabled Enterprise Project Management. | + +-----------------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | \* Cluster Version | Choose the latest version. | + +-----------------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | \* Cluster Scale | Maximum number of **worker nodes** that can be managed by the cluster. If you select **50 nodes**, the cluster can manage a maximum of 50 worker nodes. | + +-----------------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | \*High Availability | The default value is **Yes**. | + +-----------------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | **Network Settings** | | + +-----------------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | \* Network Model | Retain the default settings. | + +-----------------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | \*VPC | VPC where the cluster will be located. | + | | | + | | If no VPC is available, click **Create VPC** to create one. After the VPC is created, click refresh. | + +-----------------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | \* Master Node Subnet | Subnet where master nodes of the cluster are located. | + +-----------------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | \* Container CIDR Block | Retain the default value. | + +-----------------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | \* IPv4 Service CIDR Block | CIDR block for Services used by containers in the same cluster to access each other. The value determines the maximum number of Services you can create. The value cannot be changed after creation. | + +-----------------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + +#. Click **Next: Add-on Configuration**. Retain the default settings. + +#. Click **Next: Confirm**. After confirming that the cluster configuration information is correct, select **I have read and understand the preceding instructions** and click **Submit**. + + It takes about 6 to 10 minutes to create a cluster. + + The created cluster will be displayed on the **Clusters** page, and the number of nodes in the cluster is 0. + +Creating a Node +--------------- + +After a cluster is created, you need to create nodes in the cluster to run workloads. + +#. Log in to the CCE console. + +#. Click the created cluster. + +#. In the navigation pane, choose **Nodes**. Click **Create Node** in the upper right corner and set node parameters. + + The following describes only important parameters. For other parameters, retain the defaults. + + **Compute Settings** + + - **AZ**: Retain the default value. + - **Node Type**: Select **Elastic Cloud Server (VM)**. + - **Specifications**: Select node specifications that fit your business needs. + - **Container Engine**: Select a container engine as required. + - **OS**: Select the operating system (OS) of the nodes to be created. + - **Node Name**: Enter a node name. + - **Login Mode**: + + - If the login mode is **Key pair**, select a key pair for logging to the node and select the check box to acknowledge that you have obtained the key file and without this file you will not be able to log in to the node. + + A key pair is used for identity authentication when you remotely log in to a node. If no key pair is available, click **Create Key Pair**.. + + **Storage Settings** + + - **System Disk**: Set disk type and capacity based on site requirements. The default disk capacity is 50 GB. + - **Data Disk**: Set disk type and capacity based on site requirements. The default disk capacity is 100 GB. + + **Network Settings** + + - **VPC**: Use the default value, that is, the subnet selected during cluster creation. + - **Node Subnet**: Select a subnet in which the node runs. + - **Node IP**: IP address of the specified node. + - **EIP**: The default value is **Do not use**. You can select **Use existing** and **Auto create**. + +#. At the bottom of the page, select the node quantity, and click **Next: Confirm**. + +#. Review the node specifications, read the instructions, select **I have read and understand the preceding instructions**, and click **Submit**. + + It takes about 6 to 10 minutes to add a node. + + The created node will be displayed on the **Nodes** page. diff --git a/umn/source/getting_started/deploying_wordpress_and_mysql_that_depend_on_each_other/index.rst b/umn/source/getting_started/deploying_wordpress_and_mysql_that_depend_on_each_other/index.rst new file mode 100644 index 0000000..5eb5124 --- /dev/null +++ b/umn/source/getting_started/deploying_wordpress_and_mysql_that_depend_on_each_other/index.rst @@ -0,0 +1,18 @@ +:original_name: cce_qs_0007.html + +.. _cce_qs_0007: + +Deploying WordPress and MySQL That Depend on Each Other +======================================================= + +- :ref:`Overview ` +- :ref:`Step 1: Create a MySQL Workload ` +- :ref:`Step 2: Create a WordPress Workload ` + +.. toctree:: + :maxdepth: 1 + :hidden: + + overview + step_1_create_a_mysql_workload + step_2_create_a_wordpress_workload diff --git a/umn/source/getting_started/deploying_wordpress_and_mysql_that_depend_on_each_other/overview.rst b/umn/source/getting_started/deploying_wordpress_and_mysql_that_depend_on_each_other/overview.rst new file mode 100644 index 0000000..5e6c617 --- /dev/null +++ b/umn/source/getting_started/deploying_wordpress_and_mysql_that_depend_on_each_other/overview.rst @@ -0,0 +1,25 @@ +:original_name: cce_qs_0009.html + +.. _cce_qs_0009: + +Overview +======== + +WordPress was originally a blog platform based on PHP and MySQL. It is gradually evolved into a content management system. You can set up your own blog website on any server that supports PHP and MySQL. Thousands of plug-ins and countless theme templates are available for WordPress and easy to install. + +WordPress is a blog platform developed in hypertext preprocessor (PHP). You can set up your websites on the services that support PHP and MySQL databases, or use WordPress as a content management system. For more information about WordPress, visit https://wordpress.org/. + +WordPress must be used together with MySQL. WordPress runs the content management program while MySQL serves as a database to store data. Generally, WordPress and MySQL run in different containers, as shown in the following figure. + + +.. figure:: /_static/images/en-us_image_0000001550678257.png + :alt: **Figure 1** WordPress + + **Figure 1** WordPress + +In this example, two container images are involved. + +- `WordPress `__: Select wordpress:php7.3 in this example. +- `MySQL `__: Select mysql:5.7 in this example. + +When WordPress accesses MySQL in a cluster, Kubernetes provides a resource object called Service for the workload access. In this example, a Service is created for MySQL and WordPress, respectively. For details about how to create and configure a Service, see the following sections. diff --git a/umn/source/getting_started/deploying_wordpress_and_mysql_that_depend_on_each_other/step_1_create_a_mysql_workload.rst b/umn/source/getting_started/deploying_wordpress_and_mysql_that_depend_on_each_other/step_1_create_a_mysql_workload.rst new file mode 100644 index 0000000..7044cba --- /dev/null +++ b/umn/source/getting_started/deploying_wordpress_and_mysql_that_depend_on_each_other/step_1_create_a_mysql_workload.rst @@ -0,0 +1,59 @@ +:original_name: cce_qs_0004.html + +.. _cce_qs_0004: + +Step 1: Create a MySQL Workload +=============================== + +WordPress must be used together with MySQL. WordPress runs the content management program while MySQL serves as a database to store data. + +Prerequisites +------------- + +- The WordPress and MySQL images have been pushed to SWR. +- You have created a CCE cluster that contains a node with 4 vCPUs and 8 GB memory. For details on how to create a cluster, see :ref:`Creating a Kubernetes Cluster `. + +Creating a MySQL Workload +------------------------- + +#. Log in to the CCE console. + +#. Choose the target cluster. + +#. In the navigation pane, choose **Workloads**. Then, click **Create Workload**. + +#. Set workload parameters. + + **Basic Info** + + - **Workload Type**: Select **Deployment**. + - **Workload Name**: Set it to **mysql**. + - **Namespace**: Select **default**. + - **Pods**: Change the value to **1** in this example. + + **Container Settings** + + Enter **mysql:5.7** in the **Image Name** text box. + + Add the following four environment variables (details available in `MySQL `__): + + - **MYSQL_ROOT_PASSWORD**: password of the **root** user of MySQL. + - **MYSQL_DATABASE**: name of the database created during image startup. + - **MYSQL_USER**: name of the database user. + - **MYSQL_PASSWORD**: password of the database user. + + **Service Settings** + + Click the plus sign (+) to create a Service for accessing MySQL from WordPress. + + Select **ClusterIP** for **Service Type**, set **Service Name** to **mysql**, set both the **Container Port** and **Service Port** to **3306**, and click **OK**. + + The default access port in the MySQL image is 3306. In this example, both the container port and Service port are set to **3306** for convenience. The access port can be changed to another port. + + In this way, the MySQL workload can be accessed through **Service name:Access port** (**mysql:3306** in this example) from within the cluster. + +#. Click **Create Workload**. + + Wait until the workload is created. + + The created Deployment will be displayed on the **Deployments** page. diff --git a/umn/source/getting_started/deploying_wordpress_and_mysql_that_depend_on_each_other/step_2_create_a_wordpress_workload.rst b/umn/source/getting_started/deploying_wordpress_and_mysql_that_depend_on_each_other/step_2_create_a_wordpress_workload.rst new file mode 100644 index 0000000..e532ebe --- /dev/null +++ b/umn/source/getting_started/deploying_wordpress_and_mysql_that_depend_on_each_other/step_2_create_a_wordpress_workload.rst @@ -0,0 +1,102 @@ +:original_name: cce_qs_0005.html + +.. _cce_qs_0005: + +Step 2: Create a WordPress Workload +=================================== + +WordPress was originally a blog platform based on PHP and MySQL. It is gradually evolved into a content management system. You can set up your own blog website on any server that supports PHP and MySQL. Thousands of plug-ins and countless theme templates are available for WordPress and easy to install. + +This section describes how to create a public WordPress website from images. + +Prerequisites +------------- + +- The WordPress and MySQL images have been pushed to SWR. +- You have created a CCE cluster that contains a node with 4 vCPUs and 8 GB memory. For details on how to create a cluster, see :ref:`Creating a Kubernetes Cluster `. +- The MySQL database has been created by following the instructions in :ref:`Step 1: Create a MySQL Workload `. In this example, WordPress data is stored in the MySQL database. + +Creating a WordPress Blog Website +--------------------------------- + +#. Log in to the CCE console. + +#. Choose the target cluster. + +#. In the navigation pane, choose **Workloads**. Then, click **Create Workload**. + +#. Set workload parameters. + + **Basic Info** + + - **Workload Type**: Select **Deployment**. + - **Workload Name**: Set it to **wordpress**. + - **Namespace**: Select **default**. + - **Pods**: Set this parameter to **2** in this example. + + **Container Settings** + + Enter **wordpress:php7.3** in the **Image Name** text box. + + Add the following environment variables: + + (These variables let WordPress know the information about the MySQL database.) + + - **WORDPRESS_DB_HOST**: address for accessing the database, which can be found in the Service (on the **Services** tab page) of the MySQL workload. You can use the internal domain name **mysql.default.svc.cluster.local:3306** to access the database, or use only **mysql:3306** omitting **.default.svc.cluster.local**. + - **WORDPRESS_DB_USER**: username for accessing the database. The value must be the same as that of **MYSQL_USER** in :ref:`Step 1: Create a MySQL Workload `, which is used to connect to MySQL. + - **WORDPRESS_DB_PASSWORD**: password for accessing the database. The value must be the same as that of **MYSQL_PASSWORD** in :ref:`Step 1: Create a MySQL Workload `. + - **WORDPRESS_DB_NAME**: name of the database to be accessed. The value must be the same as that of **MYSQL_DATABASE** in :ref:`Step 1: Create a MySQL Workload `. + + **Service Settings** + + Click the plus sign (+) to create a Service for accessing the workload from an external network. In this example, create a LoadBalancer Service. Set the following parameters: + + - **Service Name**: name of the Service exposed to external networks. In this example, the Service name is **wordpress**. + - **Service Type**: Select **LoadBalancer**. + - **Service Affinity**: Retain the default value. + - **Load Balancer**: If a load balancer is available, select an existing load balancer. If not, choose **Auto create** to create one on the ELB console. + - **Port**: + + - **Protocol**: Select **TCP**. + - **Service Port**: Set this parameter to **80**, which is mapped to the container port. + - **Container Port**: port on which the application listens. For containers created using the wordpress image, set this parameter to **80**. For other applications, set this parameter to the port of the application. + +#. Click **Create Workload**. + + Wait until the workload is created. + + The created Deployment will be displayed on the **Deployments** page. + +Accessing WordPress +------------------- + +#. Obtain the external access address of WordPress. + + Click the wordpress workload to enter its details page. On the **Access Mode** tab page, you can view the IP address of WordPress. The load balancer IP address is the external access address. + +#. Enter the external access address in the address box of a browser to connect to the workload. + + The following figure shows the accessed WordPress page. + + + .. figure:: /_static/images/en-us_image_0000001550838141.png + :alt: **Figure 1** WordPress workload + + **Figure 1** WordPress workload + + + .. figure:: /_static/images/en-us_image_0000001550678265.png + :alt: **Figure 2** WordPress + + **Figure 2** WordPress + +Deleting Resources +------------------ + +Until now, you have completed all the Getting Started walkthroughs and have understood how to use CCE. Fees are incurred while nodes are running. If the clusters used in the Getting Started walkthroughs are no longer in use, perform the following steps to delete them. If you will continue the CCE walkthroughs, retain the clusters. + +#. Log in to the CCE console. +#. In the navigation pane on the left, choose **Clusters**. +#. Click |image1| next to a cluster and delete the cluster as prompted. + +.. |image1| image:: /_static/images/en-us_image_0000001499758244.png diff --git a/umn/source/getting_started/index.rst b/umn/source/getting_started/index.rst new file mode 100644 index 0000000..b7be175 --- /dev/null +++ b/umn/source/getting_started/index.rst @@ -0,0 +1,22 @@ +:original_name: cce_qs_0000.html + +.. _cce_qs_0000: + +Getting Started +=============== + +- :ref:`Introduction ` +- :ref:`Preparations ` +- :ref:`Creating a Kubernetes Cluster ` +- :ref:`Creating a Deployment (Nginx) from an Image ` +- :ref:`Deploying WordPress and MySQL That Depend on Each Other ` + +.. toctree:: + :maxdepth: 1 + :hidden: + + introduction + preparations + creating_a_kubernetes_cluster + creating_a_deployment_nginx_from_an_image + deploying_wordpress_and_mysql_that_depend_on_each_other/index diff --git a/umn/source/getting_started/introduction.rst b/umn/source/getting_started/introduction.rst new file mode 100644 index 0000000..d8ad89a --- /dev/null +++ b/umn/source/getting_started/introduction.rst @@ -0,0 +1,59 @@ +:original_name: cce_qs_0001.html + +.. _cce_qs_0001: + +Introduction +============ + +This section describes how to use Cloud Container Engine (CCE) and provides frequently asked questions (FAQs) to help you quickly get started with CCE. + +Procedure +--------- + +Complete the following tasks to get started with CCE. + + +.. figure:: /_static/images/en-us_image_0000001499760912.png + :alt: **Figure 1** Procedure for getting started with CCE + + **Figure 1** Procedure for getting started with CCE + +#. **Register an account and grant permissions to IAM users.** + + An account has the permissions to use CCE. However, IAM users created by an account do not have the permission. You need to manually grant the permission to IAM users. For details, see . + +#. **Create a cluster.** + + For details on how to create a regular Kubernetes cluster, see :ref:`Creating a Kubernetes Cluster `. + +#. **Create a workload from an image or chart.** + + - :ref:`Creating a Deployment (Nginx) from an Image ` + - :ref:`Deploying WordPress and MySQL That Depend on Each Other ` + +#. **View workload status and logs. Upgrade, scale, and monitor the workload.** + +FAQs +---- + +#. **Is CCE suitable for users who are not familiar with Kubernetes?** + + Yes. The CCE console is easy-to-use, and the *Getting Started* guide helps you quickly understand and use CCE. + +#. **Is CCE suitable for users who have little experience in building images?** + + In addition to storing images created by yourself in **My Images**, CCE allows you to create containerized applications using open source images. For details, see :ref:`Creating a Deployment (Nginx) from an Image `. + +#. **How do I create a workload using CCE?** + + Create a cluster and then create a workload in the cluster. For details, see :ref:`Creating a Deployment (Nginx) from an Image `. + +#. **How do I create a workload accessible to public networks?** + + CCE provides different workload access types to address diverse scenarios. + +#. **How can I allow multiple workloads in the same cluster to access each other?** + + Set **Service Type** to **ClusterIP**, which allows workloads in the same cluster to use their cluster-internal domain names to access each other. + + Cluster-internal domain names are in the format of ..svc.cluster.local:. For example, nginx.default.svc.cluster.local:80. diff --git a/umn/source/getting_started/preparations.rst b/umn/source/getting_started/preparations.rst new file mode 100644 index 0000000..0a7c2bc --- /dev/null +++ b/umn/source/getting_started/preparations.rst @@ -0,0 +1,112 @@ +:original_name: cce_qs_0006.html + +.. _cce_qs_0006: + +Preparations +============ + +Before using CCE, you need to make the following preparations: + +- :ref:`Creating an IAM user ` +- :ref:`Obtaining Resource Permissions ` +- :ref:`(Optional) Creating a VPC ` +- :ref:`(Optional) Creating a Key Pair ` + +.. _cce_qs_0006__section929013341428: + +Creating an IAM user +-------------------- + +If you want to allow multiple users to manage your resources without sharing your password or keys, you can create users using IAM and grant permissions to the users. These users can use specified links and their own accounts to access the cloud and manage resources efficiently. You can also configure account security policies to ensure the security of these accounts. + +Your accounts have the permissions to use CCE. However, IAM users created by your accounts do not have the permissions. You need to manually assign the permissions to IAM users. + +.. _cce_qs_0006__section8819171411219: + +Obtaining Resource Permissions +------------------------------ + +CCE works closely with multiple cloud services to support computing, storage, networking, and monitoring functions. When you log in to the CCE console for the first time, CCE automatically requests permissions to access those cloud services in the region where you run your applications. Specifically: + +- Compute services + + When you create a node in a cluster, a cloud server is created accordingly. The prerequisite is that CCE has obtained the permissions to access Elastic Cloud Service (ECS) and Bare Metal Server (BMS). + +- Storage services + + CCE allows you to mount storage to nodes and containers in a cluster. The prerequisite is that CCE has obtained the permissions to access services such as Elastic Volume Service (EVS), Scalable File Service (SFS), and Object Storage Service (OBS). + +- Networking services + + CCE allows containers in a cluster to be published as services that can be accessed by external systems. The prerequisite is that CCE has obtained the permissions to access services such as Virtual Private Cloud (VPC) and Elastic Load Balance (ELB). + +- Container and monitoring services + + CCE supports functions such as container image pull, monitoring, and logging. The prerequisite is that CCE has obtained the permissions to access services such as SoftWare Repository for Container (SWR) and Application Operations Management (AOM). + +After you agree to delegate the permissions, an agency named **cce_admin_trust** will be created for CCE in Identity and Access Management (IAM). The system account **op_svc_cce** will be delegated the **Tenant Administrator** role to perform operations on other cloud service resources. Tenant Administrator has the permissions on all cloud services except IAM, which calls the cloud services on which CCE depends. The delegation takes effect only in the current region. For details, see `Delegating Resource Access to Another Account `__. + +To use CCE in multiple regions, you need to request cloud resource permissions in each region. You can go to the IAM console, choose **Agencies**, and click **cce_admin_trust** to view the delegation records of each region. + +.. note:: + + CCE may fail to run as expected if the Tenant Administrator role is not assigned. Therefore, do not delete or modify the **cce_admin_trust** agency when using CCE. + +.. _cce_qs_0006__section896411852619: + +(Optional) Creating a VPC +------------------------- + +A VPC provides an isolated, configurable, and manageable virtual network for CCE clusters. + +Before creating the first cluster, ensure that a VPC has been created. + +If you already have a VPC available, skip this step. + +#. Log in to the management console. + +#. Click |image1| in the upper left corner and select a region and a project. + +#. Under **Networking**, click **Virtual Private Cloud**. + +#. Click **Create VPC**. + +#. On the **Create VPC** page, configure parameters as prompted. + + A default subnet will be created together with a VPC. You can click **Add Subnet** to create more subnets for the VPC. + +#. Click **Create Now**. + +.. _cce_qs_0006__section2031413481717: + +(Optional) Creating a Key Pair +------------------------------ + +The cloud platform uses public key cryptography to protect the login information of your CCE nodes. Passwords or key pairs are used for identity authentication during remote login to nodes. + +- You need to specify the key pair name and provide the private key when logging to CCE nodes using SSH if you choose the key pair login mode. +- If you choose the password login mode, skip this task. + +.. note:: + + If you want to create pods in multiple regions, you need to create a key pair in each region. + +**Creating a Key Pair on the Management Console** + +If you have no key pair, create one on the management console. The procedure is as follows: + +#. Log in to the management console. +#. Click |image2| in the upper left corner and select a region and a project. +#. Under **Computing**, click **Elastic Cloud Server**. +#. In the navigation pane on the left, choose **Key Pair**. +#. On the right pane, click **Create Key Pair**. +#. Enter the key name and click **OK**. +#. A key pair name consists of two parts: **KeyPair** and four random digits. You can enter an easy-to-remember name, for example, **KeyPair-xxxx_ecs**. +#. Manually or automatically download the private key file. The file name is a specified key pair name with a suffix of .pem. Securely store the private key file. In the dialog box displayed, click **OK**. + + .. note:: + + The private key file can be downloaded only once. Keep it secure. When creating an ECS, provide the name of your desired key pair. Each time you log in to the ECS using SSH, provide the private key. + +.. |image1| image:: /_static/images/en-us_image_0000001499598344.png +.. |image2| image:: /_static/images/en-us_image_0000001499758236.png diff --git a/umn/source/high-risk_operations_and_solutions.rst b/umn/source/high-risk_operations_and_solutions.rst new file mode 100644 index 0000000..44a5f1d --- /dev/null +++ b/umn/source/high-risk_operations_and_solutions.rst @@ -0,0 +1,128 @@ +:original_name: cce_10_0054.html + +.. _cce_10_0054: + +High-Risk Operations and Solutions +================================== + +During service deployment or running, you may trigger high-risk operations at different levels, causing service faults or interruption. To help you better estimate and avoid operation risks, this section introduces the consequences and solutions of high-risk operations from multiple dimensions, such as clusters, nodes, networking, load balancing, logs, and EVS disks. + +Clusters and Nodes +------------------ + +.. table:: **Table 1** High-risk operations and solutions + + +-----------------+-------------------------------------------------------------------------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------+ + | Category | Operation | Impact | Solution | + +=================+=======================================================================================================+======================================================================================================================================================================================================================================================================================+===================================================================================================================================================+ + | Master node | Modifying the security group of a node in a cluster | The master node may be unavailable. | Restore the security group by referring to the security group of the new cluster and allow traffic from the security group to pass through. | + | | | | | + | | | .. note:: | | + | | | | | + | | | Naming rule of a master node: *Cluster name*\ ``-``\ **cce-control**\ ``-``\ *Random number* | | + +-----------------+-------------------------------------------------------------------------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------+ + | | Letting the node expire or destroying the node | The master node will be unavailable. | This operation cannot be undone. | + +-----------------+-------------------------------------------------------------------------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------+ + | | Reinstalling the OS | Components on the master node will be deleted. | This operation cannot be undone. | + +-----------------+-------------------------------------------------------------------------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------+ + | | Upgrading components on the master or etcd node | The cluster may be unavailable. | Roll back to the original version. | + +-----------------+-------------------------------------------------------------------------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------+ + | | Deleting or formatting core directory data such as **/etc/kubernetes** on the node | The master node will be unavailable. | This operation cannot be undone. | + +-----------------+-------------------------------------------------------------------------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------+ + | | Changing the node IP address | The master node will be unavailable. | Change the IP address back to the original one. | + +-----------------+-------------------------------------------------------------------------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------+ + | | Modifying parameters of core components (such as etcd, kube-apiserver, and docker) | The master node may be unavailable. | Restore the parameter settings to the recommended values. For details, see :ref:`Cluster Configuration Management `. | + +-----------------+-------------------------------------------------------------------------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------+ + | | Replacing the master or etcd certificate | The cluster may become unavailable. | This operation cannot be undone. | + +-----------------+-------------------------------------------------------------------------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------+ + | Worker node | Modifying the security group of a node in a cluster | The node may be unavailable. | Restore the security group by referring to :ref:`Creating a CCE Cluster ` and allow traffic from the security group to pass through. | + | | | | | + | | | .. note:: | | + | | | | | + | | | Naming rule of a worker node: *Cluster name*\ ``-``\ **cce-node**\ ``-``\ *Random number* | | + +-----------------+-------------------------------------------------------------------------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------+ + | | Deleting the node | The node will become unavailable. | This operation cannot be undone. | + +-----------------+-------------------------------------------------------------------------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------+ + | | Reinstalling the OS | Node components are deleted, and the node becomes unavailable. | Reset the node. For details, see :ref:`Resetting a Node `. | + +-----------------+-------------------------------------------------------------------------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------+ + | | Upgrading the node kernel | The node may be unavailable or the network may be abnormal. | For details, see :ref:`Resetting a Node `. | + | | | | | + | | | .. note:: | | + | | | | | + | | | Node running depends on the system kernel version. Do not use the **yum update** command to update or reinstall the operating system kernel of a node unless necessary. (Reinstalling the operating system kernel using the original image or other images is a risky operation.) | | + +-----------------+-------------------------------------------------------------------------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------+ + | | Changing the node IP address | The node will become unavailable. | Change the IP address back to the original one. | + +-----------------+-------------------------------------------------------------------------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------+ + | | Modifying parameters of core components (such as kubelet and kube-proxy) | The node may become unavailable, and components may be insecure if security-related configurations are modified. | Restore the parameter settings to the recommended values. For details, see :ref:`Configuring a Node Pool `. | + +-----------------+-------------------------------------------------------------------------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------+ + | | Modifying OS configuration | The node may be unavailable. | Restore the configuration items or reset the node. For details, see :ref:`Resetting a Node `. | + +-----------------+-------------------------------------------------------------------------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------+ + | | Deleting or modifying the **/opt/cloud/cce** and **/var/paas** directories, and delete the data disk. | The node will become unready. | You can reset the node. For details, see :ref:`Resetting a Node `. | + +-----------------+-------------------------------------------------------------------------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------+ + | | Modifying the node directory permission and the container directory permission | The permissions will be abnormal. | You are not advised to modify the permissions. Restore the permissions if they are modified. | + +-----------------+-------------------------------------------------------------------------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------+ + | | Formatting or partitioning system disks, Docker disks, and kubelet disks on nodes. | The node may be unavailable. | You can reset the node. For details, see :ref:`Resetting a Node `. | + +-----------------+-------------------------------------------------------------------------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------+ + | | Installing other software on nodes | This may cause exceptions on Kubernetes components installed on the node, and make the node unavailable. | Uninstall the software that has been installed and restore or reset the node. For details, see :ref:`Resetting a Node `. | + +-----------------+-------------------------------------------------------------------------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------+ + | | Modifying NetworkManager configurations | The node will become unavailable. | Reset the node. For details, see :ref:`Resetting a Node `. | + +-----------------+-------------------------------------------------------------------------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------+ + | | Delete system images such as **cfe-pause** from the node. | Containers cannot be created and system images cannot be pulled. | Copy the image from another normal node for restoration. | + +-----------------+-------------------------------------------------------------------------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------+ + +Networking and Load Balancing +----------------------------- + +.. table:: **Table 2** High-risk operations and solutions + + +-------------------------------------------------------------------------------------------------------------------+----------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------+ + | Operation | Impact | How to Avoid/Fix | + +===================================================================================================================+============================================================================+===================================================================================================================================================+ + | Changing the value of the kernel parameter **net.ipv4.ip_forward** to **0** | The network becomes inaccessible. | Change the value to **1**. | + +-------------------------------------------------------------------------------------------------------------------+----------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------+ + | Changing the value of the kernel parameter **net.ipv4.tcp_tw_recycle** to **1** | The NAT service becomes abnormal. | Change the value to **0**. | + +-------------------------------------------------------------------------------------------------------------------+----------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------+ + | Changing the value of the kernel parameter **net.ipv4.tcp_tw_reuse** to **1** | The network becomes abnormal. | Change the value to **0**. | + +-------------------------------------------------------------------------------------------------------------------+----------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------+ + | Not configuring the node security group to allow UDP packets to pass through port 53 of the container CIDR block | The DNS in the cluster cannot work properly. | Restore the security group by referring to :ref:`Creating a CCE Cluster ` and allow traffic from the security group to pass through. | + +-------------------------------------------------------------------------------------------------------------------+----------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------+ + | Creating a custom listener on the ELB console for the load balancer managed by CCE | The modified items are reset by CCE or the ingress is faulty. | Use the YAML file of the Service to automatically create a listener. | + +-------------------------------------------------------------------------------------------------------------------+----------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------+ + | Binding a user-defined backend on the ELB console to the load balancer managed by CCE. | | Do not manually bind any backend. | + +-------------------------------------------------------------------------------------------------------------------+----------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------+ + | Changing the ELB certificate on the ELB console for the load balancer managed by CCE. | | Use the YAML file of the ingress to automatically manage certificates. | + +-------------------------------------------------------------------------------------------------------------------+----------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------+ + | Changing the listener name on the ELB console for the ELB listener managed by CCE. | | Do not change the name of the ELB listener managed by CCE. | + +-------------------------------------------------------------------------------------------------------------------+----------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------+ + | Changing the description of load balancers, listeners, and forwarding policies managed by CCE on the ELB console. | | Do not modify the description of load balancers, listeners, or forwarding policies managed by CCE. | + +-------------------------------------------------------------------------------------------------------------------+----------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------+ + | Delete CRD resources of network-attachment-definitions of default-network. | The container network is disconnected, or the cluster fails to be deleted. | If the resources are deleted by mistake, use the correct configurations to create the default-network resources. | + +-------------------------------------------------------------------------------------------------------------------+----------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------+ + +Logs +---- + +.. table:: **Table 3** High-risk operations and solutions + + +------------------------------------------------------------------------------+--------------------------------+----------+ + | Operation | Impact | Solution | + +==============================================================================+================================+==========+ + | Deleting the **/tmp/ccs-log-collector/pos** directory on the host machine | Logs are collected repeatedly. | None | + +------------------------------------------------------------------------------+--------------------------------+----------+ + | Deleting the **/tmp/ccs-log-collector/buffer** directory of the host machine | Logs are lost. | None | + +------------------------------------------------------------------------------+--------------------------------+----------+ + +EVS Disks +--------- + +.. table:: **Table 4** High-risk operations and solutions + + +------------------------------------------------+----------------------------------------------------------------------------+-----------------------------------------------------------------+---------------------------------------------------------------------------+ + | Operation | Impact | Solution | Remarks | + +================================================+============================================================================+=================================================================+===========================================================================+ + | Manually unmounting an EVS disk on the console | An I/O error is reported when the pod data is being written into the disk. | Delete the mount path from the node and schedule the pod again. | The file in the pod records the location where files are to be collected. | + +------------------------------------------------+----------------------------------------------------------------------------+-----------------------------------------------------------------+---------------------------------------------------------------------------+ + | Unmounting the disk mount path on the node | Pod data is written into a local disk. | Remount the corresponding path to the pod. | The buffer contains log cache files to be consumed. | + +------------------------------------------------+----------------------------------------------------------------------------+-----------------------------------------------------------------+---------------------------------------------------------------------------+ + | Operating EVS disks on the node | Pod data is written into a local disk. | None | None | + +------------------------------------------------+----------------------------------------------------------------------------+-----------------------------------------------------------------+---------------------------------------------------------------------------+ diff --git a/umn/source/index.rst b/umn/source/index.rst index 5ab5adf..58ca636 100644 --- a/umn/source/index.rst +++ b/umn/source/index.rst @@ -5,10 +5,10 @@ Cloud Container Engine - User Guide .. toctree:: :maxdepth: 1 - what_is_cloud_container_engine - instruction + service_overview/index product_bulletin/index - obtaining_resource_permissions + getting_started/index + high-risk_operations_and_solutions clusters/index nodes/index node_pools/index @@ -18,13 +18,13 @@ Cloud Container Engine - User Guide monitoring_and_alarm/index logging/index namespaces/index - configuration_center/index + configmaps_and_secrets/index auto_scaling/index add-ons/index charts/index permissions_management/index cloud_trace_service_cts/index - storage_flexvolume/index + storage_management_flexvolume_deprecated/index reference/index best_practice/index migrating_data_from_cce_1.0_to_cce_2.0/index diff --git a/umn/source/instruction.rst b/umn/source/instruction.rst deleted file mode 100644 index 880b4c2..0000000 --- a/umn/source/instruction.rst +++ /dev/null @@ -1,67 +0,0 @@ -:original_name: cce_qs_0001.html - -.. _cce_qs_0001: - -Instruction -=========== - -This document provides instructions for getting started with the Cloud Container Engine (CCE). - -Procedure ---------- - -Complete the following tasks to get started with CCE. - - -.. figure:: /_static/images/en-us_image_0000001178352608.png - :alt: **Figure 1** Procedure for getting started with CCE - - **Figure 1** Procedure for getting started with CCE - -#. :ref:`Charts (Helm) `\ Authorize an IAM user to use CCE. - - The accounts have the permission to use CCE. However, IAM users created by the accounts do not have the permission. You need to manually assign the permission to IAM users. - -#. **Create a cluster.** - - For details on how to create a regular Kubernetes cluster, see `Creating a CCE Cluster `__. - -#. **Create a workload from images or a chart.** - - Select existing images/chart, or create new images/chart. - - - For details on how to create a workload from images, see :ref:`Workloads `. - - For details on how to create a workload from a chart, see `Charts (Helm) `__. - -#. **View workload status and logs. Upgrade, scale, and monitor the workload.** - - For details, see :ref:`Managing Workloads and Jobs `. - -FAQs ----- - -#. **Is CCE suitable for users who are not familiar with Kubernetes?** - - Yes. The CCE console is easy-to-use. - -#. **Is CCE suitable for users who have little experience in building images?** - - Yes. You can select images from **Third-party Images**, and **Shared Images** pages on the CCE console. The **My Images** page displays only the images created by you. For details, see :ref:`Workloads `. - -#. **How do I create a workload using CCE?** - - Create a cluster and then create a workload in the cluster. - -#. **How do I create a workload accessible to public networks?** - - CCE provides different types of Services for workload access in diverse scenarios. Currently, CCE provides two access types to expose a workload to public networks: NodePort and LoadBalancer. For details, see :ref:`Networking `. - -#. **How can I allow multiple workloads in the same cluster to access each other?** - - Select the access type ClusterIP, which allows workloads in the same cluster to use their cluster-internal domain names to access each other. - - Cluster-internal domain names are in the format of ..svc.cluster.local:. For example, nginx.default.svc.cluster.local:80. - - Example: - - Assume that workload A needs to access workload B in the same cluster. Then, you can create a :ref:`ClusterIP ` Service for workload B. After the ClusterIP Service is created, workload B is reachable at ..svc.cluster.local:. diff --git a/umn/source/logging/using_icagent_to_collect_container_logs.rst b/umn/source/logging/using_icagent_to_collect_container_logs.rst index 407b7a5..8f9814d 100644 --- a/umn/source/logging/using_icagent_to_collect_container_logs.rst +++ b/umn/source/logging/using_icagent_to_collect_container_logs.rst @@ -22,7 +22,7 @@ Using ICAgent to Collect Logs The following uses Nginx as an example. Log policies vary depending on workloads. - .. figure:: /_static/images/en-us_image_0000001199181298.png + .. figure:: /_static/images/en-us_image_0000001569022957.png :alt: **Figure 1** Adding a log policy **Figure 1** Adding a log policy @@ -173,7 +173,7 @@ The following shows how to use a hostPath volume. Compared with emptyDir, the ty .. table:: **Table 2** Parameter description +--------------------------------+-------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ - | Parameter | Explanation | Description | + | Parameter | Description | Description | +================================+=========================+=======================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================+ | extendPathMode | Extended host path | Extended host paths contain pod IDs or container names to distinguish different containers into which the host path is mounted. | | | | | @@ -238,4 +238,4 @@ You can also run the **kubectl logs** command to view the standard output of a c kubectl logs pod_name -c container_name -n namespace (one-off query) kubectl logs -f -n namespace (real-time query in tail -f mode) -.. |image1| image:: /_static/images/en-us_image_0000001206876656.png +.. |image1| image:: /_static/images/en-us_image_0000001569182673.png diff --git a/umn/source/migrating_data_from_cce_1.0_to_cce_2.0/migrating_clusters.rst b/umn/source/migrating_data_from_cce_1.0_to_cce_2.0/migrating_clusters.rst index 1e0d6d3..3c0ee2d 100644 --- a/umn/source/migrating_data_from_cce_1.0_to_cce_2.0/migrating_clusters.rst +++ b/umn/source/migrating_data_from_cce_1.0_to_cce_2.0/migrating_clusters.rst @@ -24,62 +24,62 @@ Procedure .. table:: **Table 1** Parameters for creating a cluster - +---------------------------+------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ - | Parameter in CCE 2.0 | Parameter in CCE 1.0 | Configuration | - +===========================+==========================================================================================+===================================================================================================================================================================================================================================================================================================================================================================================================+ - | \* Cluster Name | Name | Name of the cluster to be created. | - +---------------------------+------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ - | \*Version | This parameter does not exist in CCE 1.0. Retain the default value. | Cluster version, namely, corresponding Kubernetes baseline version. | - +---------------------------+------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ - | \*Management Scale | This parameter does not exist in CCE 1.0. Set this parameter based on your requirements. | Maximum number of nodes that can be managed by the cluster. | - +---------------------------+------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ - | \* High Availability | Cluster Type | - **Yes**: The cluster has three master nodes. The cluster is still available even when two master nodes are down. | - | | | - **No**: The cluster has only one master node. If the master node is down, the whole cluster becomes unavailable, but existing applications are not affected. | - +---------------------------+------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ - | \*VPC | VPCs created in CCE 1.0 can be used in CCE 2.0. | VPC where the new cluster is located. | - | | | | - | | | If no VPCs are available, click **Create a VPC**. | - +---------------------------+------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ - | \*Subnet | Subnets created in CCE 1.0 can be used in CCE 2.0. | Subnet in which the cluster will run. | - +---------------------------+------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ - | \*Network Model | This parameter does not exist in CCE 1.0. Set this parameter based on your requirements. | - **Tunnel network**: An independent container network constructed using VXLAN tunnels based on the underlying VPC network. This model is appropriate for typical scenarios. | - | | | - **VPC network**: The VPC routing mode is used to deeply integrate with the underlying network. This mode applies to high-performance scenarios where the number of nodes is limited by the VPC routing quota. Only one cluster using the VPC network model can be created in a single VPC. | - +---------------------------+------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ - | Container Network Segment | This parameter does not exist in CCE 1.0. Set this parameter based on your requirements. | Select a container network segment based on service requirements. Container instances will be assigned with IP addresses within the planned network segment. | - | | | | - | | | - If **Automatically select** is deselected, enter a CIDR block manually. If the selected CIDR block conflicts with a subnet CIDR block, the system prompts you to select another CIDR block. The recommended CIDR blocks are 10.0.0.0/12-19, 172.16.0.0/16-19, and 192.168.0.0/16-19. | - | | | | - | | | If different clusters share a container network segment, an IP address conflict will occur and access to the applications in the clusters may fail. | - | | | | - | | | - If **Automatically select** is selected, the system automatically assigns a CIDR block that does not conflict with any subnet CIDR block. | - | | | | - | | | The mask of the container CIDR block must be appropriate. It determines the number of available nodes in a cluster. A too small mask value will cause the cluster to soon fall short of nodes. After the mask is set, the estimated maximum number of containers supported by the current CIDR block will be displayed. | - +---------------------------+------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ - | Service Network Segment | This parameter does not exist in CCE 1.0. Set this parameter based on your requirements. | This parameter is left unspecified, by default. This parameter applies only to clusters of v1.11.7 and later versions. | - | | | | - | | | This parameter indicates a CIDR block of Kubernetes services. The mask of the service CIDR block must be appropriate. It determines the number of available nodes in a cluster. | - +---------------------------+------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ - | Open EIP | This parameter does not exist in CCE 1.0. Set this parameter based on your requirements. | A public IP address that is reachable from public networks. Select an EIP that has not been bound to any node. A cluster's EIP is preset in the cluster's certificate. Do no delete the EIP after the cluster has been created. Otherwise, two-way authentication will fail. | - | | | | - | | | - **Do no configure**: No EIP will be preset in the cluster certificate. | - | | | - **Configure now**: If no EIP is available for selection, create a new EIP. | - +---------------------------+------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ - | Authorization Mode | This parameter does not exist in CCE 1.0. Set this parameter based on your requirements. | By default, **RBAC** is selected. Read `Namespace Permissions (Kubernetes RBAC-based) `__ and select **I am aware of the above limitations and read the CCE Role Management Instructions**. | - | | | | - | | | After RBAC is enabled, users access resources in the cluster according to fine-grained permissions policies. | - +---------------------------+------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ - | Authentication Mode | This parameter does not exist in CCE 1.0. Set this parameter based on your requirements. | The authentication mechanism performs permission control on resources in a cluster. For example, you can grant user A to read and write applications in a namespace, while granting user B to only read resources in a cluster. For details about role-based permission control, see `Controlling Cluster Permissions `__. | - | | | | - | | | - By default, X.509 authentication instead of **Enhanced authentication** is enabled. X.509 is a standard defining the format of public key certificates. X.509 certificates are used in many Internet protocols. | - | | | | - | | | - If permission control on a cluster is required, select **Enhanced authentication** and then **Authenticating Proxy**. | - | | | | - | | | Click **Upload** next to **CA Root Certificate** to upload a valid certificate. Select the check box to confirm that the uploaded certificate is valid. | - | | | | - | | | If the certificate is invalid, the cluster cannot be created. The uploaded certificate file must be smaller than 1 MB and in .crt or .cer format. | - +---------------------------+------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ - | Cluster Description | Description | Description of the cluster. | - +---------------------------+------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + +---------------------------+------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | Parameter in CCE 2.0 | Parameter in CCE 1.0 | Configuration | + +===========================+==========================================================================================+=================================================================================================================================================================================================================================================================================================================================================================================================================+ + | \* Cluster Name | Name | Name of the cluster to be created. | + +---------------------------+------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | \*Version | This parameter does not exist in CCE 1.0. Retain the default value. | Cluster version, namely, corresponding Kubernetes baseline version. | + +---------------------------+------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | \*Management Scale | This parameter does not exist in CCE 1.0. Set this parameter based on your requirements. | Maximum number of nodes that can be managed by the cluster. | + +---------------------------+------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | \* High Availability | Cluster Type | - **Yes**: The cluster has three master nodes. The cluster is still available even when two master nodes are down. | + | | | - **No**: The cluster has only one master node. If the master node is down, the whole cluster becomes unavailable, but existing applications are not affected. | + +---------------------------+------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | \*VPC | VPCs created in CCE 1.0 can be used in CCE 2.0. | VPC where the new cluster is located. | + | | | | + | | | If no VPCs are available, click **Create a VPC**. | + +---------------------------+------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | \*Subnet | Subnets created in CCE 1.0 can be used in CCE 2.0. | Subnet in which the cluster will run. | + +---------------------------+------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | \*Network Model | This parameter does not exist in CCE 1.0. Set this parameter based on your requirements. | - **Tunnel network**: An independent container network constructed using VXLAN tunnels based on the underlying VPC network. This model is appropriate for typical scenarios. | + | | | - **VPC network**: The VPC routing mode is used to deeply integrate with the underlying network. This mode applies to high-performance scenarios where the number of nodes is limited by the VPC routing quota. Only one cluster using the VPC network model can be created in a single VPC. | + +---------------------------+------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | Container Network Segment | This parameter does not exist in CCE 1.0. Set this parameter based on your requirements. | Select a container network segment based on service requirements. Container instances will be assigned with IP addresses within the planned network segment. | + | | | | + | | | - If **Automatically select** is deselected, enter a CIDR block manually. If the selected CIDR block conflicts with a subnet CIDR block, the system prompts you to select another CIDR block. The recommended CIDR blocks are 10.0.0.0/12-19, 172.16.0.0/16-19, and 192.168.0.0/16-19. | + | | | | + | | | If different clusters share a container network segment, an IP address conflict will occur and access to the applications in the clusters may fail. | + | | | | + | | | - If **Automatically select** is selected, the system automatically assigns a CIDR block that does not conflict with any subnet CIDR block. | + | | | | + | | | The mask of the container CIDR block must be appropriate. It determines the number of available nodes in a cluster. A too small mask value will cause the cluster to soon fall short of nodes. After the mask is set, the estimated maximum number of containers supported by the current CIDR block will be displayed. | + +---------------------------+------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | Service Network Segment | This parameter does not exist in CCE 1.0. Set this parameter based on your requirements. | This parameter is left unspecified, by default. This parameter applies only to clusters of v1.11.7 and later versions. | + | | | | + | | | This parameter indicates a CIDR block of Kubernetes services. The mask of the service CIDR block must be appropriate. It determines the number of available nodes in a cluster. | + +---------------------------+------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | Open EIP | This parameter does not exist in CCE 1.0. Set this parameter based on your requirements. | A public IP address that is reachable from public networks. Select an EIP that has not been bound to any node. A cluster's EIP is preset in the cluster's certificate. Do no delete the EIP after the cluster has been created. Otherwise, two-way authentication will fail. | + | | | | + | | | - **Do no configure**: No EIP will be preset in the cluster certificate. | + | | | - **Configure now**: If no EIP is available for selection, create a new EIP. | + +---------------------------+------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | Authorization Mode | This parameter does not exist in CCE 1.0. Set this parameter based on your requirements. | By default, **RBAC** is selected. Read `Namespace Permissions (Kubernetes RBAC-based) `__ and select **I am aware of the above limitations and read the CCE Role Management Instructions**. | + | | | | + | | | After RBAC is enabled, users access resources in the cluster according to fine-grained permissions policies. | + +---------------------------+------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | Authentication Mode | This parameter does not exist in CCE 1.0. Set this parameter based on your requirements. | The authentication mechanism performs permission control on resources in a cluster. For example, you can grant user A to read and write applications in a namespace, while granting user B to only read resources in a cluster. For details about role-based permission control, see `Namespace Permissions (Kubernetes RBAC-based) `__. | + | | | | + | | | - By default, X.509 authentication instead of **Enhanced authentication** is enabled. X.509 is a standard defining the format of public key certificates. X.509 certificates are used in many Internet protocols. | + | | | | + | | | - If permission control on a cluster is required, select **Enhanced authentication** and then **Authenticating Proxy**. | + | | | | + | | | Click **Upload** next to **CA Root Certificate** to upload a valid certificate. Select the check box to confirm that the uploaded certificate is valid. | + | | | | + | | | If the certificate is invalid, the cluster cannot be created. The uploaded certificate file must be smaller than 1 MB and in .crt or .cer format. | + +---------------------------+------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | Cluster Description | Description | Description of the cluster. | + +---------------------------+------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ #. After the configuration is complete, click **Next** to add a node. @@ -111,7 +111,7 @@ Procedure +----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | OS | | Select an operating system for the node. | | | | | - | | | Reinstalling OSs or modifying OS configurations could make nodes unavailable. Exercise caution when performing these operations. For more information, see :ref:`Risky Operations on Cluster Nodes `. | + | | | Reinstalling OSs or modifying OS configurations could make nodes unavailable. Exercise caution when performing these operations. For more information, see :ref:`High-Risk Operations and Solutions `. | +----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | VPC | This parameter does not exist in CCE 1.0. Set this parameter based on your requirements. | The value cannot be changed. This parameter is supported only in v1.13.10-r0 and later versions of clusters. It is not displayed in versions earlier than v1.13.10-r0. | +----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ @@ -191,7 +191,7 @@ Procedure System resource add-ons must be installed. Advanced functional add-ons are optional. - You can also install optional add-ons after the cluster is created. To do so, choose **Add-ons** in the navigation pane of the CCE console and select the add-on you will install. For details, see `Add-ons `__. + You can also install optional add-ons after the cluster is created. To do so, choose **Add-ons** in the navigation pane of the CCE console and select the add-on you will install. For details, see `Add-ons `__. #. Click **Create Now**. Check all the configurations, and click **Submit**. diff --git a/umn/source/monitoring_and_alarm/custom_monitoring.rst b/umn/source/monitoring_and_alarm/custom_monitoring.rst index 73f6c3a..3be881b 100644 --- a/umn/source/monitoring_and_alarm/custom_monitoring.rst +++ b/umn/source/monitoring_and_alarm/custom_monitoring.rst @@ -198,5 +198,5 @@ You can see that Nginx has been accessed once. Log in to AOM. In the navigation pane, choose **Monitoring** > **Metric Monitoring**. You can view Nginx-related metrics, for example, **nginx_connections_active**. -.. |image1| image:: /_static/images/en-us_image_0000001199501262.png -.. |image2| image:: /_static/images/en-us_image_0000001243981177.png +.. |image1| image:: /_static/images/en-us_image_0000001517743384.png +.. |image2| image:: /_static/images/en-us_image_0000001568822693.png diff --git a/umn/source/namespaces/managing_namespaces.rst b/umn/source/namespaces/managing_namespaces.rst index 7346156..e4e1ec8 100644 --- a/umn/source/namespaces/managing_namespaces.rst +++ b/umn/source/namespaces/managing_namespaces.rst @@ -29,7 +29,7 @@ Isolating Namespaces The following figure shows namespaces created for the development, joint debugging, and testing environments, respectively. - .. figure:: /_static/images/en-us_image_0000001199021298.png + .. figure:: /_static/images/en-us_image_0000001569182513.png :alt: **Figure 1** One namespace for one environment **Figure 1** One namespace for one environment @@ -39,7 +39,7 @@ Isolating Namespaces You are advised to use this method if a large number of workloads are deployed in the same environment. For example, in the following figure, different namespaces (APP1 and APP2) are created to logically manage workloads as different groups. Workloads in the same namespace access each other using the Service name, and workloads in different namespaces access each other using the Service name or namespace name. - .. figure:: /_static/images/en-us_image_0000001243981147.png + .. figure:: /_static/images/en-us_image_0000001569022797.png :alt: **Figure 2** Grouping workloads into different namespaces **Figure 2** Grouping workloads into different namespaces diff --git a/umn/source/namespaces/setting_a_resource_quota.rst b/umn/source/namespaces/setting_a_resource_quota.rst index 7a030b5..47acdd1 100644 --- a/umn/source/namespaces/setting_a_resource_quota.rst +++ b/umn/source/namespaces/setting_a_resource_quota.rst @@ -27,7 +27,7 @@ Cluster Scale Recommended Number of Pods 2,000 nodes 50,000 pods ============= ========================== -Starting from clusters of v1.21 and later, the default `Resource Quotas `__ are created when a namespace is created if you have enabled **enable-resource-quota** in :ref:`Managing Cluster Components `. :ref:`Table 1 ` lists the resource quotas based on cluster specifications. You can modify them according to your service requirements. +Starting from clusters of v1.21 and later, the default `Resource Quotas `__ are created when a namespace is created if you have enabled **enable-resource-quota** in :ref:`Cluster Configuration Management `. :ref:`Table 1 ` lists the resource quotas based on cluster specifications. You can modify them according to your service requirements. .. _cce_10_0287__table371165714613: diff --git a/umn/source/networking/accessing_public_networks_from_a_container.rst b/umn/source/networking/accessing_public_networks_from_a_container.rst index 67560d5..4a58d98 100644 --- a/umn/source/networking/accessing_public_networks_from_a_container.rst +++ b/umn/source/networking/accessing_public_networks_from_a_container.rst @@ -11,11 +11,11 @@ Containers can access public networks in either of the following ways: - Bind a public IP address to the pod. (When the Cloud Native Network 2.0 model is used, manually bind an EIP to the ENI or sub-ENI of the pod on the VPC console. This method is not recommended because the IP address of a pod changes after the pod is rescheduled. As a result, the new pod cannot access the public network.) - Configure SNAT rules through NAT Gateway. -You can use NAT Gateway to enable container pods in a VPC to access public networks. NAT Gateway provides source network address translation (SNAT), which translates private IP addresses to a public IP address by binding an elastic IP address (EIP) to the gateway, providing secure and efficient access to the Internet. :ref:`Figure 1 ` shows the SNAT architecture. The SNAT function allows the container pods in a VPC to access the Internet without being bound to an EIP. SNAT supports a large number of concurrent connections, which makes it suitable for applications involving a large number of requests and connections. +You can use NAT Gateway to enable container pods in a VPC to access public networks. NAT Gateway provides source network address translation (SNAT), which translates private IP addresses to a public IP address by binding an elastic IP address (EIP) to the gateway, providing secure and efficient access to the Internet. :ref:`Figure 1 ` shows the SNAT architecture. The SNAT function allows the container pods in a VPC to access the Internet without being bound to an EIP. SNAT supports a large number of concurrent connections, which makes it suitable for applications involving a large number of requests and connections. -.. _cce_10_0400__cce_bestpractice_00274_0_en-us_topic_0241700138_en-us_topic_0144420145_fig34611314153619: +.. _cce_10_0400__cce_bestpractice_00274_en-us_topic_0241700138_en-us_topic_0144420145_fig34611314153619: -.. figure:: /_static/images/en-us_image_0000001192028618.png +.. figure:: /_static/images/en-us_image_0000001569182781.png :alt: **Figure 1** SNAT **Figure 1** SNAT @@ -65,9 +65,9 @@ To enable a container pod to access the Internet, perform the following steps: After the SNAT rule is configured, workloads can access public networks from the container. Public networks can be pinged from the container. -.. |image1| image:: /_static/images/en-us_image_0275445566.png -.. |image2| image:: /_static/images/en-us_image_0261818893.png -.. |image3| image:: /_static/images/en-us_image_0275445543.png -.. |image4| image:: /_static/images/en-us_image_0261818896.png -.. |image5| image:: /_static/images/en-us_image_0275452681.png -.. |image6| image:: /_static/images/en-us_image_0261818899.png +.. |image1| image:: /_static/images/en-us_image_0000001568822961.png +.. |image2| image:: /_static/images/en-us_image_0000001518062796.png +.. |image3| image:: /_static/images/en-us_image_0000001517743652.png +.. |image4| image:: /_static/images/en-us_image_0000001568902689.png +.. |image5| image:: /_static/images/en-us_image_0000001569023069.png +.. |image6| image:: /_static/images/en-us_image_0000001568822957.png diff --git a/umn/source/networking/container_network_models/cloud_native_network_2.0.rst b/umn/source/networking/container_network_models/cloud_native_network_2.0.rst index c24088f..0845f00 100644 --- a/umn/source/networking/container_network_models/cloud_native_network_2.0.rst +++ b/umn/source/networking/container_network_models/cloud_native_network_2.0.rst @@ -11,7 +11,7 @@ Model Definition Developed by CCE, Cloud Native Network 2.0 deeply integrates Elastic Network Interfaces (ENIs) and sub-ENIs of Virtual Private Cloud (VPC). Container IP addresses are allocated from the VPC CIDR block. ELB passthrough networking is supported to direct access requests to containers. Security groups and elastic IPs (EIPs) are bound to deliver high performance. -.. figure:: /_static/images/en-us_image_0000001199181336.png +.. figure:: /_static/images/en-us_image_0000001568822717.png :alt: **Figure 1** Cloud Native Network 2.0 **Figure 1** Cloud Native Network 2.0 @@ -57,7 +57,7 @@ In the Cloud Native Network 2.0 model, the container CIDR block and node CIDR bl In addition, a subnet can be added to the container CIDR block after a cluster is created to increase the number of available IP addresses. In this case, ensure that the added subnet does not conflict with other subnets in the container CIDR block. -.. figure:: /_static/images/en-us_image_0000001244261171.png +.. figure:: /_static/images/en-us_image_0000001569182549.png :alt: **Figure 2** Configuring CIDR blocks **Figure 2** Configuring CIDR blocks diff --git a/umn/source/networking/container_network_models/container_tunnel_network.rst b/umn/source/networking/container_network_models/container_tunnel_network.rst index 7767566..438af1f 100644 --- a/umn/source/networking/container_network_models/container_tunnel_network.rst +++ b/umn/source/networking/container_network_models/container_tunnel_network.rst @@ -11,7 +11,7 @@ Container Tunnel Network Model The container tunnel network is constructed on but independent of the node network through tunnel encapsulation. This network model uses VXLAN to encapsulate Ethernet packets into UDP packets and transmits them in tunnels. Open vSwitch serves as the backend virtual switch. Though at some costs of performance, packet encapsulation and tunnel transmission enable higher interoperability and compatibility with advanced features (such as network policy-based isolation) for most common scenarios. -.. figure:: /_static/images/en-us_image_0000001199341330.png +.. figure:: /_static/images/en-us_image_0000001518222740.png :alt: **Figure 1** Container tunnel network **Figure 1** Container tunnel network @@ -55,7 +55,7 @@ The container tunnel network allocates container IP addresses according to the f - Pods scheduled to a node are cyclically allocated IP addresses from one or more CIDR blocks allocated to the node. -.. figure:: /_static/images/en-us_image_0000001244141217.png +.. figure:: /_static/images/en-us_image_0000001569182773.png :alt: **Figure 2** IP address allocation of the container tunnel network **Figure 2** IP address allocation of the container tunnel network diff --git a/umn/source/networking/container_network_models/overview.rst b/umn/source/networking/container_network_models/overview.rst index 491b6a9..8f1bf08 100644 --- a/umn/source/networking/container_network_models/overview.rst +++ b/umn/source/networking/container_network_models/overview.rst @@ -7,7 +7,7 @@ Overview The container network assigns IP addresses to pods in a cluster and provides networking services. In CCE, you can select the following network models for your cluster: -- :ref:`Tunnel network ` +- :ref:`Container tunnel network ` - :ref:`VPC network ` - :ref:`Cloud Native Network 2.0 ` @@ -25,7 +25,7 @@ Network Model Comparison .. table:: **Table 1** Network model comparison +------------------------+-----------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------+ - | Dimension | Tunnel Network | VPC Network | Cloud Native Network 2.0 | + | Dimension | Container Tunnel Network | VPC Network | Cloud Native Network 2.0 | +========================+===================================================================================================================================+======================================================================================================================================================+============================================================================================================+ | Application scenarios | - Common container service scenarios | - Scenarios that have high requirements on network latency and bandwidth | - Scenarios that have high requirements on network latency, bandwidth, and performance | | | - Scenarios that do not have high requirements on network latency and bandwidth | - Containers can communicate with VMs using a microservice registration framework, such as Dubbo and CSE. | - Containers can communicate with VMs using a microservice registration framework, such as Dubbo and CSE. | diff --git a/umn/source/networking/container_network_models/vpc_network.rst b/umn/source/networking/container_network_models/vpc_network.rst index 6ee0769..a2ab121 100644 --- a/umn/source/networking/container_network_models/vpc_network.rst +++ b/umn/source/networking/container_network_models/vpc_network.rst @@ -11,7 +11,7 @@ Model Definition The VPC network uses VPC routing to integrate with the underlying network. This network model is suitable for performance-intensive scenarios. The maximum number of nodes allowed in a cluster depends on the VPC route quota. Each node is assigned a CIDR block of a fixed size. This networking model is free from tunnel encapsulation overhead and outperforms the container tunnel network model. In addition, as VPC routing includes routes to node IP addresses and the container CIDR block, container pods in a cluster can be directly accessed from outside the cluster. -.. figure:: /_static/images/en-us_image_0000001199181338.png +.. figure:: /_static/images/en-us_image_0000001568822773.png :alt: **Figure 1** VPC network model **Figure 1** VPC network model @@ -54,7 +54,7 @@ The VPC network allocates container IP addresses according to the following rule - Pods scheduled to a node are cyclically allocated IP addresses from CIDR blocks allocated to the node. -.. figure:: /_static/images/en-us_image_0000001244261173.png +.. figure:: /_static/images/en-us_image_0000001569022889.png :alt: **Figure 2** IP address management of the VPC network **Figure 2** IP address management of the VPC network diff --git a/umn/source/networking/dns/overview.rst b/umn/source/networking/dns/overview.rst index b3b0ea8..0e8c019 100644 --- a/umn/source/networking/dns/overview.rst +++ b/umn/source/networking/dns/overview.rst @@ -46,7 +46,7 @@ By default, after other pods are created, the address of the coredns Service is When a user accesses the *Service name:Port* of the Nginx pod, the IP address of the Nginx Service is resolved from CoreDNS, and then the IP address of the Nginx Service is accessed. In this way, the user can access the backend Nginx pod. -.. figure:: /_static/images/en-us_image_0000001244261167.png +.. figure:: /_static/images/en-us_image_0000001568822905.png :alt: **Figure 1** Example of domain name resolution in a cluster **Figure 1** Example of domain name resolution in a cluster diff --git a/umn/source/networking/dns/using_coredns_for_custom_domain_name_resolution.rst b/umn/source/networking/dns/using_coredns_for_custom_domain_name_resolution.rst index 4453ad2..6632e80 100644 --- a/umn/source/networking/dns/using_coredns_for_custom_domain_name_resolution.rst +++ b/umn/source/networking/dns/using_coredns_for_custom_domain_name_resolution.rst @@ -60,6 +60,10 @@ Assume that a cluster administrator has a Consul DNS server located at 10.150.0. You can also modify the ConfigMap as follows: +.. important:: + + The parameter values in red in the example can only be modified and cannot be deleted. + .. code-block:: $ kubectl edit configmap coredns -n kube-system diff --git a/umn/source/networking/ingresses/ingress_overview.rst b/umn/source/networking/ingresses/ingress_overview.rst index 11cc203..2cd2f45 100644 --- a/umn/source/networking/ingresses/ingress_overview.rst +++ b/umn/source/networking/ingresses/ingress_overview.rst @@ -14,7 +14,7 @@ An ingress is an independent resource in the Kubernetes cluster and defines rule .. _cce_10_0094__fig18155819416: -.. figure:: /_static/images/en-us_image_0000001243981115.png +.. figure:: /_static/images/en-us_image_0000001517903200.png :alt: **Figure 1** Ingress diagram **Figure 1** Ingress diagram @@ -37,7 +37,7 @@ ELB Ingress Controller is deployed on the master node and bound to the load bala .. _cce_10_0094__fig122542486129: -.. figure:: /_static/images/en-us_image_0000001199501200.png +.. figure:: /_static/images/en-us_image_0000001568822925.png :alt: **Figure 2** Working principle of ELB Ingress Controller **Figure 2** Working principle of ELB Ingress Controller diff --git a/umn/source/networking/ingresses/using_elb_ingresses_on_the_console.rst b/umn/source/networking/ingresses/using_elb_ingresses_on_the_console.rst index d05c1b6..1ccfbb5 100644 --- a/umn/source/networking/ingresses/using_elb_ingresses_on_the_console.rst +++ b/umn/source/networking/ingresses/using_elb_ingresses_on_the_console.rst @@ -40,7 +40,9 @@ This section uses an Nginx workload as an example to describe how to add an ELB Dedicated load balancers must support HTTP and the network type must support private networks. - - **Listener Configuration**: Ingress configures a listener for the load balancer, which listens to requests from the load balancer and distributes traffic. After the configuration is complete, a listener is created on the load balancer. The default listener name is *k8s___*, for example, *k8s_HTTP_80*. + - .. _cce_10_0251__li6851318392: + + **Listener**: Ingress configures a listener for the load balancer, which listens to requests from the load balancer and distributes traffic. After the configuration is complete, a listener is created on the load balancer. The default listener name is *k8s___*, for example, *k8s_HTTP_80*. - **Front-End Protocol**: **HTTP** and **HTTPS** are available. @@ -70,7 +72,13 @@ This section uses an Nginx workload as an example to describe how to add an ELB - **Security Policy** is available only when **HTTPS** is selected. - This function is supported only for clusters of v1.17.9 and later. - - **Forwarding Policies**: When the access address of a request matches the forwarding policy (a forwarding policy consists of a domain name and URL, for example, 10.117.117.117:80/helloworld), the request is forwarded to the corresponding target Service for processing. Click **Add Forwarding Policies** to add multiple forwarding policies. + - Backend protocol + + If the :ref:`listener ` uses HTTP, only **HTTP** can be selected. + + If the :ref:`listener ` uses HTTPS, you can select **HTTP** or **HTTPS**. + + - **Forwarding Policies**: When the access address of a request matches the forwarding policy (a forwarding policy consists of a domain name and URL, for example, 10.117.117.117:80/helloworld), the request is forwarded to the corresponding target Service for processing. Click |image1| to add multiple forwarding policies. - **Domain Name**: actual domain name. Ensure that the domain name has been registered and archived. Once a domain name rule is configured, you must use the domain name for access. @@ -101,11 +109,11 @@ This section uses an Nginx workload as an example to describe how to add an ELB .. note:: - **Weighted round robin**: Requests are forwarded to different servers based on their weights, which indicate server processing performance. Backend servers with higher weights receive proportionately more requests, whereas equal-weighted servers receive the same number of requests. This algorithm is often used for short connections, such as HTTP services. - - **Weighted least connections**: In addition to the weight assigned to each server, the number of connections processed by each backend server is also considered. Requests are forwarded to the server with the lowest connections-to-weight ratio. Building on **least connections**, the **weighted least connections** algorithm assigns a weight to each server based on their processing capability. This algorithm is often used for persistent connections, such as database connections. - - **Source IP hash**: The source IP address of each request is calculated using the hash algorithm to obtain a unique hash key, and all backend servers are numbered. The generated key allocates the client to a particular server. This enables requests from different clients to be distributed in load balancing mode and ensures that requests from the same client are forwarded to the same server. This algorithm applies to TCP connections without cookies. + - **Weighted least connections**: In addition to the weight assigned to each server, the number of connections processed by each backend server is also considered. Requests are forwarded to the server with the lowest connections-to-weight ratio. Building on **least connections**, the **weighted least connections** algorithm assigns a weight to each server based on their processing performance. This algorithm is often used for persistent connections, such as database connections. + - **Source IP hash**: The source IP address of each request is calculated using the hash algorithm to obtain a unique hash key, and all backend servers are numbered. The generated key allocates the client to a particular server. This allows requests from different clients to be routed based on source IP addresses and ensures that a client is directed to the same server as always. This algorithm applies to TCP connections without cookies. - **Type**: This function is disabled by default. You can select **Load balancer cookie**. - - **Health Check**: This function is disabled by default. The health check is for the load balancer. When TCP is selected during the :ref:`port settings `, you can choose either TCP or HTTP. Currently, UDP is not supported. By default, the service port (Node Port and container port of the Service) is used for health check. You can also specify another port for health check. After the port is specified, a service port named **cce-healthz** will be added for the Service. + - **Health Check**: configured for the load balancer. When TCP is selected during the :ref:`port settings `, you can choose either TCP or HTTP. Currently, UDP is not supported. By default, the service port (Node Port and container port of the Service) is used for health check. You can also specify another port for health check. After the port is specified, a service port named **cce-healthz** will be added for the Service. - **Operation**: Click **Delete** to delete the configuration. @@ -127,7 +135,9 @@ This section uses an Nginx workload as an example to describe how to add an ELB .. _cce_10_0251__fig17115192714367: - .. figure:: /_static/images/en-us_image_0000001199181230.png + .. figure:: /_static/images/en-us_image_0000001518062672.png :alt: **Figure 1** Accessing the /healthz interface of defaultbackend **Figure 1** Accessing the /healthz interface of defaultbackend + +.. |image1| image:: /_static/images/en-us_image_0000001568822825.png diff --git a/umn/source/networking/ingresses/using_kubectl_to_create_an_elb_ingress.rst b/umn/source/networking/ingresses/using_kubectl_to_create_an_elb_ingress.rst index fe30dc0..8ce7456 100644 --- a/umn/source/networking/ingresses/using_kubectl_to_create_an_elb_ingress.rst +++ b/umn/source/networking/ingresses/using_kubectl_to_create_an_elb_ingress.rst @@ -350,7 +350,7 @@ CCE allows you to connect to an existing load balancer when creating an ingress. - Existing dedicated load balancers must be the application type (HTTP/HTTPS) supporting private networks (with a private IP). -**If the cluster version is 1.23 or earlier, the YAML file configuration is as follows:** +**If the cluster version is 1.23 or later, the YAML file configuration is as follows:** .. code-block:: @@ -378,7 +378,7 @@ CCE allows you to connect to an existing load balancer when creating an ingress. pathType: ImplementationSpecific ingressClassName: cce -**If the cluster version is 1.21 or later, the YAML file configuration is as follows:** +**If the cluster version is 1.21 or earlier, the YAML file configuration is as follows:** .. code-block:: @@ -848,4 +848,52 @@ Ingresses can route requests to multiple backend Services based on different mat property: ingress.beta.kubernetes.io/url-match-mode: STARTS_WITH -.. |image1| image:: /_static/images/en-us_image_0000001276433425.png +Interconnecting with HTTPS Backend Services +------------------------------------------- + +Ingress can interconnect with backend services of different protocols. By default, the backend proxy channel of an ingress is an HTTP channel. To create an HTTPS channel, add the following configuration to the **annotations** field: + +.. code-block:: text + + kubernetes.io/elb.pool-protocol: https + +.. important:: + + - This feature only applies to clusters of v1.23.8, v1.25.3, and later. + - Ingress can interconnect with HTTPS backend services only when dedicated load balancers are used. + - When interconnecting with HTTPS backend services, set **Client Protocol** of ingress to **HTTPS**. + +An ingress configuration example is as follows: + +.. code-block:: + + apiVersion: networking.k8s.io/v1 + kind: Ingress + metadata: + name: ingress-test + namespace: default + annotations: + kubernetes.io/elb.port: '443' + kubernetes.io/elb.id: # In this example, an existing dedicated load balancer is used. Replace its ID with the ID of your dedicated load balancer. + kubernetes.io/elb.class: performance + kubernetes.io/elb.pool-protocol: https # Interconnected HTTPS backend service + kubernetes.io/elb.tls-ciphers-policy: tls-1-2 + spec: + tls: + - secretName: ingress-test-secret + rules: + - host: '' + http: + paths: + - path: '/' + backend: + service: + name: # Replace it with the name of your target Service. + port: + number: 80 + property: + ingress.beta.kubernetes.io/url-match-mode: STARTS_WITH + pathType: ImplementationSpecific + ingressClassName: cce + +.. |image1| image:: /_static/images/en-us_image_0000001569022977.png diff --git a/umn/source/networking/network_policies.rst b/umn/source/networking/network_policies.rst index 231d442..c31529a 100644 --- a/umn/source/networking/network_policies.rst +++ b/umn/source/networking/network_policies.rst @@ -5,9 +5,7 @@ Network Policies ================ -NetworkPolicy is a Kubernetes object used to restrict pod access. In CCE, by setting network policies, you can define ingress rules specifying the addresses to access pods or egress rules specifying the addresses pods can access. This is equivalent to setting up a firewall at the application layer to further ensure network security. - -Network policies depend on the networking add-on of the cluster to which the policies apply. +Network policies are designed by Kubernetes to restrict pod access. It is equivalent to a firewall at the application layer to enhance network security. The capabilities supported by network policies depend on the capabilities of the network add-ons of the cluster. By default, if a namespace does not have any policy, pods in the namespace accept traffic from any source and send traffic to any destination. @@ -20,18 +18,35 @@ Network policy rules are classified into the following types: Notes and Constraints --------------------- -- Only clusters that use the tunnel network model support network policies. +- Only clusters that use the tunnel network model support network policies. Network policies are classified into the following types: + + - Ingress: All versions support this type. + + - Egress: Only clusters of v1.23 or later support egress rules. + + Egress rules are supported only in the following OSs: + + +-----------------------------------+-------------------------------------------+ + | OS | Verified Kernel Version | + +===================================+===========================================+ + | CentOS | 3.10.0-1062.18.1.el7.x86_64 | + | | | + | | 3.10.0-1127.19.1.el7.x86_64 | + | | | + | | 3.10.0-1160.25.1.el7.x86_64 | + | | | + | | 3.10.0-1160.76.1.el7.x86_64 | + +-----------------------------------+-------------------------------------------+ + | EulerOS 2.5 | 3.10.0-862.14.1.5.h591.eulerosv2r7.x86_64 | + | | | + | | 3.10.0-862.14.1.5.h687.eulerosv2r7.x86_64 | + +-----------------------------------+-------------------------------------------+ + | EulerOS 2.9 | 4.18.0-147.5.1.6.h541.eulerosv2r9.x86_64 | + | | | + | | 4.18.0-147.5.1.6.h766.eulerosv2r9.x86_64 | + +-----------------------------------+-------------------------------------------+ - Network isolation is not supported for IPv6 addresses. - -- Network policies do not support egress rules except for clusters of v1.23 or later. - - Egress rules are supported only in the following operating systems: - - - EulerOS 2.9: kernel version 4.18.0-147.5.1.6.h541.eulerosv2r9.x86_64 - - CentOS 7.7: kernel version 3.10.0-1062.18.1.el7.x86_64 - - EulerOS 2.5: kernel version 3.10.0-862.14.1.5.h591.eulerosv2r7.x86_64 - - If a cluster is upgraded to v1.23 in in-place mode, you cannot use egress rules because the node OS is not upgraded. In this case, reset the node. Using Ingress Rules @@ -52,17 +67,17 @@ Using Ingress Rules role: db ingress: #This is an ingress rule. - from: - - podSelector: #Only traffic from the pods with the role=frontend label is allowed. + - podSelector: #Only traffic from the pods with the "role=frontend" label is allowed. matchLabels: role: frontend ports: #Only TCP can be used to access port 6379. - protocol: TCP port: 6379 - Diagram: + See the following figure. - .. figure:: /_static/images/en-us_image_0259557735.png + .. figure:: /_static/images/en-us_image_0000001518062636.png :alt: **Figure 1** podSelector **Figure 1** podSelector @@ -88,11 +103,10 @@ Using Ingress Rules - protocol: TCP port: 6379 - :ref:`Figure 2 ` shows how namespaceSelector selects ingress sources. + See the following figure. - .. _cce_10_0059__en-us_topic_0249851123_fig127351855617: - .. figure:: /_static/images/en-us_image_0259558489.png + .. figure:: /_static/images/en-us_image_0000001518222592.png :alt: **Figure 2** namespaceSelector **Figure 2** namespaceSelector @@ -126,10 +140,10 @@ Egress supports not only podSelector and namespaceSelector, but also ipBlock. except: - 172.16.0.40/32 # This CIDR block cannot be accessed. This value must fall within the range specified by cidr. -Diagram: +The following figure shows how to use ingress and egress together. -.. figure:: /_static/images/en-us_image_0000001340138373.png +.. figure:: /_static/images/en-us_image_0000001517743496.png :alt: **Figure 3** ipBlock **Figure 3** ipBlock @@ -164,10 +178,10 @@ You can define ingress and egress in the same rule. matchLabels: role: web -Diagram: +The following figure shows how to use ingress and egress together. -.. figure:: /_static/images/en-us_image_0000001287883210.png +.. figure:: /_static/images/en-us_image_0000001568902533.png :alt: **Figure 4** Using both ingress and egress **Figure 4** Using both ingress and egress @@ -192,15 +206,15 @@ Creating a Network Policy on the Console .. table:: **Table 1** Adding an inbound rule - +------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------+ - | Parameter | Description | - +==================+==============================================================================================================================================================+ - | Protocol & Port | Select the protocol type and port. Currently, TCP and UDP are supported. | - +------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------+ - | Source Namespace | Select a namespace whose objects can be accessed. If this parameter is not specified, the source object belongs to the same namespace as the current policy. | - +------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------+ - | Source Pod Label | Allow access to the pods with this label, if not specified, all pods in the namespace can be accessed. | - +------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------+ + +------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------+ + | Parameter | Description | + +==================+=======================================================================================================================================================+ + | Protocol & Port | Select the protocol type and port. Currently, TCP and UDP are supported. | + +------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------+ + | Source Namespace | Select a namespace whose objects can be accessed. If this parameter is not specified, the object belongs to the same namespace as the current policy. | + +------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------+ + | Source Pod Label | Allow accessing the pods with this label. If this parameter is not specified, all pods in the namespace can be accessed. | + +------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------+ - **Outbound Rule**: Click |image3| to add an outbound rule. For details about parameter settings, see :ref:`Table 1 `. @@ -215,14 +229,14 @@ Creating a Network Policy on the Console +------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Destination CIDR Block | Allows requests to be routed to a specified CIDR block (and not to the exception CIDR blocks). Separate the destination and exception CIDR blocks by vertical bars (|), and separate multiple exception CIDR blocks by commas (,). For example, 172.17.0.0/16|172.17.1.0/24,172.17.2.0/24 indicates that 172.17.0.0/16 is accessible, but not for 172.17.1.0/24 or 172.17.2.0/24. | +------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ - | Destination Namespace | Select a namespace whose objects can be accessed. If this parameter is not specified, the source object belongs to the same namespace as the current policy. | + | Destination Namespace | Select a namespace whose objects can be accessed. If this parameter is not specified, the object belongs to the same namespace as the current policy. | +------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ - | Destination Pod Label | Allow access to the pods with this label, if not specified, all pods in the namespace can be accessed. | + | Destination Pod Label | Allow accessing the pods with this label. If this parameter is not specified, all pods in the namespace can be accessed. | +------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ #. Click **OK**. -.. |image1| image:: /_static/images/en-us_image_0000001251716033.png -.. |image2| image:: /_static/images/en-us_image_0000001533585325.png -.. |image3| image:: /_static/images/en-us_image_0000001533586881.png -.. |image4| image:: /_static/images/en-us_image_0000001482546084.png +.. |image1| image:: /_static/images/en-us_image_0000001568822793.png +.. |image2| image:: /_static/images/en-us_image_0000001569022905.png +.. |image3| image:: /_static/images/en-us_image_0000001517903064.png +.. |image4| image:: /_static/images/en-us_image_0000001517903068.png diff --git a/umn/source/networking/overview.rst b/umn/source/networking/overview.rst index 2211858..e7a7cf2 100644 --- a/umn/source/networking/overview.rst +++ b/umn/source/networking/overview.rst @@ -47,7 +47,7 @@ Service A Service is used for pod access. With a fixed IP address, a Service forwards access traffic to pods and performs load balancing for these pods. -.. figure:: /_static/images/en-us_image_0258889981.png +.. figure:: /_static/images/en-us_image_0000001517743432.png :alt: **Figure 1** Accessing pods through a Service **Figure 1** Accessing pods through a Service @@ -68,10 +68,10 @@ Ingress Services forward requests using layer-4 TCP and UDP protocols. Ingresses forward requests using layer-7 HTTP and HTTPS protocols. Domain names and paths can be used to achieve finer granularities. -.. figure:: /_static/images/en-us_image_0258961458.png - :alt: **Figure 2** Ingress and Service +.. figure:: /_static/images/en-us_image_0000001517903016.png + :alt: **Figure 2** Ingress-Service - **Figure 2** Ingress and Service + **Figure 2** Ingress-Service For details about the ingress, see :ref:`Ingress Overview `. @@ -86,17 +86,17 @@ Workload access scenarios can be categorized as follows: - Access from outside a cluster: A Service (NodePort or LoadBalancer type) or an ingress is recommended for a workload outside a cluster to access workloads in the cluster. - Access through the internet requires an EIP to be bound the node or load balancer. - - Access through an intranet uses only the intranet IP address of the node or load balancer. If workloads are located in different VPCs, a peering connection is required to enable communication between different VPCs. + - Access through the intranet requires an internal IP address to be bound the node or load balancer. If workloads are located in different VPCs, a peering connection is required to enable communication between different VPCs. -- External access initiated by a workload: +- The workload accesses the external network. - Accessing an intranet: The workload accesses the intranet address, but the implementation method varies depending on container network models. Ensure that the peer security group allows the access requests from the container CIDR block. - Accessing a public network: You need to assign an EIP to the node where the workload runs (when the VPC network or tunnel network model is used), bind an EIP to the pod IP address (when the Cloud Native Network 2.0 model is used), or configure SNAT rules through the NAT gateway. For details, see :ref:`Accessing Public Networks from a Container `. -.. figure:: /_static/images/en-us_image_0000001244261169.png +.. figure:: /_static/images/en-us_image_0000001568822741.png :alt: **Figure 3** Network access diagram **Figure 3** Network access diagram -.. |image1| image:: /_static/images/en-us_image_0000001199181334.png +.. |image1| image:: /_static/images/en-us_image_0000001518222536.png diff --git a/umn/source/networking/services/configuring_health_check_for_multiple_ports.rst b/umn/source/networking/services/configuring_health_check_for_multiple_ports.rst new file mode 100644 index 0000000..914eac4 --- /dev/null +++ b/umn/source/networking/services/configuring_health_check_for_multiple_ports.rst @@ -0,0 +1,99 @@ +:original_name: cce_10_0684.html + +.. _cce_10_0684: + +Configuring Health Check for Multiple Ports +=========================================== + +The annotation field related to the health check of the LoadBalancer Service is upgraded from **Kubernetes.io/elb.health-check-option** to **Kubernetes.io/elb.health-check-options**. Each Service port can be configured separately, and you can configure only some ports. If the port protocol does not need to be configured separately, the original annotation field is still available and does not need to be modified. + +Constraints +----------- + +- This feature takes effect only in the following versions: + + - v1.19: v1.19.16-r5 or later + - v1.21: v1.21.8-r0 or later + - v1.23: v1.23.6-r0 or later + - v1.25: v1.25.2-r0 or later + +- **kubernetes.io/elb.health-check-option** and **kubernetes.io/elb.health-check-options** cannot be configured at the same time. +- The **target_service_port** field is mandatory and must be unique. +- For a TCP port, the health check protocol can only be TCP or HTTP. For a UDP port, the health check protocol must be UDP. + +Procedure +--------- + +The following is an example of using the **kubernetes.io/elb.health-check-options** annotation: + +.. code-block:: + + apiVersion: v1 + kind: Service + metadata: + name: nginx + namespace: default + labels: {} + annotations: + kubernetes.io/elb.class: union + kubernetes.io/elb.id: 038ffbda-bd3a-48bb-8b8c-a8582601fd97 + kubernetes.io/elb.lb-algorithm: ROUND_ROBIN + kubernetes.io/elb.health-check-flag: 'on' + kubernetes.io/elb.health-check-options: '{ + "target_service_port": "TCP:80", // (Mandatory) Port for health check specified by spec.ports. The value consists of the protocol and port number, for example, TCP:80. + "monitor_port": "", // (Optional) Re-specified port for health check. If this parameter is not specified, the service port is used by default. Ensure that the port is in the listening state on the node where the pod is located. Otherwise, the health check result will be affected. + "protocol":"TCP", + "delay":"5", + "timeout":"10", + "max_retries":"3", + "path":"/" + }' + spec: + selector: {} + externalTrafficPolicy: Cluster + ports: + - name: cce-service-0 + targetPort: 80 + nodePort: 0 + port: 80 + protocol: TCP + type: LoadBalancer + loadBalancerIP: **.**.**.** + +.. table:: **Table 1** Data structure description of the **elb.health-check-options** field + + +---------------------+-----------------+-----------------+----------------------------------------------------------------------------------------------------------------------------------------------+ + | Parameter | Mandatory | Type | Description | + +=====================+=================+=================+==============================================================================================================================================+ + | target_service_port | Yes | String | Port for health check specified by spec.ports. The value consists of the protocol and port number, for example, TCP:80. | + +---------------------+-----------------+-----------------+----------------------------------------------------------------------------------------------------------------------------------------------+ + | monitor_port | No | String | Re-specified port for health check. If this parameter is not specified, the service port is used by default. | + | | | | | + | | | | .. note:: | + | | | | | + | | | | Ensure that the port is in the listening state on the node where the pod is located. Otherwise, the health check result will be affected. | + +---------------------+-----------------+-----------------+----------------------------------------------------------------------------------------------------------------------------------------------+ + | delay | No | String | Initial waiting time (in seconds) for starting the health check. | + | | | | | + | | | | Value range: 1 to 50. Default value: **5** | + +---------------------+-----------------+-----------------+----------------------------------------------------------------------------------------------------------------------------------------------+ + | timeout | No | String | Health check timeout, in seconds. | + | | | | | + | | | | Value range: 1 to 50. Default value: **10** | + +---------------------+-----------------+-----------------+----------------------------------------------------------------------------------------------------------------------------------------------+ + | max_retries | No | String | Maximum number of health check retries. | + | | | | | + | | | | Value range: 1 to 10. Default value: **3** | + +---------------------+-----------------+-----------------+----------------------------------------------------------------------------------------------------------------------------------------------+ + | protocol | No | String | Health check protocol. | + | | | | | + | | | | Default value: protocol of the associated Service | + | | | | | + | | | | Value options: TCP, UDP, or HTTP | + +---------------------+-----------------+-----------------+----------------------------------------------------------------------------------------------------------------------------------------------+ + | path | No | String | Health check URL. This parameter needs to be configured when the protocol is HTTP. | + | | | | | + | | | | Default value: **/** | + | | | | | + | | | | The value can contain 1 to 10,000 characters. | + +---------------------+-----------------+-----------------+----------------------------------------------------------------------------------------------------------------------------------------------+ diff --git a/umn/source/networking/services/index.rst b/umn/source/networking/services/index.rst index 70d3e66..590a08b 100644 --- a/umn/source/networking/services/index.rst +++ b/umn/source/networking/services/index.rst @@ -11,6 +11,7 @@ Services - :ref:`LoadBalancer ` - :ref:`Headless Service ` - :ref:`Service Annotations ` +- :ref:`Configuring Health Check for Multiple Ports ` .. toctree:: :maxdepth: 1 @@ -22,3 +23,4 @@ Services loadbalancer headless_service service_annotations + configuring_health_check_for_multiple_ports diff --git a/umn/source/networking/services/intra-cluster_access_clusterip.rst b/umn/source/networking/services/intra-cluster_access_clusterip.rst index 38ff599..264409b 100644 --- a/umn/source/networking/services/intra-cluster_access_clusterip.rst +++ b/umn/source/networking/services/intra-cluster_access_clusterip.rst @@ -16,7 +16,7 @@ The cluster-internal domain name format is **.\ *`, you can choose either TCP or HTTP. When UDP is selected during the :ref:`port settings `, only UDP is supported.. By default, the service port (Node Port and container port of the Service) is used for health check. You can also specify another port for health check. After the port is specified, a service port named **cce-healthz** will be added for the Service. + - **Health Check**: configured for the load balancer. When TCP is selected during the :ref:`port settings `, you can choose either TCP or HTTP. When UDP is selected during the :ref:`port settings `, only UDP is supported.. By default, the service port (Node Port and container port of the Service) is used for health check. You can also specify another port for health check. After the port is specified, a service port named **cce-healthz** will be added for the Service. - .. _cce_10_0014__li388800117144: @@ -310,7 +310,7 @@ You can set the access type when creating a workload using kubectl. This section The Nginx is accessible. - .. figure:: /_static/images/en-us_image_0000001243981181.png + .. figure:: /_static/images/en-us_image_0000001569182677.png :alt: **Figure 3** Accessing Nginx through the LoadBalancer Service **Figure 3** Accessing Nginx through the LoadBalancer Service @@ -599,7 +599,7 @@ You can add a Service when creating a workload using kubectl. This section uses The Nginx is accessible. - .. figure:: /_static/images/en-us_image_0000001199021334.png + .. figure:: /_static/images/en-us_image_0000001517743552.png :alt: **Figure 4** Accessing Nginx through the LoadBalancer Service **Figure 4** Accessing Nginx through the LoadBalancer Service @@ -631,7 +631,7 @@ This is because when the LoadBalancer Service is created, kube-proxy adds the EL When the value of **externalTrafficPolicy** is **Local**, the situation varies according to the container network model and service forwarding mode. The details are as follows: +---------------------------------------------------------------------------+-----------------------------+---------------------------------------------------------------------+-------------------------------------------------------+------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------+ -| Server | Client | Tunnel Network Cluster (IPVS) | VPC Network Cluster (IPVS) | Tunnel Network Cluster (iptables) | VPC Network Cluster (iptables) | +| Server | Client | Container Tunnel Network Cluster (IPVS) | VPC Network Cluster (IPVS) | Container Tunnel Network Cluster (iptables) | VPC Network Cluster (iptables) | +---------------------------------------------------------------------------+-----------------------------+---------------------------------------------------------------------+-------------------------------------------------------+------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------+ | NodePort Service | Same node | OK. The node where the pod runs is accessible, not any other nodes. | OK. The node where the pod runs is accessible. | OK. The node where the pod runs is accessible. | OK. The node where the pod runs is accessible. | +---------------------------------------------------------------------------+-----------------------------+---------------------------------------------------------------------+-------------------------------------------------------+------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------+ diff --git a/umn/source/networking/services/nodeport.rst b/umn/source/networking/services/nodeport.rst index f952ae7..2561bf8 100644 --- a/umn/source/networking/services/nodeport.rst +++ b/umn/source/networking/services/nodeport.rst @@ -11,7 +11,7 @@ Scenario A Service is exposed on each node's IP address at a static port (NodePort). A ClusterIP Service, to which the NodePort Service will route, is automatically created. By requesting :, you can access a NodePort Service from outside the cluster. -.. figure:: /_static/images/en-us_image_0000001199501230.png +.. figure:: /_static/images/en-us_image_0000001517743380.png :alt: **Figure 1** NodePort access **Figure 1** NodePort access diff --git a/umn/source/networking/services/service_overview.rst b/umn/source/networking/services/service_overview.rst index 8d87e99..ba2cbdb 100644 --- a/umn/source/networking/services/service_overview.rst +++ b/umn/source/networking/services/service_overview.rst @@ -18,7 +18,7 @@ For example, an application uses Deployments to create the frontend and backend. .. _cce_10_0249__en-us_topic_0249851121_fig2173165051811: -.. figure:: /_static/images/en-us_image_0258894622.png +.. figure:: /_static/images/en-us_image_0000001517743624.png :alt: **Figure 1** Inter-pod access **Figure 1** Inter-pod access @@ -32,7 +32,7 @@ In the preceding example, a Service is added for the frontend pod to access the .. _cce_10_0249__en-us_topic_0249851121_fig163156154816: -.. figure:: /_static/images/en-us_image_0258889981.png +.. figure:: /_static/images/en-us_image_0000001517743432.png :alt: **Figure 2** Accessing pods through a Service **Figure 2** Accessing pods through a Service diff --git a/umn/source/node_pools/creating_a_node_pool.rst b/umn/source/node_pools/creating_a_node_pool.rst index 73ede10..82f34aa 100644 --- a/umn/source/node_pools/creating_a_node_pool.rst +++ b/umn/source/node_pools/creating_a_node_pool.rst @@ -90,15 +90,20 @@ Procedure | | | | | An AZ is a physical region where resources use independent power supply and networks. AZs are physically isolated but interconnected through an internal network. To enhance workload availability, create nodes in different AZs. | +-----------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ - | Node Type | For a CCE cluster, **ECS** and **BMS** are supported. | + | Node Type | CCE cluster: | | | | - | | CCE Turbo clusters support ECSs of the VM and physical types. | - +-----------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ - | Container Engine | CCE clusters support Docker. Starting from CCE 1.23, containerd is supported. | + | | - ECS (VM): Containers run on ECSs. | | | | - | | For a CCE Turbo cluster, both **Docker** and **containerd** are supported. For details, see :ref:`Mapping between Node OSs and Container Engines `. | + | | CCE Turbo cluster: | + | | | + | | - ECS (VM): Containers run on ECSs. Only Trunkport ECSs (models that can be bound with multiple elastic network interfaces (ENIs)) are supported. | +-----------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ - | Specifications | Select node specifications that best fit your business needs. | + | Container Engine | CCE clusters support Docker and containerd in some scenarios. | + | | | + | | - VPC network clusters of v1.23 and later versions support containerd. Container tunnel network clusters of v1.23.2-r0 and later versions support containerd. | + | | - For a CCE Turbo cluster, both **Docker** and **containerd** are supported. For details, see :ref:`Mapping between Node OSs and Container Engines `. | + +-----------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | Specifications | Select a node specification based on service requirements. The available node specifications vary depending on regions or AZs. For details, see the CCE console. | +-----------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | OS | Select an OS type. Different types of nodes support different OSs. For details, see :ref:`Supported Node Specifications `. | | | | @@ -110,14 +115,14 @@ Procedure | | | | | Select the key pair used to log in to the node. You can select a shared key. | | | | - | | A key pair is used for identity authentication when you remotely log in to a node. If no key pair is available, click **Create Key Pair**. | + | | A key pair is used for identity authentication when you remotely log in to a node. If no key pair is available, click **Create Key Pair**.. | +-----------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ **Storage Settings** Configure storage resources on a node for the containers running on it. Set the disk size according to site requirements. - .. table:: **Table 3** Configuration parameters + .. table:: **Table 3** Parameters for storage settings +-----------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Parameter | Description | @@ -129,9 +134,12 @@ Procedure | | - **Encryption** is not selected by default. | | | - After you select **Encryption**, you can select an existing key in the displayed dialog box. If no key is available, click **View Key List** to create a key. After the key is created, click the refresh icon. | +-----------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ - | Data Disk | Data disk used by the container runtime and kubelet on the node. | + | Data Disk | **At least one data disk is required** for the container runtime and kubelet. **The data disk cannot be deleted or uninstalled. Otherwise, the node will be unavailable.** | | | | - | | **At least one data disk is required** for the container runtime and kubelet. **The data disk cannot be deleted or uninstalled. Otherwise, the node will be unavailable.** | + | | - First data disk: used for container runtime and kubelet components. The value ranges from 20 GB to 32,768 GB. The default value is 100 GB. | + | | - Other data disks: You can set the data disk size to a value ranging from 10 GB to 32,768 GB. The default value is 100 GB. | + | | | + | | **Advanced Settings** | | | | | | Click **Expand** to set the following parameters: | | | | @@ -184,7 +192,7 @@ Procedure +-----------------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Parameter | Description | +===================================+================================================================================================================================================================================================================================================================+ - | Kubernetes Label | Click **Add Label** to set the key-value pair attached to the Kubernetes objects (such as pods). A maximum of 20 labels can be added. | + | Kubernetes Label | Click **Add** to set the key-value pair attached to the Kubernetes objects (such as pods). A maximum of 20 labels can be added. | | | | | | Labels can be used to distinguish nodes. With workload affinity settings, container pods can be scheduled to a specified node. For more information, see `Labels and Selectors `__. | +-----------------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ @@ -196,7 +204,7 @@ Procedure +-----------------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Taint | This parameter is left blank by default. You can add taints to set anti-affinity for the node. A maximum of 10 taints are allowed for each node. Each taint contains the following parameters: | | | | - | | - **Key**: A key must contain 1 to 63 characters, starting with a letter or digit. Only letters, digits, hyphens (-), underscores (_), and periods (.) are allowed. A DNS subdomain name can be used as the prefix of a key. | + | | - **Key**: A key must contain 1 to 63 characters starting with a letter or digit. Only letters, digits, hyphens (-), underscores (_), and periods (.) are allowed. A DNS subdomain name can be used as the prefix of a key. | | | - **Value**: A value must start with a letter or digit and can contain a maximum of 63 characters, including letters, digits, hyphens (-), underscores (_), and periods (.). | | | - **Effect**: Available options are **NoSchedule**, **PreferNoSchedule**, and **NoExecute**. | | | | @@ -235,4 +243,4 @@ Procedure #. Click **Submit**. -.. |image1| image:: /_static/images/en-us_image_0000001201381906.png +.. |image1| image:: /_static/images/en-us_image_0000001518222604.png diff --git a/umn/source/node_pools/index.rst b/umn/source/node_pools/index.rst index 63112c2..0456a5e 100644 --- a/umn/source/node_pools/index.rst +++ b/umn/source/node_pools/index.rst @@ -15,4 +15,4 @@ Node Pools node_pool_overview creating_a_node_pool - managing_a_node_pool + managing_a_node_pool/index diff --git a/umn/source/node_pools/managing_a_node_pool/configuring_a_node_pool.rst b/umn/source/node_pools/managing_a_node_pool/configuring_a_node_pool.rst new file mode 100644 index 0000000..b011cf4 --- /dev/null +++ b/umn/source/node_pools/managing_a_node_pool/configuring_a_node_pool.rst @@ -0,0 +1,145 @@ +:original_name: cce_10_0652.html + +.. _cce_10_0652: + +Configuring a Node Pool +======================= + +Notes and Constraints +--------------------- + +The default node pool DefaultPool does not support the following management operations. + +Configuring Kubernetes Parameters +--------------------------------- + +CCE allows you to highly customize Kubernetes parameter settings on core components in a cluster. For more information, see `kubelet `__. + +This function is supported only in clusters of **v1.15 and later**. It is not displayed for clusters earlier than v1.15. + +#. Log in to the CCE console. +#. Click the cluster name and access the cluster console. Choose **Nodes** in the navigation pane and click the **Node Pools** tab on the right. +#. Choose **More** > **Manage** next to the node pool name. +#. On the **Manage Component** page on the right, change the values of the following Kubernetes parameters: + + .. table:: **Table 1** kubelet + + +-------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | Parameter | Description | Default Value | Remarks | + +=========================+====================================================================================================================================================================================================================================================================================================================================================================================================================+=================================================================================================================================+=======================================================================================================================================================================================================================================================================+ + | cpu-manager-policy | CPU management policy configuration. For details, see :ref:`CPU Core Binding `. | none | ``-`` | + | | | | | + | | - **none**: disables pods from exclusively occupying CPUs. Select this value if you want a large pool of shareable CPU cores. | | | + | | - **static**: enables pods to exclusively occupy CPUs. Select this value if your workload is sensitive to latency in CPU cache and scheduling. | | | + +-------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | kube-api-qps | Query per second (QPS) to use while talking with kube-apiserver. | 100 | ``-`` | + +-------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | kube-api-burst | Burst to use while talking with kube-apiserver. | 100 | ``-`` | + +-------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | max-pods | Maximum number of pods managed by kubelet. | 40 | ``-`` | + | | | | | + | | | 20 | | + +-------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | pod-pids-limit | PID limit in Kubernetes | -1 | ``-`` | + +-------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | with-local-dns | Whether to use the local IP address as the ClusterDNS of the node. | false | ``-`` | + +-------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | event-qps | QPS limit for event creation | 5 | ``-`` | + +-------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | allowed-unsafe-sysctls | Insecure system configuration allowed. | [] | ``-`` | + | | | | | + | | Starting from **v1.17.17**, CCE enables pod security policies for kube-apiserver. You need to add corresponding configurations to **allowedUnsafeSysctls** of a pod security policy to make the policy take effect. (This configuration is not required for clusters earlier than v1.17.17.) For details, see :ref:`Example of Enabling Unsafe Sysctls in Pod Security Policy `. | | | + +-------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | kube-reserved-mem | Reserved node memory. | Depends on node specifications. For details, see :ref:`Formula for Calculating the Reserved Resources of a Node `. | The sum of kube-reserved-mem and system-reserved-mem is less than half of the memory. | + | | | | | + | system-reserved-mem | | | | + +-------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | topology-manager-policy | Set the topology management policy. | none | The values can be modified during the node pool lifecycle. | + | | | | | + | | Valid values are as follows: | | .. important:: | + | | | | | + | | - **restricted**: kubelet accepts only pods that achieve optimal NUMA alignment on the requested resources. | | NOTICE: | + | | - **best-effort**: kubelet preferentially selects pods that implement NUMA alignment on CPU and device resources. | | Exercise caution when modifying topology-manager-policy and topology-manager-scope will restart kubelet and recalculate the resource allocation of pods based on the modified policy. As a result, running pods may restart or even fail to receive any resources. | + | | - **none** (default): The topology management policy is disabled. | | | + | | - **single-numa-node**: kubelet allows only pods that are aligned to the same NUMA node in terms of CPU and device resources. | | | + +-------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | topology-manager-scope | Set the resource alignment granularity of the topology management policy. Valid values are as follows: | Container | | + | | | | | + | | - **container** (default) | | | + | | - **pod** | | | + +-------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | resolv-conf | DNS resolution configuration file specified by a container | The default value is null. | ``-`` | + +-------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | runtime-request-timeout | Timeout interval of all runtime requests except long-running requests (pull, logs, exec, and attach). | The default value is **2m0s**. | ``-`` | + +-------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | registry-pull-qps | Maximum number of image pulls per second. | The default value is **5**. | The value ranges from 1 to 50. | + +-------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | registry-burst | Maximum number of burst image pulls. | The default value is **10**. | The value ranges from 1 to 100 and must be greater than or equal to the value of **registry-pull-qps**. | + +-------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | serialize-image-pulls | When this function is enabled, kubelet is notified to pull only one image at a time. | The default value is **true**. | ``-`` | + +-------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + + .. table:: **Table 2** kube-proxy + + +----------------------------------+-------------------------------------------------------------+---------------+---------+ + | Parameter | Description | Default Value | Remarks | + +==================================+=============================================================+===============+=========+ + | conntrack-min | sysctl -w net.nf_conntrack_max | 131072 | ``-`` | + +----------------------------------+-------------------------------------------------------------+---------------+---------+ + | conntrack-tcp-timeout-close-wait | sysctl -w net.netfilter.nf_conntrack_tcp_timeout_close_wait | 1h0m0s | ``-`` | + +----------------------------------+-------------------------------------------------------------+---------------+---------+ + + .. table:: **Table 3** Network components (available only for CCE Turbo clusters) + + +---------------------------+------------------------------------------------------------------------------------------------------+------------------+-----------------+ + | Parameter | Description | Default Value | Remarks | + +===========================+======================================================================================================+==================+=================+ + | nic-threshold | Low threshold of the number of bound ENIs:High threshold of the number of bound ENIs | Default: **0:0** | ``-`` | + | | | | | + | | .. note:: | | | + | | | | | + | | This parameter is being discarded. Use the dynamic pre-binding parameters of the other four ENIs. | | | + +---------------------------+------------------------------------------------------------------------------------------------------+------------------+-----------------+ + | nic-minimum-target | Minimum number of ENIs bound to a node at the node pool level | Default: **10** | ``-`` | + +---------------------------+------------------------------------------------------------------------------------------------------+------------------+-----------------+ + | nic-maximum-target | Maximum number of ENIs pre-bound to a node at the node pool level | Default: **0** | ``-`` | + +---------------------------+------------------------------------------------------------------------------------------------------+------------------+-----------------+ + | nic-warm-target | Number of ENIs pre-bound to a node at the node pool level | Default: **2** | ``-`` | + +---------------------------+------------------------------------------------------------------------------------------------------+------------------+-----------------+ + | nic-max-above-warm-target | Reclaim number of ENIs pre-bound to a node at the node pool level | Default: **2** | ``-`` | + +---------------------------+------------------------------------------------------------------------------------------------------+------------------+-----------------+ + + .. table:: **Table 4** Pod security group in a node pool (available only for CCE Turbo clusters) + + +------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-----------------+-----------------+ + | Parameter | Description | Default Value | Remarks | + +==============================+=====================================================================================================================================================================================================================================================================================================+=================+=================+ + | security_groups_for_nodepool | - Default security group used by pods in a node pool. You can enter the security group ID. If this parameter is not set, the default security group of the cluster container network is used. A maximum of five security group IDs can be specified at the same time, separated by semicolons (;). | ``-`` | ``-`` | + | | - The priority of the security group is lower than that of the security group configured for :ref:`Security Groups `. | | | + +------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-----------------+-----------------+ + + .. table:: **Table 5** Docker (available only for node pools that use Docker) + + +-----------------------+---------------------------------------------------------------+-----------------+--------------------------------------------------------------------------------------------------------+ + | Parameter | Description | Default Value | Remarks | + +=======================+===============================================================+=================+========================================================================================================+ + | native-umask | \`--exec-opt native.umask | normal | Cannot be changed. | + +-----------------------+---------------------------------------------------------------+-----------------+--------------------------------------------------------------------------------------------------------+ + | docker-base-size | \`--storage-opts dm.basesize | 0 | Cannot be changed. | + +-----------------------+---------------------------------------------------------------+-----------------+--------------------------------------------------------------------------------------------------------+ + | insecure-registry | Address of an insecure image registry | false | Cannot be changed. | + +-----------------------+---------------------------------------------------------------+-----------------+--------------------------------------------------------------------------------------------------------+ + | limitcore | Maximum size of a core file in a container. The unit is byte. | 5368709120 | ``-`` | + | | | | | + | | If not specified, the value is **infinity**. | | | + +-----------------------+---------------------------------------------------------------+-----------------+--------------------------------------------------------------------------------------------------------+ + | default-ulimit-nofile | Limit on the number of handles in a container | {soft}:{hard} | The value cannot exceed the value of the kernel parameter **nr_open** and cannot be a negative number. | + | | | | | + | | | | You can run the following command to obtain the kernel parameter **nr_open**: | + | | | | | + | | | | .. code-block:: | + | | | | | + | | | | sysctl -a | grep nr_open | + +-----------------------+---------------------------------------------------------------+-----------------+--------------------------------------------------------------------------------------------------------+ + +#. Click **OK**. diff --git a/umn/source/node_pools/managing_a_node_pool/copying_a_node_pool.rst b/umn/source/node_pools/managing_a_node_pool/copying_a_node_pool.rst new file mode 100644 index 0000000..3bba7bd --- /dev/null +++ b/umn/source/node_pools/managing_a_node_pool/copying_a_node_pool.rst @@ -0,0 +1,14 @@ +:original_name: cce_10_0655.html + +.. _cce_10_0655: + +Copying a Node Pool +=================== + +You can copy the configuration of an existing node pool to create a new node pool on the CCE console. + +#. Log in to the CCE console. +#. Click the cluster name and access the cluster console. Choose **Nodes** in the navigation pane and click the **Node Pools** tab on the right. +#. Choose **More > Copy** next to a node pool name to copy the node pool. +#. The configurations of the selected node pool are replicated to the **Clone Node Pool** page. You can edit the configurations as required. For details about configuration items, see :ref:`Creating a Node Pool `. After confirming the configuration, click **Next: Confirm**. +#. On the **Confirm** page, confirm the node pool configuration and click **Submit**. Then, a new node pool is created based on the edited configuration. diff --git a/umn/source/node_pools/managing_a_node_pool/deleting_a_node_pool.rst b/umn/source/node_pools/managing_a_node_pool/deleting_a_node_pool.rst new file mode 100644 index 0000000..dababeb --- /dev/null +++ b/umn/source/node_pools/managing_a_node_pool/deleting_a_node_pool.rst @@ -0,0 +1,24 @@ +:original_name: cce_10_0657.html + +.. _cce_10_0657: + +Deleting a Node Pool +==================== + +Deleting a node pool will delete nodes in the pool. Pods on these nodes will be automatically migrated to available nodes in other node pools. + +Precautions +----------- + +- Deleting a node pool will delete all nodes in the node pool. Back up data in a timely manner to prevent data loss. +- Deleting a node will lead to pod migration, which may affect services. Perform this operation during off-peak hours. If pods in the node pool have a specific node selector and none of the other nodes in the cluster satisfies the node selector, the pods will become unschedulable. +- When deleting a node pool, the system sets all nodes in the current node pool to the unschedulable state. + +Procedure +--------- + +#. Log in to the CCE console. +#. Click the cluster name and access the cluster console. Choose **Nodes** in the navigation pane and click the **Node Pools** tab on the right. +#. Choose **More > Delete** next to a node pool name to delete the node pool. +#. Read the precautions in the **Delete Node Pool** dialog box. +#. In the text box, click **Yes** to confirm that you want to continue the deletion. diff --git a/umn/source/node_pools/managing_a_node_pool/index.rst b/umn/source/node_pools/managing_a_node_pool/index.rst new file mode 100644 index 0000000..6dfc7e1 --- /dev/null +++ b/umn/source/node_pools/managing_a_node_pool/index.rst @@ -0,0 +1,26 @@ +:original_name: cce_10_0222.html + +.. _cce_10_0222: + +Managing a Node Pool +==================== + +- :ref:`Configuring a Node Pool ` +- :ref:`Updating a Node Pool ` +- :ref:`Synchronizing Node Pools ` +- :ref:`Upgrading the OS ` +- :ref:`Copying a Node Pool ` +- :ref:`Migrating a Node ` +- :ref:`Deleting a Node Pool ` + +.. toctree:: + :maxdepth: 1 + :hidden: + + configuring_a_node_pool + updating_a_node_pool + synchronizing_node_pools + upgrading_the_os + copying_a_node_pool + migrating_a_node + deleting_a_node_pool diff --git a/umn/source/node_pools/managing_a_node_pool/migrating_a_node.rst b/umn/source/node_pools/managing_a_node_pool/migrating_a_node.rst new file mode 100644 index 0000000..cf0d2d7 --- /dev/null +++ b/umn/source/node_pools/managing_a_node_pool/migrating_a_node.rst @@ -0,0 +1,18 @@ +:original_name: cce_10_0656.html + +.. _cce_10_0656: + +Migrating a Node +================ + +Nodes in a node pool can be migrated. Currently, nodes in a node pool can be migrated only to the default node pool (defaultpool) in the same cluster. + +#. Log in to the CCE console and access the cluster console. +#. In the navigation pane, choose **Nodes** and switch to the **Node Pools** tab page. +#. Click **View Node** in the **Operation** column of the node pool to be migrated. +#. Click **More** > **Migrate** in the **Operation** column of the target node to migrate the node. +#. In the displayed **Migrate Node** window, confirm the information. + + .. note:: + + The migration has no impacts on the original resource tags, Kubernetes labels, and taints of the node. diff --git a/umn/source/node_pools/managing_a_node_pool/synchronizing_node_pools.rst b/umn/source/node_pools/managing_a_node_pool/synchronizing_node_pools.rst new file mode 100644 index 0000000..83fbff9 --- /dev/null +++ b/umn/source/node_pools/managing_a_node_pool/synchronizing_node_pools.rst @@ -0,0 +1,39 @@ +:original_name: cce_10_0654.html + +.. _cce_10_0654: + +Synchronizing Node Pools +======================== + +After the configuration of a node pool is updated, some configurations cannot be automatically synchronized for existing nodes. You can manually synchronize configurations for these nodes. + +.. important:: + + - Do not delete or reset nodes during batch synchronization. Otherwise, the synchronization of node pool configuration may fail. + - This operation involves resetting nodes. **Workload services running on the nodes may be interrupted due to single-instance deployment or insufficient schedulable resources.** Evaluate the upgrade risks and perform the upgrade during off-peak hours. You can also `specify a disruption budget for your application `__) to ensure the availability of key services during the upgrade. + - During configuration synchronization for existing nodes, the system disk and data disk will be cleared. Back up important data before the synchronization. + - Only some node pool parameters can be synchronized by resetting nodes. The constraints are as follows: + + - When editing the resource tags of the node pool. The modified configuration takes effect only for new nodes. To synchronize the configuration to the existing nodes, you need to manually reset the existing nodes. + - Updates of kubernetes labels and taints are automatically synchronized to existing nodes. You do not need to reset nodes. + +Synchronizing a Single Node +--------------------------- + +#. Log in to the CCE console. +#. Access the cluster console, choose **Nodes** in the navigation pane, and click the **Node Pools** tab on the right. +#. **upgrade** is displayed in the **Node Pool** column of the existing nodes in the node pool. +#. Click **update**. In the dialog box that is displayed, confirm whether to reset the node immediately. + +Batch Synchronization +--------------------- + +#. Log in to the CCE console. +#. Click the cluster name and access the cluster console. Choose **Nodes** in the navigation pane and click the **Node Pools** tab on the right. +#. Choose **More > Synchronize** in the **Operation** column of the target node pool. +#. In the **Batch Synchronization** window, set the synchronization parameters. + + - **Synchronization Policy**: **Node Reset** is supported. + - **Max. Nodes for Batch Synchronize**: Nodes will be unavailable during synchronization in **Node Reset** mode. Set this parameter properly to prevent pod scheduling failures caused by too many unavailable nodes in the cluster. + +#. In the node list, select the nodes to be synchronized and click **OK** to start the synchronization. diff --git a/umn/source/node_pools/managing_a_node_pool/updating_a_node_pool.rst b/umn/source/node_pools/managing_a_node_pool/updating_a_node_pool.rst new file mode 100644 index 0000000..02e6e0c --- /dev/null +++ b/umn/source/node_pools/managing_a_node_pool/updating_a_node_pool.rst @@ -0,0 +1,98 @@ +:original_name: cce_10_0653.html + +.. _cce_10_0653: + +Updating a Node Pool +==================== + +Constraints +----------- + +- When editing the resource tags of the node pool. The modified configuration takes effect only for new nodes. To synchronize the configuration to the existing nodes, you need to manually reset the existing nodes. +- Updates of kubernetes labels and taints are automatically synchronized to existing nodes. You do not need to reset nodes. + + +Updating a Node Pool +-------------------- + +#. Log in to the CCE console. + +#. Click the cluster name and access the cluster console. Choose **Nodes** in the navigation pane and click the **Node Pools** tab on the right. + +#. Click **Update** next to the name of the node pool you will edit. Configure the parameters in the displayed **Update Node Pool** page. + + **Basic Settings** + + .. table:: **Table 1** Basic settings + + +-----------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | Parameter | Description | + +===================================+=================================================================================================================================================================================================================================================================================================================================================================================================================================================+ + | Node Pool Name | Name of the node pool. | + +-----------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | Nodes | Modify the number of nodes based on service requirements. | + +-----------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | Auto Scaling | By default, this parameter is disabled. | + | | | + | | After you enable autoscaler by clicking |image1|, nodes in the node pool are automatically created or deleted based on service requirements. | + | | | + | | - **Maximum Nodes** and **Minimum Nodes**: You can set the maximum and minimum number of nodes to ensure that the number of nodes to be scaled is within a proper range. | + | | | + | | - **Priority**: A larger value indicates a higher priority. For example, if this parameter is set to **1** and **4** respectively for node pools A and B, B has a higher priority than A, and auto scaling is first triggered for B. If the priorities of multiple node pools are set to the same value, for example, **2**, the node pools are not prioritized and the system performs scaling based on the minimum resource waste principle. | + | | | + | | After the priority is updated, the configuration takes effect within 1 minute. | + | | | + | | - **Cooldown Period**: Enter a period, in minutes. This field indicates the period during which the nodes added in the current node pool cannot be scaled in. | + | | | + | | If the **Autoscaler** field is set to on, install the :ref:`autoscaler add-on ` to use the autoscaler feature. | + +-----------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + + **Advanced Settings** + + .. table:: **Table 2** Advanced settings + + +-----------------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | Parameter | Description | + +===================================+================================================================================================================================================================================================================================================================+ + | Kubernetes Label | Click **Add Label** to set the key-value pair attached to the Kubernetes objects (such as pods). A maximum of 20 labels can be added. | + | | | + | | Labels can be used to distinguish nodes. With workload affinity settings, container pods can be scheduled to a specified node. For more information, see `Labels and Selectors `__. | + | | | + | | .. note:: | + | | | + | | After a **Kubernetes label** is modified, the inventory nodes in the node pool are updated synchronously. | + +-----------------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | Resource Tag | You can add resource tags to classify resources. | + | | | + | | You can create **predefined tags** in Tag Management Service (TMS). Predefined tags are visible to all service resources that support the tagging function. You can use these tags to improve tagging and resource migration efficiency. | + | | | + | | CCE will automatically create the "CCE-Dynamic-Provisioning-Node=\ *node id*" tag. | + | | | + | | .. note:: | + | | | + | | After a **resource tag** is modified, the modification automatically takes effect when a node is added. For existing nodes, you need to manually reset the nodes for the modification to take effect. | + +-----------------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | Taint | This field is left blank by default. You can add taints to set anti-affinity for the node. A maximum of 10 taints are allowed for each node. Each taint contains the following parameters: | + | | | + | | - **Key**: A key must contain 1 to 63 characters, starting with a letter or digit. Only letters, digits, hyphens (-), underscores (_), and periods (.) are allowed. A DNS subdomain name can be used as the prefix of a key. | + | | - **Value**: A value must start with a letter or digit and can contain a maximum of 63 characters, including letters, digits, hyphens (-), underscores (_), and periods (.). | + | | - **Effect**: Available options are **NoSchedule**, **PreferNoSchedule**, and **NoExecute**. | + | | | + | | For details, see :ref:`Managing Node Taints `. | + | | | + | | .. note:: | + | | | + | | After a **taint** is modified, the inventory nodes in the node pool are updated synchronously. | + +-----------------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | Edit Key pair | Only node pools that use key pairs for login support key pair editing. You can select another key pair. | + | | | + | | .. note:: | + | | | + | | The edited key pair automatically takes effect when a node is added. For existing nodes, you need to manually reset the nodes for the key pair to take effect. | + +-----------------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + +#. When the configuration is complete, click **OK**. + + After the node pool parameters are updated, go to the **Nodes** page to check whether the node to which the node pool belongs is updated. You can reset the node to synchronize the configuration updates for the node pool. + +.. |image1| image:: /_static/images/en-us_image_0000001629926113.png diff --git a/umn/source/node_pools/managing_a_node_pool/upgrading_the_os.rst b/umn/source/node_pools/managing_a_node_pool/upgrading_the_os.rst new file mode 100644 index 0000000..a745e31 --- /dev/null +++ b/umn/source/node_pools/managing_a_node_pool/upgrading_the_os.rst @@ -0,0 +1,59 @@ +:original_name: cce_10_0660.html + +.. _cce_10_0660: + +Upgrading the OS +================ + +When CCE releases a new OS image, existing nodes cannot be automatically upgraded. You can manually upgrade them in batches. + +.. important:: + + - This operation will upgrade the OS by resetting the node. **Workloads running on the node may be interrupted due to single-instance deployment or insufficient schedulable resources.** Evaluate the upgrade risks and upgrade the OS during off-peak hours, you can also set the Pod Disruption Budget (PDB, that is `disruption budget `__) policy for important applications to ensure their availability. + - Nodes that use private images cannot be upgraded. + +Procedure +--------- + +**Default node pool** + +#. Log in to the CCE console. +#. Click the cluster name and access the cluster console. Choose **Nodes** in the navigation pane and click the **Node Pools** tab on the right. +#. Click **Upgrade** next to the default node pool +#. In the displayed **Operating system upgrade** window, set upgrade parameters. + + - **Max. Unavailable Nodes**: specifies the maximum number of unavailable nodes during node synchronization. + + - **Target Operating System**: You do not need to set this parameter. It is used to display the image information of the target version. + + - **Node List**: Select the nodes to be upgraded. + + - Login Mode: + + - **Key Pair** + + Select the key pair used to log in to the node. You can select a shared key. + + A key pair is used for identity authentication when you remotely log in to a node. If no key pair is available, click **Create Key Pair**. + + - **Pre-installation Command**: Enter a maximum of 1,000 characters. + + The script will be executed before Kubernetes software is installed. Note that if the script is incorrect, Kubernetes software may fail to be installed. + + - **Post-installation Command**: Enter a maximum of 1,000 characters. + + The script will be executed after Kubernetes software is installed and will not affect the installation. + +#. Click **OK**. + +**Non-default node pool** + +#. Log in to the CCE console. +#. Click the cluster name and access the cluster console. Choose **Nodes** in the navigation pane and click the **Node Pools** tab on the right. +#. Choose **More > Synchronize** next to a node pool name. +#. In the displayed **Batch synchronization** dialog box, set upgrade parameters. + + - **Max. Unavailable Nodes**: specifies the maximum number of unavailable nodes during node synchronization. + - **Node List**: This parameter cannot be set. By default, nodes that can be upgraded are selected. + +#. Click **OK**. diff --git a/umn/source/nodes/adding_nodes_for_management.rst b/umn/source/nodes/adding_nodes_for_management.rst index 23e0311..4887184 100644 --- a/umn/source/nodes/adding_nodes_for_management.rst +++ b/umn/source/nodes/adding_nodes_for_management.rst @@ -47,29 +47,30 @@ Procedure .. table:: **Table 1** Configuration parameters - +-----------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ - | Parameter | Description | - +===================================+=======================================================================================================================================================================================+ - | Specifications | Click **Select Cloud Server** and select the servers to be accepted. | - | | | - | | You can select multiple cloud servers for batch management. However, only the cloud servers with the same specifications, AZ, and data disk configuration can be added in batches. | - | | | - | | If a cloud server contains multiple data disks, select one of them for the container runtime and kubelet. | - +-----------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ - | Container Engine | CCE clusters support Docker. Starting from CCE 1.23, containerd is supported. | - | | | - | | For a CCE Turbo cluster, both **Docker** and **containerd** are supported. For details, see :ref:`Mapping between Node OSs and Container Engines `. | - +-----------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ - | OS | **Public image**: Select an OS for the node. | - | | | - | | **Private image**: You can use private images. | - +-----------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ - | Login Mode | - **Key Pair** | - | | | - | | Select the key pair used to log in to the node. You can select a shared key. | - | | | - | | A key pair is used for identity authentication when you remotely log in to a node. If no key pair is available, click **Create Key Pair**. | - +-----------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + +-----------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | Parameter | Description | + +===================================+==========================================================================================================================================================================================+ + | Specifications | Click **Select Cloud Server** and select the servers to be accepted. | + | | | + | | You can select multiple cloud servers for batch management. However, only the cloud servers with the same specifications, AZ, and data disk configuration can be added in batches. | + | | | + | | If a cloud server contains multiple data disks, select one of them for the container runtime and kubelet. | + +-----------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | Container Engine | CCE clusters support Docker and containerd in some scenarios. | + | | | + | | - VPC network clusters of v1.23 and later versions support containerd. Container tunnel network clusters of v1.23.2-r0 and later versions support containerd. | + | | - For a CCE Turbo cluster, both **Docker** and **containerd** are supported. For details, see :ref:`Mapping between Node OSs and Container Engines `. | + +-----------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | OS | **Public image**: Select an OS for the node. | + | | | + | | **Private image**: You can use private images. | + +-----------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | Login Mode | - **Key Pair** | + | | | + | | Select the key pair used to log in to the node. You can select a shared key. | + | | | + | | A key pair is used for identity authentication when you remotely log in to a node. If no key pair is available, click **Create Key Pair**. | + +-----------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ **Storage Settings** diff --git a/umn/source/nodes/creating_a_node.rst b/umn/source/nodes/creating_a_node.rst index 677daed..04c26a4 100644 --- a/umn/source/nodes/creating_a_node.rst +++ b/umn/source/nodes/creating_a_node.rst @@ -17,7 +17,7 @@ Notes and Constraints - The node has 2-core or higher CPU, 4 GB or larger memory. - To ensure node stability, a certain amount of CCE node resources will be reserved for Kubernetes components (such as kubelet, kube-proxy, and docker) based on the node specifications. Therefore, the total number of node resources and assignable node resources in Kubernetes are different. The larger the node specifications, the more the containers deployed on the node. Therefore, more node resources need to be reserved to run Kubernetes components. For details, see :ref:`Formula for Calculating the Reserved Resources of a Node `. - The node networking (such as the VM networking and container networking) is taken over by CCE. You are not allowed to add and delete NICs or change routes. If you modify the networking configuration, the availability of CCE may be affected. For example, the NIC named **gw_11cbf51a@eth0** on the node is the container network gateway and cannot be modified. -- During the node creation, software packages are downloaded from OBS using the domain name. You need to use a private DNS server to resolve the OBS domain name, and configure the subnet where the node resides with a private DNS server address. When you create a subnet, the private DNS server is used by default. If you change the subnet DNS, ensure that the DNS server in use can resolve the OBS domain name. +- During the node creation, software packages are downloaded from OBS using the domain name. You need to use a private DNS server to resolve the OBS domain name, and configure the DNS server address of the subnet where the node resides with a private DNS server address. When you create a subnet, the private DNS server is used by default. If you change the subnet DNS, ensure that the DNS server in use can resolve the OBS domain name. - Once a node is created, its AZ cannot be changed. Procedure @@ -44,9 +44,13 @@ After a cluster is created, you can create nodes for the cluster. | | | | | An AZ is a physical region where resources use independent power supply and networks. AZs are physically isolated but interconnected through an internal network. To enhance workload availability, create nodes in different AZs. | +-----------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ - | Node Type | CCE clusters support Elastic Cloud Servers (ECSs). | + | Node Type | CCE cluster: | | | | - | | CCE Turbo clusters support Elastic Cloud Servers (ECSs) and bare metal servers (BMSs). | + | | - ECS (VM): Containers run on ECSs. | + | | | + | | CCE Turbo cluster: | + | | | + | | - ECS (VM): Containers run on ECSs. Only Trunkport ECSs (models that can be bound with multiple elastic network interfaces) are supported. | +-----------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Container Engine | CCE clusters support Docker and containerd in some scenarios. | | | | @@ -85,14 +89,17 @@ After a cluster is created, you can create nodes for the cluster. +===================================+===============================================================================================================================================================================================================================================================================================+ | System Disk | System disk used by the node OS. The value ranges from 40 GB to 1,024 GB. The default value is 50 GB. | | | | - | | **Encryption**: Data disk encryption safeguards your data. Snapshots generated from encrypted disks and disks created using these snapshots automatically inherit the encryption function. **This function is available only in certain regions.** | + | | **Encryption**: System disk encryption safeguards your data. Snapshots generated from encrypted disks and disks created using these snapshots automatically inherit the encryption function. **This function is available only in certain regions.** | | | | | | - **Encryption** is not selected by default. | | | - After you select **Encryption**, you can select an existing key in the displayed dialog box. If no key is available, click **View Key List** to create a key. After the key is created, click the refresh icon. | +-----------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ - | Data Disk | Data disk used by the container runtime and kubelet on the node. | + | Data Disk | **At least one data disk is required** for the container runtime and kubelet. **The data disk cannot be deleted or uninstalled. Otherwise, the node will be unavailable.** | | | | - | | **At least one data disk is required** for the container runtime and kubelet. **The data disk cannot be deleted or uninstalled. Otherwise, the node will be unavailable.** | + | | - First data disk: used for container runtime and kubelet components. The value ranges from 20 GB to 32,768 GB. The default value is 100 GB. | + | | - Other data disks: You can set the data disk size to a value ranging from 10 GB to 32,768 GB. The default value is 100 GB. | + | | | + | | **Advanced Settings** | | | | | | Click **Expand** to set the following parameters: | | | | @@ -122,13 +129,17 @@ After a cluster is created, you can create nodes for the cluster. .. table:: **Table 3** Configuration parameters - +-----------------+-------------------------------------------------------------------------------------------------------------+ - | Parameter | Description | - +=================+=============================================================================================================+ - | Node Subnet | The node subnet selected during cluster creation is used by default. You can choose another subnet instead. | - +-----------------+-------------------------------------------------------------------------------------------------------------+ - | Node IP Address | IP address of the specified node. By default, the value is randomly allocated. | - +-----------------+-------------------------------------------------------------------------------------------------------------+ + +-----------------------------------+-------------------------------------------------------------------------------------------------------------+ + | Parameter | Description | + +===================================+=============================================================================================================+ + | Node Subnet | The node subnet selected during cluster creation is used by default. You can choose another subnet instead. | + +-----------------------------------+-------------------------------------------------------------------------------------------------------------+ + | Node IP Address | IP address of the specified node. By default, the value is randomly allocated. | + +-----------------------------------+-------------------------------------------------------------------------------------------------------------+ + | EIP | A cloud server without an EIP cannot access public networks or be accessed by public networks. | + | | | + | | The default value is **Do not use**. **Use existing** and **Auto create** are supported. | + +-----------------------------------+-------------------------------------------------------------------------------------------------------------+ **Advanced Settings** diff --git a/umn/source/nodes/deleting_a_node.rst b/umn/source/nodes/deleting_a_node.rst index 2f1033e..f234fcc 100644 --- a/umn/source/nodes/deleting_a_node.rst +++ b/umn/source/nodes/deleting_a_node.rst @@ -13,13 +13,7 @@ When a node in a CCE cluster is deleted, services running on the node will also Notes and Constraints --------------------- -- After a CCE cluster is deleted, the ECS nodes in the cluster are also deleted. - -- - - .. important:: - - For clusters of v1.17.11 or later, after a VM is deleted on the ECS console, the corresponding node in the CCE cluster is automatically deleted. +- VM nodes that are being used by CCE do not support deletion on the ECS page. Precautions ----------- diff --git a/umn/source/nodes/node_overview/container_engine.rst b/umn/source/nodes/node_overview/container_engine.rst index 340d1c0..41bd442 100644 --- a/umn/source/nodes/node_overview/container_engine.rst +++ b/umn/source/nodes/node_overview/container_engine.rst @@ -17,31 +17,41 @@ Mapping between Node OSs and Container Engines .. table:: **Table 1** Node OSs and container engines in CCE clusters - +-------------+----------------+-------------------------------------------------+-----------------------------------------------------+-------------------+ - | OS | Kernel Version | Container Engine | Container Storage Rootfs | Container Runtime | - +=============+================+=================================================+=====================================================+===================+ - | CentOS 7.x | 3.x | Docker | Clusters of v1.19.16 and earlier use Device Mapper. | runC | - | | | | | | - | | | Clusters of v1.23 and later support containerd. | Clusters of v1.19.16 and later use OverlayFS. | | - +-------------+----------------+-------------------------------------------------+-----------------------------------------------------+-------------------+ - | EulerOS 2.5 | 3.x | Docker | Device Mapper | runC | - +-------------+----------------+-------------------------------------------------+-----------------------------------------------------+-------------------+ - | EulerOS 2.9 | 4.x | Docker | OverlayFS | runC | - | | | | | | - | | | Clusters of v1.23 and later support containerd. | | | - +-------------+----------------+-------------------------------------------------+-----------------------------------------------------+-------------------+ + +--------------+----------------+-------------------------------------------------+-----------------------------------------------------+-------------------+ + | OS | Kernel Version | Container Engine | Container Storage Rootfs | Container Runtime | + +==============+================+=================================================+=====================================================+===================+ + | CentOS 7.x | 3.x | Docker | Clusters of v1.19.16 and earlier use Device Mapper. | runC | + | | | | | | + | | | Clusters of v1.23 and later support containerd. | Clusters of v1.19.16 and later use OverlayFS. | | + +--------------+----------------+-------------------------------------------------+-----------------------------------------------------+-------------------+ + | EulerOS 2.5 | 3.x | Docker | Device Mapper | runC | + +--------------+----------------+-------------------------------------------------+-----------------------------------------------------+-------------------+ + | EulerOS 2.9 | 4.x | Docker | OverlayFS | runC | + | | | | | | + | | | Clusters of v1.23 and later support containerd. | | | + +--------------+----------------+-------------------------------------------------+-----------------------------------------------------+-------------------+ + | Ubuntu 22.04 | 4.x | Docker | OverlayFS | runC | + | | | | | | + | | | containerd | | | + +--------------+----------------+-------------------------------------------------+-----------------------------------------------------+-------------------+ .. table:: **Table 2** Node OSs and container engines in CCE Turbo clusters - +-----------------------------------------+-------------+----------------+------------------+--------------------------+-------------------+ - | Node Type | OS | Kernel Version | Container Engine | Container Storage Rootfs | Container Runtime | - +=========================================+=============+================+==================+==========================+===================+ - | Elastic Cloud Server (VM) | CentOS 7.x | 3.x | Docker | OverlayFS | runC | - | | | | | | | - | | EulerOS 2.9 | | | | | - +-----------------------------------------+-------------+----------------+------------------+--------------------------+-------------------+ - | Elastic Cloud Server (physical machine) | EulerOS 2.9 | 4.x | containerd | Device Mapper | Kata | - +-----------------------------------------+-------------+----------------+------------------+--------------------------+-------------------+ + +---------------------------+--------------+----------------+-------------------------------------------------+--------------------------+-------------------+ + | Node Type | OS | Kernel Version | Container Engine | Container Storage Rootfs | Container Runtime | + +===========================+==============+================+=================================================+==========================+===================+ + | Elastic Cloud Server (VM) | CentOS 7.x | 3.x | Docker | OverlayFS | runC | + +---------------------------+--------------+----------------+-------------------------------------------------+--------------------------+-------------------+ + | | EulerOS 2.5 | 3.x | Docker | OverlayFS | runC | + +---------------------------+--------------+----------------+-------------------------------------------------+--------------------------+-------------------+ + | | EulerOS 2.9 | 4.x | Docker | OverlayFS | runC | + | | | | | | | + | | | | Clusters of v1.23 and later support containerd. | | | + +---------------------------+--------------+----------------+-------------------------------------------------+--------------------------+-------------------+ + | | Ubuntu 22.04 | 4.x | Docker | OverlayFS | runC | + | | | | | | | + | | | | containerd | | | + +---------------------------+--------------+----------------+-------------------------------------------------+--------------------------+-------------------+ Differences in Tracing ---------------------- @@ -65,6 +75,12 @@ Container Engine Version Description - Docker - - EulerOS/CentOS: docker-engine 18.9.0, a Docker version customized for CCE. Security vulnerabilities will be fixed in a timely manner. + - EulerOS/CentOS: docker 18.9.0, a Docker version customized for CCE. Security vulnerabilities will be fixed in a timely manner. + - Ubuntu 22.04: docker-ce 20.10.21 (community version). -- containerd: 1.4.1 + .. note:: + + - You are advised to use the containerd engine for Ubuntu nodes. + - The open source docker-ce of the Ubuntu 18.04 node may trigger bugs when concurrent exec operations are performed (for example, multiple exec probes are configured). You are advised to use HTTP/TCP probes. + +- containerd: 1.6.14 diff --git a/umn/source/nodes/node_overview/data_disk_space_allocation.rst b/umn/source/nodes/node_overview/data_disk_space_allocation.rst index b094458..030b4a2 100644 --- a/umn/source/nodes/node_overview/data_disk_space_allocation.rst +++ b/umn/source/nodes/node_overview/data_disk_space_allocation.rst @@ -93,5 +93,5 @@ Recommended Configuration for the Container Engine Space - You are advised to create and delete files of containerized services in local storage volumes (such as emptyDir and hostPath volumes) or cloud storage directories mounted to the containers. In this way, the thin pool space is not occupied. emptyDir volumes occupy the kubelet space. Therefore, properly plan the size of the kubelet space. - If OverlayFS is used by in CCE clusters, you can deploy services on these nodes so that the disk space occupied by files created or deleted in containers can be released immediately. -.. |image1| image:: /_static/images/en-us_image_0000001199021278.png -.. |image2| image:: /_static/images/en-us_image_0000001244101121.png +.. |image1| image:: /_static/images/en-us_image_0000001517902940.png +.. |image2| image:: /_static/images/en-us_image_0000001517743364.png diff --git a/umn/source/nodes/node_overview/formula_for_calculating_the_reserved_resources_of_a_node.rst b/umn/source/nodes/node_overview/formula_for_calculating_the_reserved_resources_of_a_node.rst index 5378bb2..484d662 100644 --- a/umn/source/nodes/node_overview/formula_for_calculating_the_reserved_resources_of_a_node.rst +++ b/umn/source/nodes/node_overview/formula_for_calculating_the_reserved_resources_of_a_node.rst @@ -5,7 +5,7 @@ Formula for Calculating the Reserved Resources of a Node ======================================================== -Some of the resources on the node need to run some necessary Kubernetes system components and resources to make the node as part of your cluster. Therefore, the total number of node resources and the number of assignable node resources in Kubernetes are different. The larger the node specifications, the more the containers deployed on the node. Therefore, Kubernetes needs to reserve more resources. +Some of the resources on the node need to run some necessary Kubernetes system components and resources to make the node as part of your cluster. Therefore, the total number of node resources and the number of assignable node resources in Kubernetes are different. The larger the node specifications, the more the containers deployed on the node. Therefore, more node resources need to be reserved to run Kubernetes components. To ensure node stability, a certain amount of CCE node resources will be reserved for Kubernetes components (such as kubelet, kube-proxy, and docker) based on the node specifications. @@ -17,8 +17,8 @@ The memory eviction threshold is fixed at 100 MB. When the memory consumed by all pods on a node increases, the following behaviors may occur: -#. If the memory is greater than or equal to the allocatable amount on the node, kubelet is triggered to evict pods. -#. When the memory approaches the allocatable amount and eviction threshold (total minus reserved), OS OOM is triggered. +#. When the available memory on a node is lower than the eviction threshold, kubelet is triggered to evict pods. For details about Kubernetes eviction threshold, see `Node-pressure Eviction `__. +#. If a node triggers an OS Out-Of-Memory (OOM) event before kubelet reclaims memory, the system terminates the container. However, kubelet does not evict the pod, but restarts the container based on the RestartPolicy of the pod. Rules for Reserving Node Memory ------------------------------- diff --git a/umn/source/nodes/node_overview/maximum_number_of_pods_that_can_be_created_on_a_node.rst b/umn/source/nodes/node_overview/maximum_number_of_pods_that_can_be_created_on_a_node.rst index 7cf6523..576ddd3 100644 --- a/umn/source/nodes/node_overview/maximum_number_of_pods_that_can_be_created_on_a_node.rst +++ b/umn/source/nodes/node_overview/maximum_number_of_pods_that_can_be_created_on_a_node.rst @@ -26,7 +26,10 @@ Container Network vs. Host Network When creating a pod, you can select the container network or host network for the pod. -- Container network (default): **Each pod is assigned an IP address by the cluster networking add-ons, which occupies the IP addresses of the container network**. +- .. _cce_10_0348__li13739132619599: + + Container network (default): **Each pod is assigned an IP address by the cluster networking add-ons, which occupies the IP addresses of the container network**. + - Host network: The pod uses the host network (**hostNetwork: true** needs to be configured for the pod) and occupies the host port. The pod IP address is the host IP address. The pod does not occupy the IP addresses of the container network. To use the host network, you must confirm whether the container ports conflict with the host ports. Do not use the host network unless you know exactly which host port is used by which container. .. _cce_10_0348__section10770192193714: @@ -36,7 +39,7 @@ Number of Container IP Addresses That Can Be Allocated on a Node If you select **VPC network** for **Network Model** when creating a CCE cluster, you also need to set the number of container IP addresses that can be allocated to each node. -This parameter affects the maximum number of pods that can be created on a node. Each pod occupies an IP address (when the container network is used). If the number of available IP addresses is insufficient, pods cannot be created. +This parameter affects the maximum number of pods that can be created on a node. Each pod occupies an IP address (when the :ref:`container network ` is used). If the number of available IP addresses is insufficient, pods cannot be created. By default, a node occupies three container IP addresses (network address, gateway address, and broadcast address). Therefore, the number of container IP addresses that can be allocated to a node equals the number of selected container IP addresses minus 3. For example, in the preceding figure, **the number of container IP addresses that can be allocated to a node is 125 (128 - 3)**. diff --git a/umn/source/nodes/performing_rolling_upgrade_for_nodes.rst b/umn/source/nodes/performing_rolling_upgrade_for_nodes.rst index f6d0645..cfd4a55 100644 --- a/umn/source/nodes/performing_rolling_upgrade_for_nodes.rst +++ b/umn/source/nodes/performing_rolling_upgrade_for_nodes.rst @@ -12,7 +12,7 @@ In a rolling upgrade, a new node is created, existing workloads are migrated to .. _cce_10_0276__fig1689610598118: -.. figure:: /_static/images/en-us_image_0000001199181340.png +.. figure:: /_static/images/en-us_image_0000001568822733.png :alt: **Figure 1** Workload migration **Figure 1** Workload migration @@ -74,7 +74,7 @@ Scenario 2: The Original Node Is Not in DefaultPool #. .. _cce_10_0276__li1992616214312: - Copy the node pool and add nodes to it. For details, see :ref:`Copying a Node Pool `. + Copy the node pool and add nodes to it. For details, see :ref:`Copying a Node Pool `. #. Click **View Node** in the **Operation** column of the node pool. The IP address of the new node is displayed in the node list. diff --git a/umn/source/nodes/resetting_a_node.rst b/umn/source/nodes/resetting_a_node.rst index 27fac2c..e1840a4 100644 --- a/umn/source/nodes/resetting_a_node.rst +++ b/umn/source/nodes/resetting_a_node.rst @@ -50,25 +50,26 @@ The new console allows you to reset nodes in batches. You can also use private i .. table:: **Table 1** Configuration parameters - +-----------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ - | Parameter | Description | - +===================================+=======================================================================================================================================================================================+ - | Specification | Node specifications cannot be modified when you reset a node. | - +-----------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ - | Container Engine | CCE clusters support Docker. | - | | | - | | For a CCE Turbo cluster, both **Docker** and **containerd** are supported. For details, see :ref:`Mapping between Node OSs and Container Engines `. | - +-----------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ - | OS | **Public image**: Select an OS for the node. | - | | | - | | **Private image**: You can use private images. | - +-----------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ - | Login Mode | - **Key Pair** | - | | | - | | Select the key pair used to log in to the node. You can select a shared key. | - | | | - | | A key pair is used for identity authentication when you remotely log in to a node. If no key pair is available, click **Create Key Pair**. | - +-----------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + +-----------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | Parameter | Description | + +===================================+==========================================================================================================================================================================================+ + | Specification | Node specifications cannot be modified when you reset a node. | + +-----------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | Container Engine | CCE clusters support Docker and containerd in some scenarios. | + | | | + | | - VPC network clusters of v1.23 and later versions support containerd. Container tunnel network clusters of v1.23.2-r0 and later versions support containerd. | + | | - For a CCE Turbo cluster, both **Docker** and **containerd** are supported. For details, see :ref:`Mapping between Node OSs and Container Engines `. | + +-----------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | OS | **Public image**: Select an OS for the node. | + | | | + | | **Private image**: You can use private images. | + +-----------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | Login Mode | - **Key Pair** | + | | | + | | Select the key pair used to log in to the node. You can select a shared key. | + | | | + | | A key pair is used for identity authentication when you remotely log in to a node. If no key pair is available, click **Create Key Pair**. | + +-----------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ **Storage Settings** @@ -95,7 +96,7 @@ The new console allows you to reset nodes in batches. You can also use private i +-----------------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Parameter | Description | +===================================+================================================================================================================================================================================================================================================================+ - | Kubernetes Label | Click **Add Label** to set the key-value pair attached to the Kubernetes objects (such as pods). A maximum of 20 labels can be added. | + | Kubernetes Label | Click **Add** to set the key-value pair attached to the Kubernetes objects (such as pods). A maximum of 20 labels can be added. | | | | | | Labels can be used to distinguish nodes. With workload affinity settings, container pods can be scheduled to a specified node. For more information, see `Labels and Selectors `__. | +-----------------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ @@ -105,9 +106,9 @@ The new console allows you to reset nodes in batches. You can also use private i | | | | | CCE will automatically create the "CCE-Dynamic-Provisioning-Node=\ *node id*" tag. | +-----------------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ - | Taint | This field is left blank by default. You can add taints to set anti-affinity for the node. A maximum of 10 taints are allowed for each node. Each taint contains the following parameters: | + | Taint | This parameter is left blank by default. You can add taints to set anti-affinity for the node. A maximum of 10 taints are allowed for each node. Each taint contains the following parameters: | | | | - | | - **Key**: A key must contain 1 to 63 characters, starting with a letter or digit. Only letters, digits, hyphens (-), underscores (_), and periods (.) are allowed. A DNS subdomain name can be used as the prefix of a key. | + | | - **Key**: A key must contain 1 to 63 characters starting with a letter or digit. Only letters, digits, hyphens (-), underscores (_), and periods (.) are allowed. A DNS subdomain name can be used as the prefix of a key. | | | - **Value**: A value must start with a letter or digit and can contain a maximum of 63 characters, including letters, digits, hyphens (-), underscores (_), and periods (.). | | | - **Effect**: Available options are **NoSchedule**, **PreferNoSchedule**, and **NoExecute**. | | | | diff --git a/umn/source/nodes/stopping_a_node.rst b/umn/source/nodes/stopping_a_node.rst index f9d9c1a..b1c95c4 100644 --- a/umn/source/nodes/stopping_a_node.rst +++ b/umn/source/nodes/stopping_a_node.rst @@ -28,7 +28,7 @@ Procedure #. In the upper right corner of the ECS details page, click **Stop** in the instance status area. In the displayed dialog box, click **Yes**. - .. figure:: /_static/images/en-us_image_0000001244261119.png + .. figure:: /_static/images/en-us_image_0000001518062704.png :alt: **Figure 1** ECS details page **Figure 1** ECS details page diff --git a/umn/source/nodes/synchronizing_data_with_cloud_servers.rst b/umn/source/nodes/synchronizing_data_with_cloud_servers.rst index 60381f0..ed4c06f 100644 --- a/umn/source/nodes/synchronizing_data_with_cloud_servers.rst +++ b/umn/source/nodes/synchronizing_data_with_cloud_servers.rst @@ -31,7 +31,7 @@ Procedure #. Choose **More** > **Sync Server Data** next to the node. - .. figure:: /_static/images/en-us_image_0000001243981203.png + .. figure:: /_static/images/en-us_image_0000001517743520.png :alt: **Figure 1** Synchronizing server data **Figure 1** Synchronizing server data diff --git a/umn/source/obtaining_resource_permissions.rst b/umn/source/obtaining_resource_permissions.rst deleted file mode 100644 index 560cde2..0000000 --- a/umn/source/obtaining_resource_permissions.rst +++ /dev/null @@ -1,32 +0,0 @@ -:original_name: cce_01_9994.html - -.. _cce_01_9994: - -Obtaining Resource Permissions -============================== - -CCE works closely with multiple cloud services to support computing, storage, networking, and monitoring functions. When you log in to the CCE console for the first time, CCE automatically requests permissions to access those cloud services in the region where you run your applications. Specifically: - -- Compute services - - When you create a node in a cluster, an ECS is created accordingly. The prerequisite is that CCE have obtained the permissions to access Elastic Cloud Service (ECS). - -- Storage services - - CCE allows you to mount storage to nodes and containers in a cluster. The prerequisite is that CCE have obtained the permissions to access services such as Elastic Volume Service (EVS), Scalable File Service (SFS), and Object Storage Service (OBS). - -- Networking services - - CCE allows containers in a cluster to be published as services that can be accessed by external systems. The prerequisite is that CCE have obtained the permissions to access services such as Virtual Private Cloud (VPC) and Elastic Load Balance (ELB). - -- Container and monitoring services - - CCE supports functions such as container image pulling, monitoring, and logging. The prerequisite is that CCE have obtained the permissions to access services such as SoftWare Repository for Container (SWR) and Application Operations Management (AOM). - -After you agree to delegate the permissions, an agency named **cce_admin_trust** will be created for CCE in Identity and Access Management (IAM). The system account **op_svc_cce** will be delegated the **Tenant Administrator** role to perform operations on other cloud service resources. Tenant Administrator has the permissions on all cloud services except IAM, which calls the cloud services on which CCE depends. The delegation takes effect only in the current region. For details, see `Delegating Resource Access to Another Account `__. - -To use CCE in multiple regions, you need to request cloud resource permissions in each region. You can go to the IAM console, choose **Agencies**, and click **cce_admin_trust** to view the delegation records of each region. - -.. note:: - - CCE may fail to run as expected if the Tenant Administrator role is not assigned. Therefore, do not delete or modify the **cce_admin_trust** agency when using CCE. diff --git a/umn/source/permissions_management/cluster_permissions_iam-based.rst b/umn/source/permissions_management/cluster_permissions_iam-based.rst index 93b372a..75e0914 100644 --- a/umn/source/permissions_management/cluster_permissions_iam-based.rst +++ b/umn/source/permissions_management/cluster_permissions_iam-based.rst @@ -25,7 +25,7 @@ Process Flow ------------ -.. figure:: /_static/images/en-us_image_0000001244261073.png +.. figure:: /_static/images/en-us_image_0000001517743544.png :alt: **Figure 1** Process of assigning CCE permissions **Figure 1** Process of assigning CCE permissions @@ -177,4 +177,4 @@ When RBAC and IAM policies co-exist, the backend authentication logic for open A Using clusterCert to obtain the cluster kubeconfig: cceadm/teadmin -.. |image1| image:: /_static/images/en-us_image_0000001244101107.png +.. |image1| image:: /_static/images/en-us_image_0000001518062684.png diff --git a/umn/source/permissions_management/example_designing_and_configuring_permissions_for_users_in_a_department.rst b/umn/source/permissions_management/example_designing_and_configuring_permissions_for_users_in_a_department.rst index 684fa2c..87bca61 100644 --- a/umn/source/permissions_management/example_designing_and_configuring_permissions_for_users_in_a_department.rst +++ b/umn/source/permissions_management/example_designing_and_configuring_permissions_for_users_in_a_department.rst @@ -83,4 +83,4 @@ In the previous steps, Linda and Peter have been assigned the read-only permissi By now, all the required permissions are assigned to the department members. -.. |image1| image:: /_static/images/en-us_image_0000001256348238.jpg +.. |image1| image:: /_static/images/en-us_image_0000001569182569.jpg diff --git a/umn/source/permissions_management/index.rst b/umn/source/permissions_management/index.rst index bf98b3a..a6d7451 100644 --- a/umn/source/permissions_management/index.rst +++ b/umn/source/permissions_management/index.rst @@ -11,7 +11,7 @@ Permissions Management - :ref:`Example: Designing and Configuring Permissions for Users in a Department ` - :ref:`Permission Dependency of the CCE Console ` - :ref:`Pod Security ` -- :ref:`Service Account Token Security Improvement ` +- :ref:`Service Account Token Security Improvement ` .. toctree:: :maxdepth: 1 diff --git a/umn/source/permissions_management/namespace_permissions_kubernetes_rbac-based.rst b/umn/source/permissions_management/namespace_permissions_kubernetes_rbac-based.rst index 8c42416..4c45b1c 100644 --- a/umn/source/permissions_management/namespace_permissions_kubernetes_rbac-based.rst +++ b/umn/source/permissions_management/namespace_permissions_kubernetes_rbac-based.rst @@ -19,7 +19,7 @@ You can regulate users' or user groups' access to Kubernetes resources in a sing Role and ClusterRole specify actions that can be performed on specific resources. RoleBinding and ClusterRoleBinding bind roles to specific users, user groups, or ServiceAccounts. Illustration: -.. figure:: /_static/images/en-us_image_0000001244261071.png +.. figure:: /_static/images/en-us_image_0000001517743636.png :alt: **Figure 1** Role binding **Figure 1** Role binding @@ -30,15 +30,17 @@ On the CCE console, you can assign permissions to a user or user group to access - edit (development): read and write permissions on most resources in all or selected namespaces. If this ClusterRole is configured for all namespaces, its capability is the same as the O&M permission. - admin (O&M): read and write permissions on most resources in all namespaces, and read-only permission on nodes, storage volumes, namespaces, and quota management. - cluster-admin (administrator): read and write permissions on all resources in all namespaces. +- drainage-editor: drain a node. +- drainage-viewer: view the nodal drainage status but cannot drain a node. .. _cce_10_0189__section207514572488: Cluster Permissions (IAM-based) and Namespace Permissions (Kubernetes RBAC-based) --------------------------------------------------------------------------------- -Users with different cluster permissions (assigned using IAM) have different namespace permissions (assigned using Kubernetes RBAC). :ref:`Table 1 ` lists the namespace permissions of different users. +Users with different cluster permissions (assigned using IAM) have different namespace permissions (assigned using Kubernetes RBAC). :ref:`Table 1 ` lists the namespace permissions of different users. -.. _cce_10_0189__cce_10_0187_table886210176509: +.. _cce_10_0189__en-us_topic_0000001199181174_table886210176509: .. table:: **Table 1** Differences in namespace permissions @@ -136,7 +138,7 @@ After creating a Role, you can bind the Role to a specific user, which is called The **subjects** section binds a Role with an IAM user so that the IAM user can obtain the permissions defined in the Role, as shown in the following figure. -.. figure:: /_static/images/en-us_image_0262051194.png +.. figure:: /_static/images/en-us_image_0000001518222732.png :alt: **Figure 2** A RoleBinding binds the Role to the user. **Figure 2** A RoleBinding binds the Role to the user. diff --git a/umn/source/permissions_management/permissions_overview.rst b/umn/source/permissions_management/permissions_overview.rst index 190e97f..f7f618a 100644 --- a/umn/source/permissions_management/permissions_overview.rst +++ b/umn/source/permissions_management/permissions_overview.rst @@ -29,7 +29,7 @@ CCE permissions are described as follows: In general, you configure CCE permissions in two scenarios. The first is creating and managing clusters and related resources, such as nodes. The second is creating and using Kubernetes resources in the cluster, such as workloads and Services. -.. figure:: /_static/images/en-us_image_0000001199181266.png +.. figure:: /_static/images/en-us_image_0000001569182621.png :alt: **Figure 1** Illustration on CCE permissions **Figure 1** Illustration on CCE permissions diff --git a/umn/source/permissions_management/pod_security/configuring_a_pod_security_policy.rst b/umn/source/permissions_management/pod_security/configuring_a_pod_security_policy.rst index 1ba83b4..6d618e1 100644 --- a/umn/source/permissions_management/pod_security/configuring_a_pod_security_policy.rst +++ b/umn/source/permissions_management/pod_security/configuring_a_pod_security_policy.rst @@ -5,7 +5,7 @@ Configuring a Pod Security Policy ================================= -A pod security policy (PSP) is a cluster-level resource that controls sensitive security aspects of the pod specification. The `PodSecurityPolicy `__ object in Kubernetes defines a group of conditions that a pod must comply with to be accepted by the system, as well as the default values of related fields. +A pod security policy (PSP) is a cluster-level resource that controls sensitive security aspects of the pod specification. The PodSecurityPolicy object in Kubernetes defines a group of conditions that a pod must comply with to be accepted by the system, as well as the default values of related fields. By default, the PSP access control component is enabled for clusters of v1.17.17 and a global default PSP named **psp-global** is created. You can modify the default policy (but not delete it). You can also create a PSP and bind it to the RBAC configuration. diff --git a/umn/source/permissions_management/service_account_token_security_improvement.rst b/umn/source/permissions_management/service_account_token_security_improvement.rst index 3e0dbbf..13b846e 100644 --- a/umn/source/permissions_management/service_account_token_security_improvement.rst +++ b/umn/source/permissions_management/service_account_token_security_improvement.rst @@ -1,6 +1,6 @@ -:original_name: cce_10_0477_0.html +:original_name: cce_10_0477.html -.. _cce_10_0477_0: +.. _cce_10_0477: Service Account Token Security Improvement ========================================== @@ -38,4 +38,4 @@ Run the following steps to check your CCE clusters of v1.21 and later: |image1| -.. |image1| image:: /_static/images/en-us_image_0000001402494682.png +.. |image1| image:: /_static/images/en-us_image_0000001518062816.png diff --git a/umn/source/product_bulletin/index.rst b/umn/source/product_bulletin/index.rst index beba27b..b67e229 100644 --- a/umn/source/product_bulletin/index.rst +++ b/umn/source/product_bulletin/index.rst @@ -5,20 +5,16 @@ Product Bulletin ================ -- :ref:`Risky Operations on Cluster Nodes ` - :ref:`Kubernetes Version Support Mechanism ` - :ref:`CCE Cluster Version Release Notes ` - :ref:`OS Patch Notes for Cluster Nodes ` - :ref:`Security Vulnerability Responses ` -- :ref:`Service Account Token Security Improvement ` .. toctree:: :maxdepth: 1 :hidden: - risky_operations_on_cluster_nodes kubernetes_version_support_mechanism cce_cluster_version_release_notes os_patch_notes_for_cluster_nodes security_vulnerability_responses/index - service_account_token_security_improvement diff --git a/umn/source/product_bulletin/os_patch_notes_for_cluster_nodes.rst b/umn/source/product_bulletin/os_patch_notes_for_cluster_nodes.rst index 3992eca..aa6534c 100644 --- a/umn/source/product_bulletin/os_patch_notes_for_cluster_nodes.rst +++ b/umn/source/product_bulletin/os_patch_notes_for_cluster_nodes.rst @@ -8,16 +8,80 @@ OS Patch Notes for Cluster Nodes Nodes in Hybrid Clusters ------------------------ -CCE nodes in Hybrid clusters can run on EulerOS 2.5, EulerOS 2.9 and CentOS 7.7. The following table lists the supported patches for these OSs. +CCE nodes in Hybrid clusters can run on EulerOS 2.5, EulerOS 2.9, CentOS 7.7 and Ubuntu 22.04. The following table lists the supported patches for these OSs. .. table:: **Table 1** Node OS patches - ========================= ========================================= - OS Patch - ========================= ========================================= - EulerOS release 2.0 (SP5) 3.10.0-862.14.1.5.h687.eulerosv2r7.x86_64 - EulerOS release 2.0 (SP9) 4.18.0-147.5.1.6.h766.eulerosv2r9.x86_64 - CentOS Linux release 7.7 3.10.0-1160.76.1.el7.x86_64 - ========================= ========================================= + +--------------------------+-----------------+-------------------------------------------+ + | OS | Cluster Version | Latest Kernel | + +==========================+=================+===========================================+ + | EulerOS release 2.5 | v1.25 | 3.10.0-862.14.1.5.h687.eulerosv2r7.x86_64 | + +--------------------------+-----------------+-------------------------------------------+ + | | v1.23 | 3.10.0-862.14.1.5.h687.eulerosv2r7.x86_64 | + +--------------------------+-----------------+-------------------------------------------+ + | | v1.21 | 3.10.0-862.14.1.5.h687.eulerosv2r7.x86_64 | + +--------------------------+-----------------+-------------------------------------------+ + | | v1.19 | 3.10.0-862.14.1.5.h687.eulerosv2r7.x86_64 | + +--------------------------+-----------------+-------------------------------------------+ + | EulerOS release 2.9 | v1.25 | 4.18.0-147.5.1.6.h766.eulerosv2r9.x86_64 | + +--------------------------+-----------------+-------------------------------------------+ + | | v1.23 | 4.18.0-147.5.1.6.h766.eulerosv2r9.x86_64 | + +--------------------------+-----------------+-------------------------------------------+ + | | v1.21 | 4.18.0-147.5.1.6.h766.eulerosv2r9.x86_64 | + +--------------------------+-----------------+-------------------------------------------+ + | | v1.19 | 4.18.0-147.5.1.6.h766.eulerosv2r9.x86_64 | + +--------------------------+-----------------+-------------------------------------------+ + | CentOS Linux release 7.7 | v1.25 | 3.10.0-1160.76.1.el7.x86_64 | + +--------------------------+-----------------+-------------------------------------------+ + | | v1.23 | 3.10.0-1160.76.1.el7.x86_64 | + +--------------------------+-----------------+-------------------------------------------+ + | | v1.21 | 3.10.0-1160.76.1.el7.x86_64 | + +--------------------------+-----------------+-------------------------------------------+ + | | v1.19 | 3.10.0-1160.76.1.el7.x86_64 | + +--------------------------+-----------------+-------------------------------------------+ + | Ubuntu 22.04 | v1.25 | 5.15.0-53-generic | + +--------------------------+-----------------+-------------------------------------------+ + +.. table:: **Table 2** Mappings between BMS node OS versions and cluster versions + + +-----------------------------------------+-----------------+------------------------------------------+ + | OS Version | Cluster Version | Latest Kernel | + +=========================================+=================+==========================================+ + | EulerOS release 2.9 (bare metal server) | v1.25 | 4.18.0-147.5.1.6.h766.eulerosv2r9.x86_64 | + +-----------------------------------------+-----------------+------------------------------------------+ + | | v1.23 | 4.18.0-147.5.1.6.h766.eulerosv2r9.x86_64 | + +-----------------------------------------+-----------------+------------------------------------------+ + +.. table:: **Table 3** Mappings between OS versions and network model + + +--------------------------+-----------------+-------------+----------------+--------------------------+ + | OS Version | Cluster Version | VPC Network | Tunnel Network | Cloud Native Network 2.0 | + +==========================+=================+=============+================+==========================+ + | Ubuntu 22.04 | v1.25 | Y | x | Y | + +--------------------------+-----------------+-------------+----------------+--------------------------+ + | CentOS Linux release 7.7 | v1.25 | Y | Y | Y | + +--------------------------+-----------------+-------------+----------------+--------------------------+ + | | v1.23 | Y | Y | Y | + +--------------------------+-----------------+-------------+----------------+--------------------------+ + | | v1.21 | Y | Y | Y | + +--------------------------+-----------------+-------------+----------------+--------------------------+ + | | v1.19 | Y | Y | Y | + +--------------------------+-----------------+-------------+----------------+--------------------------+ + | EulerOS release 2.9 | v1.25 | Y | Y | Y | + +--------------------------+-----------------+-------------+----------------+--------------------------+ + | | v1.23 | Y | Y | Y | + +--------------------------+-----------------+-------------+----------------+--------------------------+ + | | v1.21 | Y | Y | Y | + +--------------------------+-----------------+-------------+----------------+--------------------------+ + | | v1.19 | Y | Y | Y | + +--------------------------+-----------------+-------------+----------------+--------------------------+ + | EulerOS release 2.5 | v1.25 | Y | Y | Y | + +--------------------------+-----------------+-------------+----------------+--------------------------+ + | | v1.23 | Y | Y | Y | + +--------------------------+-----------------+-------------+----------------+--------------------------+ + | | v1.21 | Y | Y | Y | + +--------------------------+-----------------+-------------+----------------+--------------------------+ + | | v1.19 | Y | Y | Y | + +--------------------------+-----------------+-------------+----------------+--------------------------+ The OS patches and verification results will be updated from time to time. You can update the operating system based on your needs. diff --git a/umn/source/product_bulletin/risky_operations_on_cluster_nodes.rst b/umn/source/product_bulletin/risky_operations_on_cluster_nodes.rst deleted file mode 100644 index 4595197..0000000 --- a/umn/source/product_bulletin/risky_operations_on_cluster_nodes.rst +++ /dev/null @@ -1,48 +0,0 @@ -:original_name: cce_bulletin_0054.html - -.. _cce_bulletin_0054: - -Risky Operations on Cluster Nodes -================================= - -Precautions for Using a Cluster -------------------------------- - -- When performing operations such as creating, deleting, and scaling clusters, do not change user permission in the Identity and Access Management (IAM) console. Otherwise, these operations may fail. -- The containerized network canal of CCE nodes uses a CIDR block as the CIDR block of the container network. This CIDR block can be configured during cluster creation and defaults to 172.16.0.0/16. The Docker service creates a docker0 bridge by default. The default docker0 address is 172.17.0.1. When creating a cluster, ensure that the CIDR block of the VPC in the cluster is different from the CIDR blocks of the container network docker0 bridge. If VPC peering connections are used, also ensure that the CIDR block of the peer VPC is different from the CIDR blocks of the container network docker0 bridge. -- For a cluster of Kubernetes v1.15, the DNS server of nodes in the cluster uses the DNS address in the VPC subnet, not the CoreDNS address of Kubernetes. Ensure that the DNS address in the subnet exists and is configurable. -- For a cluster of Kubernetes v1.17, a single-plane network is used for nodes. When a multi-plane network is used, if you bind a NIC to an ECS, you need to configure the NIC information on the node and restart the NIC. -- Do not modify the security groups, Elastic Volume Service (EVS) disks, and other resources created by CCE. Otherwise, clusters may not function properly. The resources created by CCE are labeled **cce**, for example, **cce-evs-jwh9pcl7-***\***. -- When adding a node, ensure that the DNS server in the subnet can resolve the domain name of the corresponding service. Otherwise, the node cannot be installed properly. - -Precautions for Using a Node ----------------------------- - -Some of the resources on the node need to run some necessary Kubernetes system components and resources to make the node as part of your cluster. Therefore, the total number of node resources and the number of assignable node resources in Kubernetes are different. The larger the node specifications, the more the containers deployed on the node. Therefore, Kubernetes needs to reserve more resources. - -To ensure node stability, CCE cluster nodes reserve some resources for Kubernetes components (such as kubelet, kube-proxy, and docker) based on node specifications. - -.. note:: - - You are advised not to install software or modify the operating system (OS) configuration on a cluster node. This may cause exceptions on Kubernetes components installed on the node, and make the node unavailable. - -Risky Operations on Nodes -------------------------- - -After logging in to a node created by CCE, do not perform the following operations. Otherwise, the node will become unready. - -.. table:: **Table 1** Operations that will cause nodes to become unready - - +----+--------------------------------------------------------------------------+-------------------------------------------------------------------------------+------------------------------------------------------------------------------------------+ - | SN | Risky Operation | Impact | Solution | - +====+==========================================================================+===============================================================================+==========================================================================================+ - | 1 | Reinstall the operating system using the original image or another image | The node will become unready. | Delete the node and buy a new node. | - +----+--------------------------------------------------------------------------+-------------------------------------------------------------------------------+------------------------------------------------------------------------------------------+ - | 2 | Modify OS configuration | The node will become unready. | Restore the original configuration or buy the node again. | - +----+--------------------------------------------------------------------------+-------------------------------------------------------------------------------+------------------------------------------------------------------------------------------+ - | 3 | Delete the **opt** directory, **/var/paas** directory, or a data disk | The node will become unready. | Delete the node and buy a new node. | - +----+--------------------------------------------------------------------------+-------------------------------------------------------------------------------+------------------------------------------------------------------------------------------+ - | 4 | Format and partition a node disk | The node will become unready. | Delete the node and buy a new node. | - +----+--------------------------------------------------------------------------+-------------------------------------------------------------------------------+------------------------------------------------------------------------------------------+ - | 5 | Modify a security group | The node will become unready or the cluster will exhibit unexpected behavior. | Correct the security group settings based on security group settings of normal clusters. | - +----+--------------------------------------------------------------------------+-------------------------------------------------------------------------------+------------------------------------------------------------------------------------------+ diff --git a/umn/source/product_bulletin/service_account_token_security_improvement.rst b/umn/source/product_bulletin/service_account_token_security_improvement.rst deleted file mode 100644 index 9f6ba3c..0000000 --- a/umn/source/product_bulletin/service_account_token_security_improvement.rst +++ /dev/null @@ -1,41 +0,0 @@ -:original_name: cce_10_0477.html - -.. _cce_10_0477: - -Service Account Token Security Improvement -========================================== - -In clusters earlier than v1.21, a token is obtained by mounting the secret of the service account to a pod. Tokens obtained this way are permanent. This approach is no longer recommended starting from version 1.21. Service accounts will stop auto creating secrets in clusters from version 1.25. - -In clusters of version 1.21 or later, you can use the `TokenRequest `__ API to obtain the token and use the projected volume to mount the token to the pod. Such tokens are valid for a fixed period (one hour by default). Before expiration, Kubelet refreshes the token to ensure that the pod always uses a valid token. When the mounting pod is deleted, the token automatically becomes invalid. This approach is implemented by the `BoundServiceAccountTokenVolume `__ feature to improve the token security of the service account. Kubernetes clusters of v1.21 and later enables this approach by default. - -For smooth transition, the community extends the token validity period to one year by default. After one year, the token becomes invalid, and clients that do not support certificate reloading cannot access the API server. It is recommended that clients of earlier versions be upgraded as soon as possible. Otherwise, service faults may occur. - -If you use a Kubernetes client of a to-be-outdated version, the certificate reloading may fail. Versions of officially supported Kubernetes client libraries able to reload tokens are as follows: - -- Go: >= v0.15.7 -- Python: >= v12.0.0 -- Java: >= v9.0.0 -- Javascript: >= v0.10.3 -- Ruby: master branch -- Haskell: v0.3.0.0 -- C#: >= 7.0.5 - -For details, visit https://github.com/kubernetes/enhancements/tree/master/keps/sig-auth/1205-bound-service-account-tokens. - -.. note:: - - If you need a token that never expires, you can also `manually manage secrets for service accounts `__. Although a permanent service account token can be manually created, you are advised to use a short-lived token by calling the `TokenRequest `__ API for higher security. - -Diagnosis ---------- - -Run the following steps to check your CCE clusters of v1.21 and later: - -#. Use kubectl to connect to the cluster and run the **kubectl get --raw "/metrics" \| grep stale** command to query the metrics. Check the metric named **serviceaccount_stale_tokens_total**. - - If the value is greater than 0, some workloads in the cluster may be using an earlier client-go version. In this case, check whether this problem occurs in your deployed applications. If yes, upgrade client-go to the version specified by the community as soon as possible. The version must be at least two major versions of the CCE cluster. For example, if your cluster version is 1.23, the Kubernetes dependency library version must be at least 1.19. - - |image1| - -.. |image1| image:: /_static/images/en-us_image_0000001402494682.png diff --git a/umn/source/service_overview/application_scenarios/auto_scaling_in_seconds.rst b/umn/source/service_overview/application_scenarios/auto_scaling_in_seconds.rst new file mode 100644 index 0000000..144547a --- /dev/null +++ b/umn/source/service_overview/application_scenarios/auto_scaling_in_seconds.rst @@ -0,0 +1,44 @@ +:original_name: cce_productdesc_0015.html + +.. _cce_productdesc_0015: + +Auto Scaling in Seconds +======================= + +Application Scenarios +--------------------- + +- Shopping apps and websites, especially during promotions and flash sales +- Live streaming, where service loads often fluctuate +- Games, where many players may go online in certain time periods + +Benefits +-------- + +CCE auto adjusts capacity to cope with service surges according to the policies you set. CCE adds or reduces cloud servers and containers to scale your cluster and workloads. Your applications will always have the right resources at the right time. + +Advantages +---------- + +- Flexible + + Allows diverse types of scaling policies and scales containers within seconds once triggered. + +- Highly available + + Monitors pod running and replaces unhealthy pods with new ones. + +- Lower costs + + Bills you only for the scaled cloud servers as you use. + +Related Services +---------------- + +HPA (Horizontal Pod Autoscaling) + CA (Cluster AutoScaling) + + +.. figure:: /_static/images/en-us_image_0000001550245869.png + :alt: **Figure 1** How auto scaling works + + **Figure 1** How auto scaling works diff --git a/umn/source/service_overview/application_scenarios/devops_and_ci_cd.rst b/umn/source/service_overview/application_scenarios/devops_and_ci_cd.rst new file mode 100644 index 0000000..2aa7504 --- /dev/null +++ b/umn/source/service_overview/application_scenarios/devops_and_ci_cd.rst @@ -0,0 +1,42 @@ +:original_name: cce_productdesc_0017.html + +.. _cce_productdesc_0017: + +DevOps and CI/CD +================ + +Application Scenario +-------------------- + +You may receive a lot feedback and requirements for your apps or services. You may want to boost user experience with new features. Continuous integration (CI) and delivery (CD) can help. CI/CD automates builds, tests, and merges, making app delivery faster. + +Benefits +-------- + +CCE works with SWR to support DevOps and CI/CD. A pipeline automates coding, image build, grayscale release, and deployment based on code sources. Existing CI/CD systems can connect to CCE to containerize legacy applications. + +Advantages +---------- + +- Efficient process + + Reduces scripting workload by more than 80% through streamlined processes. + +- Flexible integration + + Provides various APIs to integrate with existing CI/CD systems for in-depth customization. + +- High performance + + Enables flexible scheduling with a containerized architecture. + +Related Services +---------------- + +Software Repository for Container (SWR), Object Storage Service (OBS), Virtual Private Network (VPN) + + +.. figure:: /_static/images/en-us_image_0000001499725850.png + :alt: **Figure 1** How DevOps works + + **Figure 1** How DevOps works diff --git a/umn/source/service_overview/application_scenarios/hybrid_cloud_architecture.rst b/umn/source/service_overview/application_scenarios/hybrid_cloud_architecture.rst new file mode 100644 index 0000000..e7f088b --- /dev/null +++ b/umn/source/service_overview/application_scenarios/hybrid_cloud_architecture.rst @@ -0,0 +1,60 @@ +:original_name: cce_productdesc_0018.html + +.. _cce_productdesc_0018: + +Hybrid Cloud Architecture +========================= + +Application Scenarios +--------------------- + +- Multi-cloud deployment and disaster recovery + + Running apps in containers on different clouds can ensure high availability. When a cloud is down, other clouds respond and serve. + +- Traffic distribution and auto scaling + + Large organizations often span cloud facilities in different regions. They need to communicate and auto scale — start small and then scale as system load grows. CCE takes care of these for you, cutting the costs of maintaining facilities. + +- Migration to the cloud and database hosting + + Industries like finance and security have a top concern on data protection. They want to run critical systems in local IDCs while moving others to the cloud. They also expect one unified dashboard to manage all systems. + +- Environment decoupling + + To ensure IP security, you can decouple development from production. Set up one on the public cloud and the other in the local IDC. + +Benefits +-------- + +Your apps and data can flow free on and off the cloud. Resource scheduling and DR are much easier, thanks to environment-independent containers. CCE connects private and public clouds for you to run containers on them. + +Advantages +---------- + +- On-cloud DR + + Multicloud prevents systems from outages. When a cloud is faulty, CCE auto diverts traffic to other clouds to ensure service continuity. + +- Automatic traffic distribution + + CCE reduces access latency by processing user requests on the nodes nearest to the users. Overloaded apps in local IDCs can be burst to the cloud backed by auto scaling. + +- Decoupling and sharing + + CCE decouples data, environments, and compute capacity. Sensitive data vs general data. Development vs production. Compute-intensive services vs general services. Apps running on-premises can burst to the cloud. Your resources on and off the cloud can be better used. + +- Lower costs + + Public cloud resource pools, backed by auto scaling, can respond to load spikes in time. Manual operations are no longer needed and you can save big. + +Related Services +---------------- + +Elastic Cloud Server (ECS), Direct Connect (DC), Virtual Private Network (VPN), SoftWare Repository for Container (SWR) + + +.. figure:: /_static/images/en-us_image_0000001626725269.png + :alt: **Figure 1** How hybrid cloud works + + **Figure 1** How hybrid cloud works diff --git a/umn/source/service_overview/application_scenarios/index.rst b/umn/source/service_overview/application_scenarios/index.rst new file mode 100644 index 0000000..9fda3cd --- /dev/null +++ b/umn/source/service_overview/application_scenarios/index.rst @@ -0,0 +1,20 @@ +:original_name: cce_productdesc_0007.html + +.. _cce_productdesc_0007: + +Application Scenarios +===================== + +- :ref:`Infrastructure and Containerized Application Management ` +- :ref:`Auto Scaling in Seconds ` +- :ref:`DevOps and CI/CD ` +- :ref:`Hybrid Cloud Architecture ` + +.. toctree:: + :maxdepth: 1 + :hidden: + + infrastructure_and_containerized_application_management + auto_scaling_in_seconds + devops_and_ci_cd + hybrid_cloud_architecture diff --git a/umn/source/service_overview/application_scenarios/infrastructure_and_containerized_application_management.rst b/umn/source/service_overview/application_scenarios/infrastructure_and_containerized_application_management.rst new file mode 100644 index 0000000..0bab731 --- /dev/null +++ b/umn/source/service_overview/application_scenarios/infrastructure_and_containerized_application_management.rst @@ -0,0 +1,43 @@ +:original_name: cce_productdesc_0020.html + +.. _cce_productdesc_0020: + +Infrastructure and Containerized Application Management +======================================================= + +Application Scenario +-------------------- + +In CCE, you can run clusters with x86 and Arm nodes. Create and manage Kubernetes clusters. Deploy containerized applications in them. All done in CCE. + + +.. figure:: /_static/images/en-us_image_0000001550125865.png + :alt: **Figure 1** CCE cluster + + **Figure 1** CCE cluster + +Benefits +-------- + +Containerization requires less resources to deploy application. Services are not uninterrupted during upgrades. + +Advantages +---------- + +- Multiple types of workloads + + Runs Deployments, StatefulSets, DaemonSets, jobs, and cron jobs to meet different needs. + +- Application upgrade + + Upgrades your apps in replace or rolling mode (by proportion or by number of pods), or rolls back the upgrades. + +- Auto scaling + + Auto scales your nodes and workloads according to the policies you set. + + +.. figure:: /_static/images/en-us_image_0000001499246158.png + :alt: **Figure 2** Workload + + **Figure 2** Workload diff --git a/umn/source/service_overview/basic_concepts/basic_concepts.rst b/umn/source/service_overview/basic_concepts/basic_concepts.rst new file mode 100644 index 0000000..b78d73b --- /dev/null +++ b/umn/source/service_overview/basic_concepts/basic_concepts.rst @@ -0,0 +1,233 @@ +:original_name: cce_productdesc_0011.html + +.. _cce_productdesc_0011: + +Basic Concepts +============== + +CCE provides highly scalable, high-performance, enterprise-class Kubernetes clusters and supports Docker containers. With CCE, you can easily deploy, manage, and scale containerized applications in the cloud. + +The graphical CCE console enables E2E user experiences. In addition, CCE supports native Kubernetes APIs and kubectl. Before using CCE, you are advised to understand related basic concepts. + +Cluster +------- + +A cluster is a group of one or more cloud servers (also known as nodes) in the same subnet. It has all the cloud resources (including VPCs and compute resources) required for running containers. + +Node +---- + +A node is a cloud server (virtual or physical machine) running an instance of the Docker Engine. Containers are deployed, run, and managed on nodes. The node agent (kubelet) runs on each node to manage container instances on the node. The number of nodes in a cluster can be scaled. + +Node Pool +--------- + +A node pool contains one node or a group of nodes with identical configuration in a cluster. + +Virtual Private Cloud (VPC) +--------------------------- + +A VPC is a logically isolated virtual network that facilitates secure internal network management and configurations. Resources in the same VPC can communicate with each other, but those in different VPCs cannot communicate with each other by default. VPCs provide the same network functions as physical networks and also advanced network services, such as elastic IP addresses and security groups. + +Security Group +-------------- + +A security group is a collection of access control rules for ECSs that have the same security protection requirements and are mutually trusted in a VPC. After a security group is created, you can create different access rules for the security group to protect the ECSs that are added to this security group. + +**Relationship Between Clusters, VPCs, Security Groups, and Nodes** + +As shown in :ref:`Figure 1 `, a region may comprise multiple VPCs. A VPC consists of one or more subnets. The subnets communicate with each other through a subnet gateway. A cluster is created in a subnet. There are three scenarios: + +- Different clusters are created in different VPCs. +- Different clusters are created in the same subnet. +- Different clusters are created in different subnets. + +.. _cce_productdesc_0011__en-us_topic_0000001550245837_fig96091540175212: + +.. figure:: /_static/images/en-us_image_0000001499565934.png + :alt: **Figure 1** Relationship between clusters, VPCs, security groups, and nodes + + **Figure 1** Relationship between clusters, VPCs, security groups, and nodes + +Pod +--- + +A pod is the smallest and simplest unit in the Kubernetes object model that you create or deploy. A pod encapsulates an application container (or, in some cases, multiple containers), storage resources, a unique network IP address, and options that govern how the containers should run. + + +.. figure:: /_static/images/en-us_image_0000001550365705.png + :alt: **Figure 2** Pod + + **Figure 2** Pod + +Container +--------- + +A container is a running instance of a Docker image. Multiple containers can run on one node. Containers are actually software processes. Unlike traditional software processes, containers have separate namespace and do not run directly on a host. + + +.. figure:: /_static/images/en-us_image_0000001550445737.png + :alt: **Figure 3** Relationships between pods, containers, and nodes + + **Figure 3** Relationships between pods, containers, and nodes + +Workload +-------- + +A workload is an application running on Kubernetes. No matter how many components are there in your workload, you can run it in a group of Kubernetes pods. A workload is an abstract model of a group of pods in Kubernetes. Workloads classified in Kubernetes include Deployments, StatefulSets, DaemonSets, jobs, and cron jobs. + +- **Deployment**: Pods are completely independent of each other and functionally identical. They feature auto scaling and rolling upgrade. Typical examples include Nginx and WordPress. +- **StatefulSet**: Pods are not completely independent of each other. They have stable persistent storage, and feature orderly deployment and deletion. Typical examples include MySQL-HA and etcd. +- **DaemonSet**: A DaemonSet ensures that all or some nodes run a pod. It is applicable to pods running on every node. Typical examples include Ceph, Fluentd, and Prometheus Node Exporter. +- **Job**: It is a one-time task that runs to completion. It can be executed immediately after being created. Before creating a workload, you can execute a job to upload an image to the image repository. +- **Cron job**: It runs a job periodically on a given schedule. You can perform time synchronization for all active nodes at a fixed time point. + + +.. figure:: /_static/images/en-us_image_0000001550125873.png + :alt: **Figure 4** Relationship between workloads and pods + + **Figure 4** Relationship between workloads and pods + +Image +----- + +Docker creates an industry standard for packaging containerized applications. Docker images are like templates that include everything needed to run containers, and are used to create Docker containers. In other words, Docker image is a special file system that includes everything needed to run containers: programs, libraries, resources, and configuration files. It also contains configuration parameters (such as anonymous volumes, environment variables, and users) required within a container runtime. An image does not contain any dynamic data. Its content remains unchanged after being built. When deploying containerized applications, you can use images from Docker Hub, SoftWare Repository for Container (SWR), and your private image registries. For example, a Docker image can contain a complete Ubuntu operating system, in which only the required programs and dependencies are installed. + +Images become containers at runtime, that is, containers are created from images. Containers can be created, started, stopped, deleted, and suspended. + + +.. figure:: /_static/images/en-us_image_0000001499406030.png + :alt: **Figure 5** Relationship between images, containers, and workloads + + **Figure 5** Relationship between images, containers, and workloads + +Namespace +--------- + +A namespace is an abstract collection of resources and objects. It enables resources to be organized into non-overlapping groups. Multiple namespaces can be created inside a cluster and isolated from each other. This enables namespaces to share the same cluster services without affecting each other. Examples: + +- You can deploy workloads in a development environment into one namespace, and deploy workloads in a test environment into another namespace. +- Pods, Services, ReplicationControllers, and Deployments belong to a namespace (named **default**, by default), whereas nodes and PersistentVolumes do not belong to any namespace. + +Service +------- + +A Service is an abstract method that exposes a group of applications running on a pod as network services. + +Kubernetes provides you with a service discovery mechanism without modifying applications. In this mechanism, Kubernetes provides pods with their own IP addresses and a single DNS for a group of pods, and balances load between them. + +Kubernetes allows you to specify a Service of a required type. The values and actions of different types of Services are as follows: + +- **ClusterIP**: ClusterIP Service, as the default Service type, is exposed through the internal IP address of the cluster. If this mode is selected, Services can be accessed only within the cluster. +- **NodePort**: NodePort Services are exposed through the IP address and static port of each node. A ClusterIP Service, to which a NodePort Service will route, is automatically created. By sending a request to :, you can access a NodePort Service from outside of a cluster. +- **LoadBalancer (ELB)**: LoadBalancer (ELB) Services are exposed by using load balancers of the cloud provider. External load balancers can route to NodePort and ClusterIP Services. + +Layer-7 Load Balancing (Ingress) +-------------------------------- + +An ingress is a set of routing rules for requests entering a cluster. It provides Services with URLs, load balancing, SSL termination, and HTTP routing for external access to the cluster. + +Network Policy +-------------- + +Network policies provide policy-based network control to isolate applications and reduce the attack surface. A network policy uses label selectors to simulate traditional segmented networks and controls traffic between them and traffic from outside. + +ConfigMap +--------- + +A ConfigMap is used to store configuration data or configuration files as key-value pairs. ConfigMaps are similar to secrets, but provide a means of working with strings that do not contain sensitive information. + +Secret +------ + +Secrets resolve the configuration problem of sensitive data such as passwords, tokens, and keys, and will not expose the sensitive data in images or pod specs. A secret can be used as a volume or an environment variable. + +Label +----- + +A label is a key-value pair and is associated with an object, for example, a pod. Labels are used to identify special features of objects and are meaningful to users. However, labels have no direct meaning to the kernel system. + +Label Selector +-------------- + +Label selector is the core grouping mechanism of Kubernetes. It identifies a group of resource objects with the same characteristics or attributes through the label selector client or user. + +Annotation +---------- + +Annotations are defined in key-value pairs as labels are. + +Labels have strict naming rules. They define the metadata of Kubernetes objects and are used by label selectors. + +Annotations are additional user-defined information for external tools to search for a resource object. + +PersistentVolume +---------------- + +A PersistentVolume (PV) is a network storage in a cluster. Similar to a node, it is also a cluster resource. + +PersistentVolumeClaim +--------------------- + +A PV is a storage resource, and a PersistentVolumeClaim (PVC) is a request for a PV. PVC is similar to pod. Pods consume node resources, and PVCs consume PV resources. Pods request CPU and memory resources, and PVCs request data volumes of a specific size and access mode. + +Auto Scaling - HPA +------------------ + +Horizontal Pod Autoscaling (HPA) is a function that implements horizontal scaling of pods in Kubernetes. The scaling mechanism of ReplicationController can be used to scale your Kubernetes clusters. + +Affinity and Anti-Affinity +-------------------------- + +If an application is not containerized, multiple components of the application may run on the same virtual machine and processes communicate with each other. However, in the case of containerization, software processes are packed into different containers and each container has its own lifecycle. For example, the transaction process is packed into a container while the monitoring/logging process and local storage process are packed into other containers. If closely related container processes run on distant nodes, routing between them will be costly and slow. + +- Affinity: Containers are scheduled onto the nearest node. For example, if application A and application B frequently interact with each other, it is necessary to use the affinity feature to keep the two applications as close as possible or even let them run on the same node. In this way, no performance loss will occur due to slow routing. +- Anti-affinity: Instances of the same application spread across different nodes to achieve higher availability. Once a node is down, instances on other nodes are not affected. For example, if an application has multiple replicas, it is necessary to use the anti-affinity feature to deploy the replicas on different nodes. In this way, no single point of failure will occur. + +Node Affinity +------------- + +By selecting labels, you can schedule pods to specific nodes. + +Node Anti-Affinity +------------------ + +By selecting labels, you can prevent pods from being scheduled to specific nodes. + +Pod Affinity +------------ + +You can deploy pods onto the same node to reduce consumption of network resources. + +Pod Anti-Affinity +----------------- + +You can deploy pods onto different nodes to reduce the impact of system breakdowns. Anti-affinity deployment is also recommended for workloads that may interfere with each other. + +Resource Quota +-------------- + +Resource quotas are used to limit the resource usage of users. + +Resource Limit (LimitRange) +--------------------------- + +By default, all containers in Kubernetes have no CPU or memory limit. LimitRange (**limits** for short) is used to add a resource limit to a namespace, including the minimum, maximum, and default amounts of resources. When a pod is created, resources are allocated according to the **limits** parameters. + +Environment Variable +-------------------- + +An environment variable is a variable whose value can affect the way a running container will behave. A maximum of 30 environment variables can be defined at container creation time. You can modify environment variables even after workloads are deployed, increasing flexibility in workload configuration. + +The function of setting environment variables on CCE is the same as that of specifying ENV in a Dockerfile. + +Chart +----- + +For your Kubernetes clusters, you can use `Helm `__ to manage software packages, which are called charts. Helm is to Kubernetes what the apt command is to Ubuntu or what the yum command is to CentOS. Helm can quickly search for, download, and install charts. + +Charts are a Helm packaging format. It describes only a group of related cluster resource definitions, not a real container image package. A Helm chart contains only a series of YAML files used to deploy Kubernetes applications. You can customize some parameter settings in a Helm chart. When installing a chart, Helm deploys resources in the cluster based on the YAML files defined in the chart. Related container images are not included in the chart but are pulled from the image repository defined in the YAML files. + +Application developers need to push container image packages to the image repository, use Helm charts to package dependencies, and preset some key parameters to simplify application deployment. + +Helm directly installs applications and their dependencies in the cluster based on the YAML files in a chart. Application users can search for, install, upgrade, roll back, and uninstall applications without defining complex deployment files. diff --git a/umn/source/service_overview/basic_concepts/index.rst b/umn/source/service_overview/basic_concepts/index.rst new file mode 100644 index 0000000..35bbcfd --- /dev/null +++ b/umn/source/service_overview/basic_concepts/index.rst @@ -0,0 +1,18 @@ +:original_name: cce_productdesc_0004.html + +.. _cce_productdesc_0004: + +Basic Concepts +============== + +- :ref:`Basic Concepts ` +- :ref:`Mappings Between CCE and Kubernetes Terms ` +- :ref:`Regions and AZs ` + +.. toctree:: + :maxdepth: 1 + :hidden: + + basic_concepts + mappings_between_cce_and_kubernetes_terms + regions_and_azs diff --git a/umn/source/service_overview/basic_concepts/mappings_between_cce_and_kubernetes_terms.rst b/umn/source/service_overview/basic_concepts/mappings_between_cce_and_kubernetes_terms.rst new file mode 100644 index 0000000..a1763d9 --- /dev/null +++ b/umn/source/service_overview/basic_concepts/mappings_between_cce_and_kubernetes_terms.rst @@ -0,0 +1,52 @@ +:original_name: cce_productdesc_0010.html + +.. _cce_productdesc_0010: + +Mappings Between CCE and Kubernetes Terms +========================================= + +Kubernetes (K8s) is an open-source system for automating deployment, scaling, and management of container clusters. It is a container orchestration tool and a leading solution based on the distributed architecture of the container technology. Kubernetes is built on the open-source Docker technology that automates deployment, resource scheduling, service discovery, and dynamic scaling of containerized applications. + +This topic describes the mappings between CCE and Kubernetes terms. + +.. table:: **Table 1** Mappings between CCE and Kubernetes terms + + ================================ ===================== + CCE Kubernetes + ================================ ===================== + Cluster Cluster + Node Node + Node pool NodePool + Container Container + Image Image + Namespace Namespace + Deployment Deployment + StatefulSet StatefulSet + DaemonSet DaemonSet + Job Job + Cron job CronJob + Pod Pod + Service Service + ClusterIP Cluster IP + NodePort NodePort + LoadBalancer LoadBalancer + Layer-7 load balancing (ingress) Ingress + Network policy NetworkPolicy + Chart Template + ConfigMap ConfigMap + Secret Secret + Label Label + Label selector LabelSelector + Annotation Annotation + Volume PersistentVolume + PersistentVolumeClaim PersistentVolumeClaim + Auto scaling HPA + Node affinity NodeAffinity + Node anti-affinity NodeAntiAffinity + Pod affinity PodAffinity + Pod anti-affinity PodAntiAffinity + Webhook Webhook + Endpoint Endpoint + Quota Resource Quota + Resource limit Limit Range + ================================ ===================== diff --git a/umn/source/service_overview/basic_concepts/regions_and_azs.rst b/umn/source/service_overview/basic_concepts/regions_and_azs.rst new file mode 100644 index 0000000..c34cde6 --- /dev/null +++ b/umn/source/service_overview/basic_concepts/regions_and_azs.rst @@ -0,0 +1,38 @@ +:original_name: cce_productdesc_0012.html + +.. _cce_productdesc_0012: + +Regions and AZs +=============== + +Definition +---------- + +A region and availability zone (AZ) identify the location of a data center. You can create resources in a specific region and AZ. + +- Regions are divided based on geographical location and network latency. Public services, such as Elastic Cloud Server (ECS), Elastic Volume Service (EVS), Object Storage Service (OBS), Virtual Private Cloud (VPC), Elastic IP (EIP), and Image Management Service (IMS), are shared within the same region. Regions are classified as universal regions and dedicated regions. A universal region provides universal cloud services for common domains. A dedicated region provides services of the same type only or for specific domains. +- An AZ contains one or more physical data centers. Each AZ has independent cooling, fire extinguishing, moisture-proof, and electricity facilities. Within an AZ, computing, network, storage, and other resources are logically divided into multiple clusters. AZs in a region are interconnected through high-speed optic fibers. This is helpful if you will deploy systems across AZs to achieve higher availability. + +Cloud services are available in many regions around the world. You can select a region and AZ as needed. + +How to Select a Region? +----------------------- + +When selecting a region, consider the following factors: + +- Location + + Select a region close to you or your target users to reduce network latency and improve access rate. + +Selecting an AZ +--------------- + +When deploying resources, consider your applications' requirements on disaster recovery (DR) and network latency. + +- For high DR capability, deploy resources in different AZs within the same region. +- For lower network latency, deploy resources in the same AZ. + +Regions and Endpoints +--------------------- + +When using an API to access resources, you must specify a region and endpoint. For more information about regions and endpoints, see `Regions and Endpoints `__. diff --git a/umn/source/service_overview/index.rst b/umn/source/service_overview/index.rst new file mode 100644 index 0000000..b85196a --- /dev/null +++ b/umn/source/service_overview/index.rst @@ -0,0 +1,26 @@ +:original_name: en-us_topic_0000001550437509.html + +.. _en-us_topic_0000001550437509: + +Service Overview +================ + +- :ref:`What Is Cloud Container Engine? ` +- :ref:`Product Advantages ` +- :ref:`Application Scenarios ` +- :ref:`Notes and Constraints ` +- :ref:`Permissions ` +- :ref:`Basic Concepts ` +- :ref:`Related Services ` + +.. toctree:: + :maxdepth: 1 + :hidden: + + what_is_cloud_container_engine + product_advantages + application_scenarios/index + notes_and_constraints + permissions + basic_concepts/index + related_services diff --git a/umn/source/service_overview/notes_and_constraints.rst b/umn/source/service_overview/notes_and_constraints.rst new file mode 100644 index 0000000..b19d8c7 --- /dev/null +++ b/umn/source/service_overview/notes_and_constraints.rst @@ -0,0 +1,163 @@ +:original_name: cce_productdesc_0005.html + +.. _cce_productdesc_0005: + +Notes and Constraints +===================== + +This section describes the notes and constraints on using CCE. + +Clusters and Nodes +------------------ + +- After a cluster is created, the following items cannot be changed: + + - Number of master nodes. For example, you cannot change a non-HA cluster (with one master node) to an HA cluster (with three master nodes). + - AZ of a master node. + - Network configuration of the cluster, such as the VPC, subnet, container CIDR block, Service CIDR block, IPv6 settings, and kube-proxy (forwarding) settings. + - Network model. For example, change the **tunnel network** to the **VPC network**. + +- Applications cannot be migrated between different namespaces. +- Underlying resources, such as ECSs (nodes), are limited by quotas and their inventory. Therefore, only some nodes may be successfully created during cluster creation, cluster scaling, or auto scaling. +- The ECS (node) specifications must be higher than 2 cores and 4 GB memory. +- To access a CCE cluster through a VPN, ensure that the VPN CIDR block does not conflict with the VPC CIDR block where the cluster resides and the container CIDR block. +- Ubuntu 22.04 does not support the tunnel network model. + +Networking +---------- + +- By default, a NodePort Service is accessed within a VPC. If you need to use an EIP to access a NodePort Service through public networks, bind an EIP to the node in the cluster in advance. +- LoadBalancer Services allow workloads to be accessed from public networks through **ELB**. This access mode has the following restrictions: + + - It is recommended that automatically created load balancers not be used by other resources. Otherwise, these load balancers cannot be completely deleted, causing residual resources. + - Do not change the listener name for the load balancer in clusters of v1.15 and earlier. Otherwise, the load balancer cannot be accessed. + +- Constraints on network policies: + + - Only clusters that use the tunnel network model support network policies. + + - Network isolation is not supported for IPv6 addresses. + + - Network policies do not support egress rules except for clusters of v1.23 or later. + + Egress rules are supported only in the following operating systems: + + +-----------------------------------+-------------------------------------------+ + | OS | Kernel Version | + +===================================+===========================================+ + | CentOS | 3.10.0-1062.18.1.el7.x86_64 | + | | | + | | 3.10.0-1127.19.1.el7.x86_64 | + | | | + | | 3.10.0-1160.25.1.el7.x86_64 | + +-----------------------------------+-------------------------------------------+ + | EulerOS 2.5 | 3.10.0-862.14.1.5.h591.eulerosv2r7.x86_64 | + +-----------------------------------+-------------------------------------------+ + | EulerOS 2.9 | 4.18.0-147.5.1.6.h541.eulerosv2r9.x86_64 | + +-----------------------------------+-------------------------------------------+ + + - If a cluster is upgraded to v1.23 in in-place mode, you cannot use egress rules because the node OS is not upgraded. In this case, reset the node. + +Volumes +------- + +- Constraints on EVS volumes: + + - EVS disks cannot be attached across AZs and cannot be used by multiple workloads, multiple pods of the same workload, or multiple jobs. + + - Data in a shared disk cannot be shared between nodes in a CCE cluster. If the same EVS disk is attached to multiple nodes, read and write conflicts and data cache conflicts may occur. When creating a Deployment, you are advised to create only one pod if you want to use EVS disks. + + - For clusters earlier than v1.19.10, if an HPA policy is used to scale out a workload with EVS volumes mounted, the existing pods cannot be read or written when a new pod is scheduled to another node. + + For clusters of v1.19.10 and later, if an HPA policy is used to scale out a workload with EVS volume mounted, a new pod cannot be started because EVS disks cannot be attached. + + - When you create a StatefulSet and add a cloud storage volume, existing EVS volumes cannot be used. + + - EVS disks that have partitions or have non-ext4 file systems cannot be imported. + + - Container storage in CCE clusters of Kubernetes 1.13 or later version supports encryption. Currently, E2E encryption is supported only in certain regions. + + - EVS volumes cannot be created in specified enterprise projects. Only the default enterprise project is supported. + +- Constraints on SFS volumes: + + - SFS volumes are available only in certain regions. + - Container storage in CCE clusters of Kubernetes 1.13 or later version supports encryption. Currently, E2E encryption is supported only in certain regions. + - Volumes cannot be created in specified enterprise projects. Only the default enterprise project is supported. + +- Constraints on OBS volumes: + + - CCE clusters of v1.7.3-r8 and earlier do not support OBS volumes. You need to upgrade these clusters or create clusters of a later version that supports OBS. + - Volumes cannot be created in specified enterprise projects. Only the default enterprise project is supported. + +- Constraints on snapshots and backups: + + - The snapshot function is available **only for clusters of v1.15 or later** and requires the CSI-based everest add-on. + - The subtype (common I/O, high I/O, or ultra-high I/O), disk mode (SCSI or VBD), data encryption, sharing status, and capacity of an EVS disk created from a snapshot must be the same as those of the disk associated with the snapshot. These attributes cannot be modified after being queried or set. + +Services +-------- + +A Service is a Kubernetes resource object that defines a logical set of pods and a policy by which to access them. + +A maximum of 6,000 Services can be created in each namespace. + +CCE Cluster Resources +--------------------- + +There are resource quotas for your CCE clusters in each region. + ++--------------------------------------------------------------+------------------------------------------------------------------------+ +| Item | Constraints on Common Users | ++==============================================================+========================================================================+ +| Total number of clusters in a region | 50 | ++--------------------------------------------------------------+------------------------------------------------------------------------+ +| Number of nodes in a cluster (cluster management scale) | You can select 50, 200, 1,000, or 2,000 nodes. | ++--------------------------------------------------------------+------------------------------------------------------------------------+ +| Maximum number of container pods created on each worker node | This number can be set on the console when you are creating a cluster. | +| | | +| | In the VPC network model, a maximum of 256 pods can be created. | ++--------------------------------------------------------------+------------------------------------------------------------------------+ + +Dependent Underlying Cloud Resources +------------------------------------ + ++----------------+-----------------------------------------+-----------------------------+ +| Category | Item | Constraints on Common Users | ++================+=========================================+=============================+ +| Compute | Pods | 1,000 | ++----------------+-----------------------------------------+-----------------------------+ +| | Cores | 8,000 | ++----------------+-----------------------------------------+-----------------------------+ +| | RAM capacity (MB) | 16384000 | ++----------------+-----------------------------------------+-----------------------------+ +| Networking | VPCs per account | 5 | ++----------------+-----------------------------------------+-----------------------------+ +| | Subnets per account | 100 | ++----------------+-----------------------------------------+-----------------------------+ +| | Security groups per account | 100 | ++----------------+-----------------------------------------+-----------------------------+ +| | Security group rules per account | 5000 | ++----------------+-----------------------------------------+-----------------------------+ +| | Routes per route table | 100 | ++----------------+-----------------------------------------+-----------------------------+ +| | Routes per VPC | 100 | ++----------------+-----------------------------------------+-----------------------------+ +| | VPC peering connections per region | 50 | ++----------------+-----------------------------------------+-----------------------------+ +| | Network ACLs per account | 200 | ++----------------+-----------------------------------------+-----------------------------+ +| | Layer 2 connection gateways per account | 5 | ++----------------+-----------------------------------------+-----------------------------+ +| Load balancing | Elastic load balancers | 50 | ++----------------+-----------------------------------------+-----------------------------+ +| | Load balancer listeners | 100 | ++----------------+-----------------------------------------+-----------------------------+ +| | Load balancer certificates | 120 | ++----------------+-----------------------------------------+-----------------------------+ +| | Load balancer forwarding policies | 500 | ++----------------+-----------------------------------------+-----------------------------+ +| | Load balancer backend host group | 500 | ++----------------+-----------------------------------------+-----------------------------+ +| | Load balancer backend server | 500 | ++----------------+-----------------------------------------+-----------------------------+ diff --git a/umn/source/service_overview/permissions.rst b/umn/source/service_overview/permissions.rst new file mode 100644 index 0000000..5b1d666 --- /dev/null +++ b/umn/source/service_overview/permissions.rst @@ -0,0 +1,176 @@ +:original_name: cce_productdesc_0002.html + +.. _cce_productdesc_0002: + +Permissions +=========== + +CCE allows you to assign permissions to IAM users and user groups under your tenant accounts. CCE combines the advantages of Identity and Access Management (IAM) and Kubernetes Role-based Access Control (RBAC) to provide a variety of authorization methods, including IAM fine-grained/token authorization and cluster-/namespace-scoped authorization. + +CCE permissions are described as follows: + +- :ref:`Cluster-level permissions `: Cluster-level permissions management evolves out of the system policy authorization feature of IAM. IAM users in the same user group have the same permissions. On IAM, you can configure system policies to describe which IAM user groups can perform which operations on cluster resources. For example, you can grant user group A to create and delete cluster X, add a node, or install an add-on, while granting user group B to view information about cluster X. + + Cluster-level permissions involve CCE non-Kubernetes APIs and support fine-grained IAM policies and enterprise project management capabilities. + +- :ref:`Namespace-level permissions `: You can regulate users' or user groups' access to **Kubernetes resources**, such as workloads, jobs, and Services, in a single namespace based on their Kubernetes RBAC roles. CCE has also been enhanced based on open-source capabilities. It supports RBAC authorization based on IAM user or user group, and RBAC authentication on access to APIs using IAM tokens. + + Namespace-level permissions involve CCE Kubernetes APIs and are enhanced based on the Kubernetes RBAC capabilities. Namespace-level permissions can be granted to IAM users or user groups for authentication and authorization, but are independent of fine-grained IAM policies. For details, see `Using RBAC Authorization `__. + +.. caution:: + + - **Cluster-level permissions** are configured only for cluster-related resources (such as clusters and nodes). You must also configure :ref:`namespace permissions ` to operate Kubernetes resources (such as workloads, jobs, and Services). + - After you create a cluster of v1.11.7-r2 or later, CCE automatically assigns the cluster-admin permissions of all namespaces in the cluster to you, which means you have full control on the cluster and all resources in all namespaces. + +.. _cce_productdesc_0002__en-us_topic_0000001550245829_section14734188: + +Cluster-level Permissions (Assigned by Using IAM System Policies) +----------------------------------------------------------------- + +By default, new IAM users do not have permissions assigned. You need to add a user to one or more groups, and attach permissions policies or roles to these groups. Users inherit permissions from the groups to which they are added and can perform specified operations on cloud services based on the permissions. + +CCE is a project-level service deployed and accessed in specific physical regions. To assign AOM permissions to a user group, specify the scope as region-specific projects and select projects for the permissions to take effect. If **All projects** is selected, the permissions will take effect for the user group in all region-specific projects. When accessing CCE, the users need to switch to a region where they have been authorized to use the CCE service. + +You can grant users permissions by using roles and policies. + +- Roles: A type of coarse-grained authorization mechanism that defines permissions related to user responsibilities. This mechanism provides only a limited number of service-level roles for authorization. When using roles to assign permissions, you need to also assign other roles on which the permissions depend to take effect. However, roles are not an ideal choice for fine-grained authorization and secure access control. +- Policies: A type of fine-grained authorization mechanism that defines permissions required to perform operations on specific cloud resources under certain conditions. This mechanism allows for more flexible policy-based authorization, meeting requirements for secure access control. For example, you can assign users only the permissions for managing a certain type of clusters and nodes. + +:ref:`Table 1 ` lists all the system permissions supported by CCE. + +.. _cce_productdesc_0002__en-us_topic_0000001550245829_table9857780: + +.. table:: **Table 1** System permissions supported by CCE + + +--------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-----------------+---------------------------------------------------------------------------------------------------------------------------------------+ + | Role/Policy Name | Description | Type | Dependencies | + +====================+===============================================================================================================================================================================================================================================================+=================+=======================================================================================================================================+ + | CCE Administrator | Read and write permissions for CCE clusters and all resources (including workloads, nodes, jobs, and Services) in the clusters | Role | Users granted permissions of this policy must also be granted permissions of the following policies: | + | | | | | + | | | | **Global service project**: OBS Buckets Viewer and OBS Administrator | + | | | | | + | | | | **Region-specific projects**: Tenant Guest, Server Administrator, ELB Administrator, SFS Administrator, SWR Admin, and APM FullAccess | + | | | | | + | | | | .. note:: | + | | | | | + | | | | Users with both **CCE Administrator** and **NAT Gateway Administrator** policies can use NAT Gateway functions for clusters. | + +--------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-----------------+---------------------------------------------------------------------------------------------------------------------------------------+ + | CCE FullAccess | Common operation permissions on CCE cluster resources, excluding the namespace-level permissions for the clusters (with Kubernetes RBAC enabled) and the privileged administrator operations, such as agency configuration and cluster certificate generation | Policy | None. | + +--------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-----------------+---------------------------------------------------------------------------------------------------------------------------------------+ + | CCE ReadOnlyAccess | Permissions to view CCE cluster resources, excluding the namespace-level permissions of the clusters (with Kubernetes RBAC enabled) | Policy | None. | + +--------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-----------------+---------------------------------------------------------------------------------------------------------------------------------------+ + +.. table:: **Table 2** Common operations supported by CCE system policies + + +------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------------------------+------------------------------+-------------------+ + | Operation | CCE ReadOnlyAccess | CCE FullAccess | CCE Administrator | + +==============================================================================================================================================================================+==============================+==============================+===================+ + | Creating a cluster | x | Y | Y | + +------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------------------------+------------------------------+-------------------+ + | Deleting a cluster | x | Y | Y | + +------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------------------------+------------------------------+-------------------+ + | Updating a cluster, for example, updating cluster node scheduling parameters and providing RBAC support to clusters | x | Y | Y | + +------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------------------------+------------------------------+-------------------+ + | Upgrading a cluster | x | Y | Y | + +------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------------------------+------------------------------+-------------------+ + | Waking up a cluster | x | Y | Y | + +------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------------------------+------------------------------+-------------------+ + | Hibernating a cluster | x | Y | Y | + +------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------------------------+------------------------------+-------------------+ + | Listing all clusters | Y | Y | Y | + +------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------------------------+------------------------------+-------------------+ + | Querying cluster details | Y | Y | Y | + +------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------------------------+------------------------------+-------------------+ + | Adding a node | x | Y | Y | + +------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------------------------+------------------------------+-------------------+ + | Deleting one or more nodes | x | Y | Y | + +------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------------------------+------------------------------+-------------------+ + | Updating a cluster node, for example, updating the node name | x | Y | Y | + +------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------------------------+------------------------------+-------------------+ + | Querying node details | Y | Y | Y | + +------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------------------------+------------------------------+-------------------+ + | Listing all nodes | Y | Y | Y | + +------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------------------------+------------------------------+-------------------+ + | Listing all jobs | Y | Y | Y | + +------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------------------------+------------------------------+-------------------+ + | Deleting one or more cluster jobs | x | Y | Y | + +------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------------------------+------------------------------+-------------------+ + | Querying job details | Y | Y | Y | + +------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------------------------+------------------------------+-------------------+ + | Creating a storage volume | x | Y | Y | + +------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------------------------+------------------------------+-------------------+ + | Deleting a storage volume | x | Y | Y | + +------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------------------------+------------------------------+-------------------+ + | Performing operations on all Kubernetes resources | Y (Kubernetes RBAC required) | Y (Kubernetes RBAC required) | Y | + +------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------------------------+------------------------------+-------------------+ + | Performing all operations on an Elastic Cloud Server (ECS) | x | Y | Y | + +------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------------------------+------------------------------+-------------------+ + | Performing all operations on Elastic Volume Service (EVS) disks | x | Y | Y | + | | | | | + | EVS disks can be attached to cloud servers and scaled to a higher capacity whenever needed. | | | | + +------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------------------------+------------------------------+-------------------+ + | Performing all operations on VPC | x | Y | Y | + | | | | | + | A cluster must run in a VPC. When creating a namespace, you need to create or associate a VPC for the namespace so that all containers in the namespace will run in the VPC. | | | | + +------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------------------------+------------------------------+-------------------+ + | Viewing details of all resources on an ECS | Y | Y | Y | + | | | | | + | In CCE, a node is an ECS with multiple EVS disks. | | | | + +------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------------------------+------------------------------+-------------------+ + | Listing all resources on an ECS | Y | Y | Y | + +------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------------------------+------------------------------+-------------------+ + | Viewing details about all EVS disk resources EVS disks can be attached to cloud servers and scaled to a higher capacity whenever needed. | Y | Y | Y | + +------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------------------------+------------------------------+-------------------+ + | Listing all EVS resources | Y | Y | Y | + +------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------------------------+------------------------------+-------------------+ + | Viewing details about all VPC resources | Y | Y | Y | + | | | | | + | A cluster must run in a VPC. When creating a namespace, you need to create or associate a VPC for the namespace so that all containers in the namespace will run in the VPC. | | | | + +------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------------------------+------------------------------+-------------------+ + | Listing all VPC resources | Y | Y | Y | + +------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------------------------+------------------------------+-------------------+ + | Viewing details about all Elastic Load Balance (ELB) resources | x | x | Y | + +------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------------------------+------------------------------+-------------------+ + | Listing all ELB resources | x | x | Y | + +------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------------------------+------------------------------+-------------------+ + | Viewing Scalable File Service (SFS) resource details | Y | Y | Y | + +------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------------------------+------------------------------+-------------------+ + | Listing all SFS resources | Y | Y | Y | + +------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------------------------+------------------------------+-------------------+ + | Viewing Application Operations Management (AOM) resource details | Y | Y | Y | + +------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------------------------+------------------------------+-------------------+ + | Listing AOM resources | Y | Y | Y | + +------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------------------------+------------------------------+-------------------+ + | Performing all operations on AOM auto scaling rules | Y | Y | Y | + +------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------------------------+------------------------------+-------------------+ + +.. _cce_productdesc_0002__en-us_topic_0000001550245829_section54736241399: + +Namespace-level Permissions (Assigned by Using Kubernetes RBAC) +--------------------------------------------------------------- + +You can regulate users' or user groups' access to Kubernetes resources in a single namespace based on their Kubernetes RBAC roles. The RBAC API declares four kinds of Kubernetes objects: Role, ClusterRole, RoleBinding, and ClusterRoleBinding, which are described as follows: + +- Role: defines a set of rules for accessing Kubernetes resources in a namespace. +- RoleBinding: defines the relationship between users and roles. +- ClusterRole: defines a set of rules for accessing Kubernetes resources in a cluster (including all namespaces). +- ClusterRoleBinding: defines the relationship between users and cluster roles. + +Role and ClusterRole specify actions that can be performed on specific resources. RoleBinding and ClusterRoleBinding bind roles to specific users, user groups, or ServiceAccounts. See the following figure. + + +.. figure:: /_static/images/en-us_image_0261301557.png + :alt: **Figure 1** Role binding + + **Figure 1** Role binding + +On the CCE console, you can assign permissions to a user or user group to access resources in one or all namespaces. By default, the CCE console provides the following ClusterRoles: + +- view (read-only): read-only permission on most resources in all or selected namespaces. +- edit (development): read and write permissions on most resources in all or selected namespaces. If this ClusterRole is configured for all namespaces, its capability is the same as the O&M permission. +- admin (O&M): read and write permissions on most resources in all namespaces, and read-only permission on nodes, storage volumes, namespaces, and quota management. +- cluster-admin (administrator): read and write permissions on all resources in all namespaces. +- drainage-editor: drain a node. +- drainage-viewer: view the nodal drainage status but cannot drain a node. + +In addition to cluster-admin, admin, edit, and view, you can define Roles and RoleBindings to configure the permissions to add, delete, modify, and query resources, such as pods, Deployments, and Services, in the namespace. diff --git a/umn/source/service_overview/product_advantages.rst b/umn/source/service_overview/product_advantages.rst new file mode 100644 index 0000000..953c73d --- /dev/null +++ b/umn/source/service_overview/product_advantages.rst @@ -0,0 +1,130 @@ +:original_name: cce_productdesc_0003.html + +.. _cce_productdesc_0003: + +Product Advantages +================== + +Why CCE? +-------- + +CCE is a container service built on Docker and Kubernetes. A wealth of features enable you to run container clusters at scale. CCE eases containerization thanks to its reliability, performance, and open source engagement. + +**Easy to Use** + +- Creating a Kubernetes cluster is as easy as a few clicks on the web console. You can deploy and manage VMs and BMSs together. +- CCE automates deployment and O&M of containerized applications throughout their lifecycle. +- You can resize clusters and workloads by setting auto scaling policies. In-the-moment load spikes are no longer headaches. +- The console walks you through the steps to upgrade Kubernetes clusters. +- CCE supports turnkey Helm charts. + +**High Performance** + +- CCE runs on mature IaaS services and heterogeneous compute resources. You can launch containers at scale. +- AI computing is 3x to 5x better with NUMA BMSs and high-speed InfiniBand network cards. + +**Highly Available and Secure** + +- HA: Three master nodes in different AZs for your cluster control plane. Multi-active DR for your nodes and workloads. All these ensure service continuity when one of the nodes is down or an AZ gets hit by natural disasters. + + + .. figure:: /_static/images/en-us_image_0000001550365685.png + :alt: **Figure 1** High-availability setup of clusters + + **Figure 1** High-availability setup of clusters + +- Secure: Integrating IAM and Kubernetes RBAC, CCE clusters are under your full control. You can set different RBAC permissions for IAM users on the console. + +**Open and Compatible** + +- CCE runs on Docker that automates container deployment, discovery, scheduling, and scaling. +- CCE is compatible with native Kubernetes APIs and kubectl. Updates from Kubernetes and Docker communities are regularly incorporated into CCE. + +Comparative Analysis of CCE and On-Premises Kubernetes Cluster Management Systems +--------------------------------------------------------------------------------- + +.. table:: **Table 1** CCE clusters versus on-premises Kubernetes clusters + + +-----------------------+--------------------------------------------------------------------------------------------------------------------------------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | Area of Focus | On-Premises Cluster | CCE | + +=======================+==================================================================================================================================================+================================================================================================================================================================================================================+ + | Ease of use | You have to handle all the complexity in deploying and managing Kubernetes clusters. Cluster upgrades are often a heavy burden to O&M personnel. | **Easy to manage and use clusters** | + | | | | + | | | You can create a Kubernetes container cluster in a few clicks. No need to set up Docker or Kubernetes environments. CCE automates deployment and O&M of containerized applications throughout their lifecycle. | + | | | | + | | | CCE supports turnkey Helm charts. | + | | | | + | | | Using CCE is as simple as choosing a cluster and the workloads that you want to run in the cluster. CCE takes care of cluster management and you focus on app development. | + +-----------------------+--------------------------------------------------------------------------------------------------------------------------------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | Scalability | You have to assess service loads and cluster health before resizing a cluster. | **Managed scaling service** | + | | | | + | | | CCE auto scales clusters and workloads according to resource metrics and scaling policies. | + +-----------------------+--------------------------------------------------------------------------------------------------------------------------------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | Reliability | Only one master node is available in a cluster. Once this node is down, the entire cluster is down, as well as all the applications in it. | **High availability** | + | | | | + | | | Enabling HA when creating a cluster will create three master nodes for the control plane. Single points of failure (SPOFs) will not shut down your cluster. | + +-----------------------+--------------------------------------------------------------------------------------------------------------------------------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | Efficiency | You have to either build an image repository or turn to a third-party one. Images are pulled in serial. | **Rapid deployment with images** | + | | | | + | | | CCE connects to SWR to pull images in parallel. Faster pulls, faster container build. | + +-----------------------+--------------------------------------------------------------------------------------------------------------------------------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | Cost | Heavy upfront investment in installing, managing, and scaling cluster management infrastructure | **Cost effective** | + | | | | + | | | You only pay for master nodes and the resources used to run and manage applications. | + +-----------------------+--------------------------------------------------------------------------------------------------------------------------------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + +Why Containers? +--------------- + +Docker is written in the Go language designed by Google. It provides operating-system-level virtualization. Linux Control Groups (cgroups), namespaces, and UnionFS (for example, AUFS) isolate each software process. A Docker container packages everything needed to run a software process. Containers are independent from each other and from the host. + +Docker has moved forward to enhance container isolation. Containers have their own file systems. They cannot see each other's processes or network interfaces. This simplifies container creation and management. + +VMs use a hypervisor to virtualize and allocate hardware resources (such as memory, CPU, network, and disk) of a host machine. A complete operating system runs on a VM. Each VM needs to run its own system processes. On the contrary, a container does not require hardware resource virtualization. It runs an application process directly in the the host machine OS kernel. No resource overheads are incurred by running system processes. Therefore, Docker is lighter and faster than VMs. + + +.. figure:: /_static/images/en-us_image_0000001499406022.png + :alt: **Figure 2** Comparison between Docker containers and VMs + + **Figure 2** Comparison between Docker containers and VMs + +To sum up, Docker containers have many advantages over VMs. + +**Resource use** + +Containers have no overheads for virtualizing hardware and running a complete OS. They are faster than VMs in execution and file storage, while having no memory loss. + +**Start speed** + +It takes several minutes to start an application on a VM. Docker containers run on the host kernel without needing an independent OS. Apps in containers can start in seconds or even milliseconds. Development, testing, and deployment can be much faster. + +**Consistent environment** + +Different development, testing, and production environments sometimes prevent bug discovery before rollout. A Docker container image includes everything needed to run an application. You can deploy the same copy of configurations in different environments. + +**Continuous delivery and deployment** + +"Deploy once, run everywhere" would be great for DevOps personnel. + +Docker supports CI/CD by allowing you to customize container images. You compile Dockerfiles to build container images and use CI systems for testing. The Ops team can deploy images into production environments and use CD systems for auto deployment. + +The use of Dockerfiles makes the DevOps process visible to everyone in a DevOps team. Developers can better understand both user needs and the O&M headaches faced by the Ops team. The Ops team can also have some knowledge of the must-met conditions to run the application. The knowledge is helpful when the Ops personnel deploy container images in production. + +**Portability** + +Docker ensures environmental consistency across development, testing, and production. Portable Docker containers work the same, regardless of their running environments. Physical machines, VMs, public clouds, private clouds, or even laptops, you name it. Apps are now free to migrate and run anywhere. + +**Application update** + +Docker images consist of layers. Each layer is only stored once and different images can contain the exact same layers. When transferring such images, those same layers get transferred only once. This makes distribution efficient. Updating a containerized application is also simple. Either edit the top-most writable layer in the final image or add layers to the base image. Docker joins hands with many open source projects to maintain a variety of high-quality official images. You can directly use them in the production environment or easily build new images based on them. + +.. table:: **Table 2** Containers versus traditional VMs + + ==================== ======================= =========== + Feature Containers VMs + ==================== ======================= =========== + Start speed In seconds In minutes + Disk capacity MB GB + Performance Near-native performance Weak + Per-machine capacity Thousands of containers Tens of VMs + ==================== ======================= =========== diff --git a/umn/source/service_overview/related_services.rst b/umn/source/service_overview/related_services.rst new file mode 100644 index 0000000..05a097e --- /dev/null +++ b/umn/source/service_overview/related_services.rst @@ -0,0 +1,47 @@ +:original_name: cce_productdesc_0008.html + +.. _cce_productdesc_0008: + +Related Services +================ + + +.. figure:: /_static/images/en-us_image_0000001550245853.png + :alt: **Figure 1** Relationships between CCE and other services + + **Figure 1** Relationships between CCE and other services + +Relationships Between CCE and Other Services +-------------------------------------------- + +.. table:: **Table 1** Relationships between CCE and other services + + +-----------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | Service | Relationship | + +=========================================+===================================================================================================================================================================================================================================================================================+ + | Elastic Cloud Server (ECS) | An ECS with multiple EVS disks is a node in CCE. You can choose ECS specifications during node creation. | + +-----------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | Virtual Private Cloud (VPC) | For security reasons, all clusters created by CCE must run in VPCs. When creating a namespace, you need to create a VPC or bind an existing VPC to the namespace so all containers in the namespace will run in this VPC. | + +-----------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | Elastic Load Balance (ELB) | CCE works with ELB to load balance a workload's access requests across multiple pods. | + +-----------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | NAT Gateway | The NAT Gateway service provides source network address translation (SNAT) for container instances in a VPC. The SNAT feature translates private IP addresses of these container instances to the same EIP, which is a public IP address reachable on Internet. | + +-----------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | Software Repository for Container (SWR) | An image repository is used to store and manage Docker images. | + +-----------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | Elastic Volume Service (EVS) | EVS disks can be attached to cloud servers and scaled to a higher capacity whenever needed. | + | | | + | | An ECS with multiple EVS disks is a node in CCE. You can choose ECS specifications during node creation. | + +-----------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | Object Storage Service (OBS) | OBS provides stable, secure, cost-efficient, and object-based cloud storage for data of any size. With OBS, you can create, modify, and delete buckets, as well as uploading, downloading, and deleting objects. | + | | | + | | CCE allows you to create an OBS volume and attach it to a path inside a container. | + +-----------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | Scalable File Service (SFS) | SFS is a shared, fully managed file storage service. Compatible with the Network File System protocol, SFS file systems can elastically scale up to petabytes, thereby ensuring top performance of data-intensive and bandwidth-intensive applications. | + | | | + | | You can use SFS file systems as persistent storage for containers and attach the file systems to containers when creating a workload. | + +-----------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | Application Operations Management (AOM) | AOM collects container log files in formats like .log from CCE and dumps them to AOM. On the AOM console, you can easily query and view log files. In addition, AOM monitors CCE resource usage. You can define metric thresholds for CCE resource usage to trigger auto scaling. | + +-----------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | Cloud Trace Service (CTS) | CTS records operations on your cloud resources, allowing you to query, audit, and backtrack resource operation requests initiated from the management console or open APIs as well as responses to these requests. | + +-----------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ diff --git a/umn/source/service_overview/what_is_cloud_container_engine.rst b/umn/source/service_overview/what_is_cloud_container_engine.rst new file mode 100644 index 0000000..283f11c --- /dev/null +++ b/umn/source/service_overview/what_is_cloud_container_engine.rst @@ -0,0 +1,25 @@ +:original_name: cce_01_0091.html + +.. _cce_01_0091: + +What Is Cloud Container Engine? +=============================== + +Why CCE? +-------- + +CCE is a one-stop platform integrating compute, networking, storage, and many other services. Supporting multi-AZ and multi-region disaster recovery, CCE ensures high availability of `Kubernetes `__ clusters. + +For more information, see :ref:`Product Advantages ` and :ref:`Application Scenarios `. + +Accessing CCE +------------- + +You can use CCE via the CCE console, kubectl, or Kubernetes APIs. :ref:`Figure 1 ` shows the process. + +.. _cce_01_0091__en-us_topic_0000001499406010_fig3404612135411: + +.. figure:: /_static/images/en-us_image_0000001499565914.png + :alt: **Figure 1** Accessing CCE + + **Figure 1** Accessing CCE diff --git a/umn/source/storage/deployment_examples/creating_a_deployment_mounted_with_an_evs_volume.rst b/umn/source/storage/deployment_examples/creating_a_deployment_mounted_with_an_evs_volume.rst index 1e31282..6f5232b 100644 --- a/umn/source/storage/deployment_examples/creating_a_deployment_mounted_with_an_evs_volume.rst +++ b/umn/source/storage/deployment_examples/creating_a_deployment_mounted_with_an_evs_volume.rst @@ -17,7 +17,7 @@ After an EVS volume is created or imported to CCE, you can mount it to a workloa Prerequisites ------------- -You have created a CCE cluster and installed the CSI plug-in (:ref:`everest `) in the cluster. +You have created a cluster and installed the CSI plug-in (:ref:`everest `) in the cluster. Notes and Constraints --------------------- diff --git a/umn/source/storage/deployment_examples/creating_a_deployment_mounted_with_an_obs_volume.rst b/umn/source/storage/deployment_examples/creating_a_deployment_mounted_with_an_obs_volume.rst index f204865..1f474db 100644 --- a/umn/source/storage/deployment_examples/creating_a_deployment_mounted_with_an_obs_volume.rst +++ b/umn/source/storage/deployment_examples/creating_a_deployment_mounted_with_an_obs_volume.rst @@ -13,7 +13,7 @@ After an OBS volume is created or imported to CCE, you can mount the volume to a Prerequisites ------------- -You have created a CCE cluster and installed the CSI plug-in (:ref:`everest `) in the cluster. +You have created a cluster and installed the CSI plug-in (:ref:`everest `) in the cluster. Notes and Constraints --------------------- diff --git a/umn/source/storage/deployment_examples/creating_a_deployment_mounted_with_an_sfs_volume.rst b/umn/source/storage/deployment_examples/creating_a_deployment_mounted_with_an_sfs_volume.rst index 920d9d0..cc680ed 100644 --- a/umn/source/storage/deployment_examples/creating_a_deployment_mounted_with_an_sfs_volume.rst +++ b/umn/source/storage/deployment_examples/creating_a_deployment_mounted_with_an_sfs_volume.rst @@ -13,7 +13,7 @@ After an SFS volume is created or imported to CCE, you can mount the volume to a Prerequisites ------------- -You have created a CCE cluster and installed the CSI plug-in (:ref:`everest `) in the cluster. +You have created a cluster and installed the CSI plug-in (:ref:`everest `) in the cluster. Notes and Constraints --------------------- diff --git a/umn/source/storage/deployment_examples/creating_a_statefulset_mounted_with_an_obs_volume.rst b/umn/source/storage/deployment_examples/creating_a_statefulset_mounted_with_an_obs_volume.rst index ec406f4..1bd85fd 100644 --- a/umn/source/storage/deployment_examples/creating_a_statefulset_mounted_with_an_obs_volume.rst +++ b/umn/source/storage/deployment_examples/creating_a_statefulset_mounted_with_an_obs_volume.rst @@ -13,7 +13,7 @@ CCE allows you to use an existing OBS volume to create a StatefulSet through a P Prerequisites ------------- -You have created a CCE cluster and installed the CSI plug-in (:ref:`everest `) in the cluster. +You have created a cluster and installed the CSI plug-in (:ref:`everest `) in the cluster. Notes and Constraints --------------------- diff --git a/umn/source/storage/deployment_examples/creating_a_statefulset_mounted_with_an_sfs_volume.rst b/umn/source/storage/deployment_examples/creating_a_statefulset_mounted_with_an_sfs_volume.rst index ed355c0..d9f84ff 100644 --- a/umn/source/storage/deployment_examples/creating_a_statefulset_mounted_with_an_sfs_volume.rst +++ b/umn/source/storage/deployment_examples/creating_a_statefulset_mounted_with_an_sfs_volume.rst @@ -13,7 +13,7 @@ CCE allows you to use an existing SGS volume to create a StatefulSet (by using a Prerequisites ------------- -You have created a CCE cluster and installed the CSI plug-in (:ref:`everest `) in the cluster. +You have created a cluster and installed the CSI plug-in (:ref:`everest `) in the cluster. Notes and Constraints --------------------- diff --git a/umn/source/storage/overview.rst b/umn/source/storage/overview.rst index b2dd45e..a9c17a1 100644 --- a/umn/source/storage/overview.rst +++ b/umn/source/storage/overview.rst @@ -59,7 +59,7 @@ Kubernetes provides PersistentVolumes (PVs) and PersistentVolumeClaims (PVCs) to You can bind PVCs to PVs in a pod so that the pod can use storage resources. The following figure shows the relationship between PVs and PVCs. -.. figure:: /_static/images/en-us_image_0000001244141191.png +.. figure:: /_static/images/en-us_image_0000001518222608.png :alt: **Figure 1** PVC-to-PV binding **Figure 1** PVC-to-PV binding @@ -94,7 +94,7 @@ Cloud Services for Container Storage CCE allows you to mount local and cloud storage volumes listed in :ref:`Volume Types ` to your pods. Their features are described below. -.. figure:: /_static/images/en-us_image_0000001203385342.png +.. figure:: /_static/images/en-us_image_0000001568902557.png :alt: **Figure 2** Volume types supported by CCE **Figure 2** Volume types supported by CCE @@ -188,4 +188,4 @@ Checking Storage Add-ons #. Click the **Add-on Instance** tab. #. Select a cluster in the upper right corner. The default storage add-on installed during cluster creation is displayed. -.. |image1| image:: /_static/images/en-us_image_0000001199501276.png +.. |image1| image:: /_static/images/en-us_image_0000001517903088.png diff --git a/umn/source/storage/persistentvolumeclaims_pvcs.rst b/umn/source/storage/persistentvolumeclaims_pvcs.rst index a90b650..fa3c141 100644 --- a/umn/source/storage/persistentvolumeclaims_pvcs.rst +++ b/umn/source/storage/persistentvolumeclaims_pvcs.rst @@ -287,7 +287,7 @@ The disk type, encryption setting, and disk mode of the created EVS PVC are cons #. Log in to the CCE console. #. Click the cluster name and go to the cluster console. Choose **Storage** from the navigation pane, and click the **Snapshots and Backups** tab. -#. Locate the snapshot for which you want to create a PVC, click **Create PVC**, and specify the PVC name in the displayed dialog box. +#. Locate the snapshot that you want to use for creating a PVC, click **Create PVC**, and specify the PVC name in the displayed dialog box. #. Click **Create**. **Creating from YAML** diff --git a/umn/source/storage/persistentvolumes_pvs.rst b/umn/source/storage/persistentvolumes_pvs.rst index 3a447d0..f85c5bc 100644 --- a/umn/source/storage/persistentvolumes_pvs.rst +++ b/umn/source/storage/persistentvolumes_pvs.rst @@ -143,7 +143,7 @@ Creating an EVS Volume | | **Delete**: | | | | | | - If **everest.io/reclaim-policy** is not specified, both the PV and EVS disk are deleted when a PVC is deleted. | - | | - If **everest.io/reclaim-policy** is set to **retain-volume-only set**, when a PVC is deleted, the PV is deleted but the EVS resources are retained. | + | | - If **everest.io/reclaim-policy** is set to **retain-volume-only**, when a PVC is deleted, the PV is deleted but the EVS resources are retained. | | | | | | **Retain**: When a PVC is deleted, the PV and underlying storage resources are not deleted. Instead, you must manually delete these resources. After that, the PV resource is in the Released state and cannot be bound to the PVC again. | | | | @@ -239,7 +239,7 @@ Creating an SFS Volume | | **Delete**: | | | | | | - If **everest.io/reclaim-policy** is not specified, both the PV and SFS volume are deleted when a PVC is deleted. | - | | - If **everest.io/reclaim-policy** is set to **retain-volume-only set**, when a PVC is deleted, the PV is deleted but the file storage resources are retained. | + | | - If **everest.io/reclaim-policy** is set to **retain-volume-only**, when a PVC is deleted, the PV is deleted but the file storage resources are retained. | | | | | | **Retain**: When a PVC is deleted, the PV and underlying storage resources are not deleted. Instead, you must manually delete these resources. After that, the PV resource is in the Released state and cannot be bound to the PVC again. | | | | @@ -335,7 +335,7 @@ Creating an OBS Volume | | **Delete**: | | | | | | - If **everest.io/reclaim-policy** is not specified, both the PV and OBS volume are deleted when a PVC is deleted. | - | | - If **everest.io/reclaim-policy** is set to **retain-volume-only set**, when a PVC is deleted, the PV is deleted but the object storage resources are retained. | + | | - If **everest.io/reclaim-policy** is set to **retain-volume-only**, when a PVC is deleted, the PV is deleted but the object storage resources are retained. | | | | | | **Retain**: When a PVC is deleted, the PV and underlying storage resources are not deleted. Instead, you must manually delete these resources. After that, the PV resource is in the Released state and cannot be bound to the PVC again. | | | | @@ -420,7 +420,7 @@ Creating an SFS Turbo Volume | | **Delete**: | | | | | | - If **everest.io/reclaim-policy** is not specified, both the PV and SFS Turbo volume are deleted when a PVC is deleted. | - | | - If **everest.io/reclaim-policy** is set to **retain-volume-only set**, when a PVC is deleted, the PV is deleted but the SFF Turbo resources are retained. | + | | - If **everest.io/reclaim-policy** is set to **retain-volume-only**, when a PVC is deleted, the PV is deleted but the SFF Turbo resources are retained. | | | | | | **Retain**: When a PVC is deleted, the PV and underlying storage resources are not deleted. Instead, you must manually delete these resources. After that, the PV resource is in the Released state and cannot be bound to the PVC again. | | | | diff --git a/umn/source/storage/storageclass.rst b/umn/source/storage/storageclass.rst index 9607a61..3739a38 100644 --- a/umn/source/storage/storageclass.rst +++ b/umn/source/storage/storageclass.rst @@ -78,8 +78,8 @@ This section describes how to set a custom storage class in CCE and how to set t requests: storage: 10Gi -Custom Storage Classes ----------------------- +Custom Storage Class +-------------------- You can customize a high I/O storage class in a YAML file. For example, the name **csi-disk-sas** indicates that the disk type is SAS (high I/O). @@ -117,14 +117,14 @@ For an ultra-high I/O storage class, you can set the class name to **csi-disk-ss volumeBindingMode: Immediate allowVolumeExpansion: true -**reclaimPolicy**: indicates the recycling policies of the underlying cloud storage. The value can be **Delete** or **Retain**. +**reclaimPolicy**: indicates the reclaim policies of the underlying cloud storage. The value can be **Delete** or **Retain**. - **Delete**: When a PVC is deleted, both the PV and the EVS disk are deleted. -- **Retain**: When a PVC is deleted, the PV and underlying storage resources are not deleted. Instead, you must manually delete these resources. After that, the PV resource is in the **Released** state and cannot be bound to the PVC again. +- **Retain**: When a PVC is deleted, the PV and underlying storage resources are not deleted. Instead, you must manually delete these resources. After a PVC is deleted, the PV resource is in the Released state and cannot be bound to the PVC again. .. note:: - The reclamation policy set here has no impact on the SFS Turbo storage. Therefore, the yearly/monthly SFS Turbo resources will not be reclaimed when the cluster or PVC is deleted. + The reclamation policy set here has no impact on the SFS Turbo storage. If high data security is required, you are advised to select **Retain** to prevent data from being deleted by mistake. @@ -153,7 +153,7 @@ Query the storage class again. Two more types of storage classes are displayed i Other types of storage resources can be defined in the similar way. You can use kubectl to obtain the YAML file and modify it as required. -- File storage +- File Storage .. code-block:: @@ -300,4 +300,4 @@ Verification View the PVC details on the CCE console. On the PV details page, you can see that the disk type is ultra-high I/O. -.. |image1| image:: /_static/images/en-us_image_0000001102275444.png +.. |image1| image:: /_static/images/en-us_image_0000001517903252.png diff --git a/umn/source/storage/using_a_custom_ak_sk_to_mount_an_obs_volume.rst b/umn/source/storage/using_a_custom_ak_sk_to_mount_an_obs_volume.rst index 8049691..b86d97b 100644 --- a/umn/source/storage/using_a_custom_ak_sk_to_mount_an_obs_volume.rst +++ b/umn/source/storage/using_a_custom_ak_sk_to_mount_an_obs_volume.rst @@ -41,13 +41,20 @@ Search for **disable-auto-mount-secret** and set it to **true**. Run **:wq** to save the settings and exit. Wait until the pod is restarted. +Obtaining an Access Key +----------------------- + +#. Log in to the console. +#. Hover the cursor over the username in the upper right corner and choose **My Credentials** from the drop-down list. +#. In the navigation pane, choose **Access Keys**. +#. Click **Create Access Key**. The **Create Access Key** dialog box is displayed. +#. Click **OK** to download the AK/SK. + Creating a Secret Using an Access Key ------------------------------------- #. Obtain an access key. - For details, see `Creating Access Keys (AK and SK) `__. - #. Encode the keys using Base64. (Assume that the AK is xxx and the SK is yyy.) **echo -n xxx|base64** @@ -280,6 +287,6 @@ You can use a secret of an IAM user to mount an OBS volume. Assume that a worklo -rwxrwxrwx 1 root root 0 Jun 7 01:52 test -.. |image1| image:: /_static/images/en-us_image_0000001199181232.png -.. |image2| image:: /_static/images/en-us_image_0000001244141105.png -.. |image3| image:: /_static/images/en-us_image_0000001244261069.png +.. |image1| image:: /_static/images/en-us_image_0000001569182645.png +.. |image2| image:: /_static/images/en-us_image_0000001568822821.png +.. |image3| image:: /_static/images/en-us_image_0000001569022933.png diff --git a/umn/source/storage/using_local_disks_as_storage_volumes.rst b/umn/source/storage/using_local_disks_as_storage_volumes.rst index 2b23dbd..16af9a8 100644 --- a/umn/source/storage/using_local_disks_as_storage_volumes.rst +++ b/umn/source/storage/using_local_disks_as_storage_volumes.rst @@ -343,7 +343,7 @@ You can use kubectl to mount a file directory of the host where the container is -rw-r--r-- 1 root root 0 Jun 1 08:12 test1 -rw-r--r-- 1 root root 0 Jun 1 08:14 test2 -.. |image1| image:: /_static/images/en-us_image_0000001465197524.png -.. |image2| image:: /_static/images/en-us_image_0000001515917789.png -.. |image3| image:: /_static/images/en-us_image_0000001464878016.png -.. |image4| image:: /_static/images/en-us_image_0000001515838557.png +.. |image1| image:: /_static/images/en-us_image_0000001568902637.png +.. |image2| image:: /_static/images/en-us_image_0000001517903168.png +.. |image3| image:: /_static/images/en-us_image_0000001517743600.png +.. |image4| image:: /_static/images/en-us_image_0000001569023013.png diff --git a/umn/source/storage_flexvolume/flexvolume_overview.rst b/umn/source/storage_management_flexvolume_deprecated/flexvolume_overview.rst similarity index 100% rename from umn/source/storage_flexvolume/flexvolume_overview.rst rename to umn/source/storage_management_flexvolume_deprecated/flexvolume_overview.rst diff --git a/umn/source/storage_flexvolume/how_do_i_change_the_storage_class_used_by_a_cluster_of_v1.15_from_flexvolume_to_csi_everest.rst b/umn/source/storage_management_flexvolume_deprecated/how_do_i_change_the_storage_class_used_by_a_cluster_of_v1.15_from_flexvolume_to_csi_everest.rst similarity index 99% rename from umn/source/storage_flexvolume/how_do_i_change_the_storage_class_used_by_a_cluster_of_v1.15_from_flexvolume_to_csi_everest.rst rename to umn/source/storage_management_flexvolume_deprecated/how_do_i_change_the_storage_class_used_by_a_cluster_of_v1.15_from_flexvolume_to_csi_everest.rst index 7f529c5..b402746 100644 --- a/umn/source/storage_flexvolume/how_do_i_change_the_storage_class_used_by_a_cluster_of_v1.15_from_flexvolume_to_csi_everest.rst +++ b/umn/source/storage_management_flexvolume_deprecated/how_do_i_change_the_storage_class_used_by_a_cluster_of_v1.15_from_flexvolume_to_csi_everest.rst @@ -592,4 +592,4 @@ Procedure kubectl patch pv {pv_name} -p '{"metadata":{"finalizers":null}}' -.. |image1| image:: /_static/images/en-us_image_0000001097062729.png +.. |image1| image:: /_static/images/en-us_image_0000001518062756.png diff --git a/umn/source/storage_flexvolume/index.rst b/umn/source/storage_management_flexvolume_deprecated/index.rst similarity index 90% rename from umn/source/storage_flexvolume/index.rst rename to umn/source/storage_management_flexvolume_deprecated/index.rst index dfdecfc..d9419d8 100644 --- a/umn/source/storage_flexvolume/index.rst +++ b/umn/source/storage_management_flexvolume_deprecated/index.rst @@ -2,8 +2,8 @@ .. _cce_10_0305: -Storage (FlexVolume) -==================== +Storage Management: FlexVolume (Deprecated) +=========================================== - :ref:`FlexVolume Overview ` - :ref:`How Do I Change the Storage Class Used by a Cluster of v1.15 from FlexVolume to CSI Everest? ` diff --git a/umn/source/storage_flexvolume/using_evs_disks_as_storage_volumes/index.rst b/umn/source/storage_management_flexvolume_deprecated/using_evs_disks_as_storage_volumes/index.rst similarity index 100% rename from umn/source/storage_flexvolume/using_evs_disks_as_storage_volumes/index.rst rename to umn/source/storage_management_flexvolume_deprecated/using_evs_disks_as_storage_volumes/index.rst diff --git a/umn/source/storage_flexvolume/using_evs_disks_as_storage_volumes/kubectl_automatically_creating_an_evs_disk.rst b/umn/source/storage_management_flexvolume_deprecated/using_evs_disks_as_storage_volumes/kubectl_automatically_creating_an_evs_disk.rst similarity index 100% rename from umn/source/storage_flexvolume/using_evs_disks_as_storage_volumes/kubectl_automatically_creating_an_evs_disk.rst rename to umn/source/storage_management_flexvolume_deprecated/using_evs_disks_as_storage_volumes/kubectl_automatically_creating_an_evs_disk.rst diff --git a/umn/source/storage_flexvolume/using_evs_disks_as_storage_volumes/kubectl_creating_a_pod_mounted_with_an_evs_volume.rst b/umn/source/storage_management_flexvolume_deprecated/using_evs_disks_as_storage_volumes/kubectl_creating_a_pod_mounted_with_an_evs_volume.rst similarity index 100% rename from umn/source/storage_flexvolume/using_evs_disks_as_storage_volumes/kubectl_creating_a_pod_mounted_with_an_evs_volume.rst rename to umn/source/storage_management_flexvolume_deprecated/using_evs_disks_as_storage_volumes/kubectl_creating_a_pod_mounted_with_an_evs_volume.rst diff --git a/umn/source/storage_flexvolume/using_evs_disks_as_storage_volumes/kubectl_creating_a_pv_from_an_existing_evs_disk.rst b/umn/source/storage_management_flexvolume_deprecated/using_evs_disks_as_storage_volumes/kubectl_creating_a_pv_from_an_existing_evs_disk.rst similarity index 100% rename from umn/source/storage_flexvolume/using_evs_disks_as_storage_volumes/kubectl_creating_a_pv_from_an_existing_evs_disk.rst rename to umn/source/storage_management_flexvolume_deprecated/using_evs_disks_as_storage_volumes/kubectl_creating_a_pv_from_an_existing_evs_disk.rst diff --git a/umn/source/storage_flexvolume/using_evs_disks_as_storage_volumes/overview.rst b/umn/source/storage_management_flexvolume_deprecated/using_evs_disks_as_storage_volumes/overview.rst similarity index 96% rename from umn/source/storage_flexvolume/using_evs_disks_as_storage_volumes/overview.rst rename to umn/source/storage_management_flexvolume_deprecated/using_evs_disks_as_storage_volumes/overview.rst index 5720bcb..ea9a6ee 100644 --- a/umn/source/storage_flexvolume/using_evs_disks_as_storage_volumes/overview.rst +++ b/umn/source/storage_management_flexvolume_deprecated/using_evs_disks_as_storage_volumes/overview.rst @@ -8,7 +8,7 @@ Overview To achieve persistent storage, CCE allows you to mount the storage volumes created from Elastic Volume Service (EVS) disks to a path of a container. When the container is migrated, the mounted EVS volumes are also migrated. By using EVS volumes, you can mount the remote file directory of storage system into a container so that data in the data volume is permanently preserved even when the container is deleted. -.. figure:: /_static/images/en-us_image_0000001248663503.png +.. figure:: /_static/images/en-us_image_0000001517903060.png :alt: **Figure 1** Mounting EVS volumes to CCE **Figure 1** Mounting EVS volumes to CCE diff --git a/umn/source/storage_flexvolume/using_obs_buckets_as_storage_volumes/index.rst b/umn/source/storage_management_flexvolume_deprecated/using_obs_buckets_as_storage_volumes/index.rst similarity index 100% rename from umn/source/storage_flexvolume/using_obs_buckets_as_storage_volumes/index.rst rename to umn/source/storage_management_flexvolume_deprecated/using_obs_buckets_as_storage_volumes/index.rst diff --git a/umn/source/storage_flexvolume/using_obs_buckets_as_storage_volumes/kubectl_automatically_creating_an_obs_volume.rst b/umn/source/storage_management_flexvolume_deprecated/using_obs_buckets_as_storage_volumes/kubectl_automatically_creating_an_obs_volume.rst similarity index 100% rename from umn/source/storage_flexvolume/using_obs_buckets_as_storage_volumes/kubectl_automatically_creating_an_obs_volume.rst rename to umn/source/storage_management_flexvolume_deprecated/using_obs_buckets_as_storage_volumes/kubectl_automatically_creating_an_obs_volume.rst diff --git a/umn/source/storage_flexvolume/using_obs_buckets_as_storage_volumes/kubectl_creating_a_deployment_mounted_with_an_obs_volume.rst b/umn/source/storage_management_flexvolume_deprecated/using_obs_buckets_as_storage_volumes/kubectl_creating_a_deployment_mounted_with_an_obs_volume.rst similarity index 100% rename from umn/source/storage_flexvolume/using_obs_buckets_as_storage_volumes/kubectl_creating_a_deployment_mounted_with_an_obs_volume.rst rename to umn/source/storage_management_flexvolume_deprecated/using_obs_buckets_as_storage_volumes/kubectl_creating_a_deployment_mounted_with_an_obs_volume.rst diff --git a/umn/source/storage_flexvolume/using_obs_buckets_as_storage_volumes/kubectl_creating_a_pv_from_an_existing_obs_bucket.rst b/umn/source/storage_management_flexvolume_deprecated/using_obs_buckets_as_storage_volumes/kubectl_creating_a_pv_from_an_existing_obs_bucket.rst similarity index 100% rename from umn/source/storage_flexvolume/using_obs_buckets_as_storage_volumes/kubectl_creating_a_pv_from_an_existing_obs_bucket.rst rename to umn/source/storage_management_flexvolume_deprecated/using_obs_buckets_as_storage_volumes/kubectl_creating_a_pv_from_an_existing_obs_bucket.rst diff --git a/umn/source/storage_flexvolume/using_obs_buckets_as_storage_volumes/kubectl_creating_a_statefulset_mounted_with_an_obs_volume.rst b/umn/source/storage_management_flexvolume_deprecated/using_obs_buckets_as_storage_volumes/kubectl_creating_a_statefulset_mounted_with_an_obs_volume.rst similarity index 100% rename from umn/source/storage_flexvolume/using_obs_buckets_as_storage_volumes/kubectl_creating_a_statefulset_mounted_with_an_obs_volume.rst rename to umn/source/storage_management_flexvolume_deprecated/using_obs_buckets_as_storage_volumes/kubectl_creating_a_statefulset_mounted_with_an_obs_volume.rst diff --git a/umn/source/storage_flexvolume/using_obs_buckets_as_storage_volumes/overview.rst b/umn/source/storage_management_flexvolume_deprecated/using_obs_buckets_as_storage_volumes/overview.rst similarity index 97% rename from umn/source/storage_flexvolume/using_obs_buckets_as_storage_volumes/overview.rst rename to umn/source/storage_management_flexvolume_deprecated/using_obs_buckets_as_storage_volumes/overview.rst index c05a7c4..372cf52 100644 --- a/umn/source/storage_flexvolume/using_obs_buckets_as_storage_volumes/overview.rst +++ b/umn/source/storage_management_flexvolume_deprecated/using_obs_buckets_as_storage_volumes/overview.rst @@ -8,7 +8,7 @@ Overview CCE allows you to mount a volume created from an Object Storage Service (OBS) bucket to a container to store data persistently. Object storage is commonly used in cloud workloads, data analysis, content analysis, and hotspot objects. -.. figure:: /_static/images/en-us_image_0000001249023453.png +.. figure:: /_static/images/en-us_image_0000001517743540.png :alt: **Figure 1** Mounting OBS volumes to CCE **Figure 1** Mounting OBS volumes to CCE diff --git a/umn/source/storage_flexvolume/using_sfs_file_systems_as_storage_volumes/index.rst b/umn/source/storage_management_flexvolume_deprecated/using_sfs_file_systems_as_storage_volumes/index.rst similarity index 100% rename from umn/source/storage_flexvolume/using_sfs_file_systems_as_storage_volumes/index.rst rename to umn/source/storage_management_flexvolume_deprecated/using_sfs_file_systems_as_storage_volumes/index.rst diff --git a/umn/source/storage_flexvolume/using_sfs_file_systems_as_storage_volumes/kubectl_automatically_creating_an_sfs_volume.rst b/umn/source/storage_management_flexvolume_deprecated/using_sfs_file_systems_as_storage_volumes/kubectl_automatically_creating_an_sfs_volume.rst similarity index 100% rename from umn/source/storage_flexvolume/using_sfs_file_systems_as_storage_volumes/kubectl_automatically_creating_an_sfs_volume.rst rename to umn/source/storage_management_flexvolume_deprecated/using_sfs_file_systems_as_storage_volumes/kubectl_automatically_creating_an_sfs_volume.rst diff --git a/umn/source/storage_flexvolume/using_sfs_file_systems_as_storage_volumes/kubectl_creating_a_deployment_mounted_with_an_sfs_volume.rst b/umn/source/storage_management_flexvolume_deprecated/using_sfs_file_systems_as_storage_volumes/kubectl_creating_a_deployment_mounted_with_an_sfs_volume.rst similarity index 100% rename from umn/source/storage_flexvolume/using_sfs_file_systems_as_storage_volumes/kubectl_creating_a_deployment_mounted_with_an_sfs_volume.rst rename to umn/source/storage_management_flexvolume_deprecated/using_sfs_file_systems_as_storage_volumes/kubectl_creating_a_deployment_mounted_with_an_sfs_volume.rst diff --git a/umn/source/storage_flexvolume/using_sfs_file_systems_as_storage_volumes/kubectl_creating_a_pv_from_an_existing_sfs_file_system.rst b/umn/source/storage_management_flexvolume_deprecated/using_sfs_file_systems_as_storage_volumes/kubectl_creating_a_pv_from_an_existing_sfs_file_system.rst similarity index 100% rename from umn/source/storage_flexvolume/using_sfs_file_systems_as_storage_volumes/kubectl_creating_a_pv_from_an_existing_sfs_file_system.rst rename to umn/source/storage_management_flexvolume_deprecated/using_sfs_file_systems_as_storage_volumes/kubectl_creating_a_pv_from_an_existing_sfs_file_system.rst diff --git a/umn/source/storage_flexvolume/using_sfs_file_systems_as_storage_volumes/kubectl_creating_a_statefulset_mounted_with_an_sfs_volume.rst b/umn/source/storage_management_flexvolume_deprecated/using_sfs_file_systems_as_storage_volumes/kubectl_creating_a_statefulset_mounted_with_an_sfs_volume.rst similarity index 100% rename from umn/source/storage_flexvolume/using_sfs_file_systems_as_storage_volumes/kubectl_creating_a_statefulset_mounted_with_an_sfs_volume.rst rename to umn/source/storage_management_flexvolume_deprecated/using_sfs_file_systems_as_storage_volumes/kubectl_creating_a_statefulset_mounted_with_an_sfs_volume.rst diff --git a/umn/source/storage_flexvolume/using_sfs_file_systems_as_storage_volumes/overview.rst b/umn/source/storage_management_flexvolume_deprecated/using_sfs_file_systems_as_storage_volumes/overview.rst similarity index 95% rename from umn/source/storage_flexvolume/using_sfs_file_systems_as_storage_volumes/overview.rst rename to umn/source/storage_management_flexvolume_deprecated/using_sfs_file_systems_as_storage_volumes/overview.rst index 6567c03..58b0917 100644 --- a/umn/source/storage_flexvolume/using_sfs_file_systems_as_storage_volumes/overview.rst +++ b/umn/source/storage_management_flexvolume_deprecated/using_sfs_file_systems_as_storage_volumes/overview.rst @@ -8,7 +8,7 @@ Overview CCE allows you to mount a volume created from a Scalable File Service (SFS) file system to a container to store data persistently. SFS volumes are commonly used in ReadWriteMany scenarios, such as media processing, content management, big data analysis, and workload process analysis. -.. figure:: /_static/images/en-us_image_0000001201823500.png +.. figure:: /_static/images/en-us_image_0000001568822709.png :alt: **Figure 1** Mounting SFS volumes to CCE **Figure 1** Mounting SFS volumes to CCE diff --git a/umn/source/storage_flexvolume/using_sfs_turbo_file_systems_as_storage_volumes/index.rst b/umn/source/storage_management_flexvolume_deprecated/using_sfs_turbo_file_systems_as_storage_volumes/index.rst similarity index 100% rename from umn/source/storage_flexvolume/using_sfs_turbo_file_systems_as_storage_volumes/index.rst rename to umn/source/storage_management_flexvolume_deprecated/using_sfs_turbo_file_systems_as_storage_volumes/index.rst diff --git a/umn/source/storage_flexvolume/using_sfs_turbo_file_systems_as_storage_volumes/kubectl_creating_a_deployment_mounted_with_an_sfs_turbo_volume.rst b/umn/source/storage_management_flexvolume_deprecated/using_sfs_turbo_file_systems_as_storage_volumes/kubectl_creating_a_deployment_mounted_with_an_sfs_turbo_volume.rst similarity index 100% rename from umn/source/storage_flexvolume/using_sfs_turbo_file_systems_as_storage_volumes/kubectl_creating_a_deployment_mounted_with_an_sfs_turbo_volume.rst rename to umn/source/storage_management_flexvolume_deprecated/using_sfs_turbo_file_systems_as_storage_volumes/kubectl_creating_a_deployment_mounted_with_an_sfs_turbo_volume.rst diff --git a/umn/source/storage_flexvolume/using_sfs_turbo_file_systems_as_storage_volumes/kubectl_creating_a_pv_from_an_existing_sfs_turbo_file_system.rst b/umn/source/storage_management_flexvolume_deprecated/using_sfs_turbo_file_systems_as_storage_volumes/kubectl_creating_a_pv_from_an_existing_sfs_turbo_file_system.rst similarity index 100% rename from umn/source/storage_flexvolume/using_sfs_turbo_file_systems_as_storage_volumes/kubectl_creating_a_pv_from_an_existing_sfs_turbo_file_system.rst rename to umn/source/storage_management_flexvolume_deprecated/using_sfs_turbo_file_systems_as_storage_volumes/kubectl_creating_a_pv_from_an_existing_sfs_turbo_file_system.rst diff --git a/umn/source/storage_flexvolume/using_sfs_turbo_file_systems_as_storage_volumes/kubectl_creating_a_statefulset_mounted_with_an_sfs_turbo_volume.rst b/umn/source/storage_management_flexvolume_deprecated/using_sfs_turbo_file_systems_as_storage_volumes/kubectl_creating_a_statefulset_mounted_with_an_sfs_turbo_volume.rst similarity index 100% rename from umn/source/storage_flexvolume/using_sfs_turbo_file_systems_as_storage_volumes/kubectl_creating_a_statefulset_mounted_with_an_sfs_turbo_volume.rst rename to umn/source/storage_management_flexvolume_deprecated/using_sfs_turbo_file_systems_as_storage_volumes/kubectl_creating_a_statefulset_mounted_with_an_sfs_turbo_volume.rst diff --git a/umn/source/storage_flexvolume/using_sfs_turbo_file_systems_as_storage_volumes/overview.rst b/umn/source/storage_management_flexvolume_deprecated/using_sfs_turbo_file_systems_as_storage_volumes/overview.rst similarity index 94% rename from umn/source/storage_flexvolume/using_sfs_turbo_file_systems_as_storage_volumes/overview.rst rename to umn/source/storage_management_flexvolume_deprecated/using_sfs_turbo_file_systems_as_storage_volumes/overview.rst index 68c379d..a99cb85 100644 --- a/umn/source/storage_flexvolume/using_sfs_turbo_file_systems_as_storage_volumes/overview.rst +++ b/umn/source/storage_management_flexvolume_deprecated/using_sfs_turbo_file_systems_as_storage_volumes/overview.rst @@ -8,7 +8,7 @@ Overview CCE allows you to mount a volume created from an SFS Turbo file system to a container to store data persistently. Provisioned on demand and fast, SFS Turbo is suitable for DevOps, container microservices, and enterprise OA scenarios. -.. figure:: /_static/images/en-us_image_0000001202103502.png +.. figure:: /_static/images/en-us_image_0000001568902669.png :alt: **Figure 1** Mounting SFS Turbo volumes to CCE **Figure 1** Mounting SFS Turbo volumes to CCE diff --git a/umn/source/what_is_cloud_container_engine.rst b/umn/source/what_is_cloud_container_engine.rst deleted file mode 100644 index 3639733..0000000 --- a/umn/source/what_is_cloud_container_engine.rst +++ /dev/null @@ -1,15 +0,0 @@ -:original_name: cce_01_0091.html - -.. _cce_01_0091: - -What Is Cloud Container Engine? -=============================== - -Cloud Container Engine (CCE) provides highly scalable, high-performance, enterprise-class Kubernetes clusters and supports Docker containers. With CCE, you can easily deploy, manage, and scale containerized applications on the cloud. - -CCE is deeply integrated with the public cloud services, including high-performance computing (ECS), network (VPC, EIP, and ELB), and storage (EVS and SFS) services. It supports heterogeneous computing architectures such as GPU, ARM, and FPGA. By using multi-AZ and multi-region disaster recovery, CCE ensures high availability of Kubernetes clusters. - -You can use CCE through the console, kubectl, and `APIs `__. Before using the CCE service, learn about the concepts related to Kubernetes. For details, see https://kubernetes.io/docs/concepts/. - -- Junior users: You are advised to use the console. The console provides an intuitive interface for you to complete operations such as creating clusters or workloads. -- Advanced users: If you have experience in using kubectl, you are advised to use the kubectl, and `APIs `__ to perform operations. For details, see `Kubernetes APIs `__ and `kubectl CLI `__. diff --git a/umn/source/workloads/accessing_a_container.rst b/umn/source/workloads/accessing_a_container.rst new file mode 100644 index 0000000..6fd23a8 --- /dev/null +++ b/umn/source/workloads/accessing_a_container.rst @@ -0,0 +1,49 @@ +:original_name: cce_10_00356.html + +.. _cce_10_00356: + +Accessing a Container +===================== + +Scenario +-------- + +If you encounter unexpected problems when using a container, you can log in to the container for debugging. + +Logging In to a Container Using kubectl +--------------------------------------- + +#. Use kubectl to connect to the cluster. For details, see :ref:`Connecting to a Cluster Using kubectl `. + +#. Run the following command to view the created pod: + + .. code-block:: + + kubectl get pod + + The example output is as follows: + + .. code-block:: + + NAME READY STATUS RESTARTS AGE + nginx-59d89cb66f-mhljr 1/1 Running 0 11m + +#. Query the name of the container in the pod. + + .. code-block:: + + kubectl get po nginx-59d89cb66f-mhljr -o jsonpath='{range .spec.containers[*]}{.name}{end}{"\n"}' + + The example output is as follows: + + .. code-block:: + + container-1 + +#. Run the following command to log in to the container named **container-1** in **nginx-59d89cb66f-mhljrPod**: + + .. code-block:: + + kubectl exec -it nginx-59d89cb66f-mhljr -c container-1 -- /bin/sh + +#. To exit the container, run the **exit** command. diff --git a/umn/source/workloads/configuring_a_container/scheduling_policy_affinity_anti-affinity.rst b/umn/source/workloads/configuring_a_container/scheduling_policy_affinity_anti-affinity.rst index 8952f33..f183f54 100644 --- a/umn/source/workloads/configuring_a_container/scheduling_policy_affinity_anti-affinity.rst +++ b/umn/source/workloads/configuring_a_container/scheduling_policy_affinity_anti-affinity.rst @@ -239,7 +239,7 @@ From the preceding output, you can find that no pods of the Deployment are sched In the preceding example, the node scheduling priority is as follows. Nodes with both **SSD** and **gpu=true** labels have the highest priority. Nodes with the **SSD** label but no **gpu=true** label have the second priority (weight: 80). Nodes with the **gpu=true** label but no **SSD** label have the third priority. Nodes without any of these two labels have the lowest priority. -.. figure:: /_static/images/en-us_image_0000001202101148.png +.. figure:: /_static/images/en-us_image_0000001569022881.png :alt: **Figure 1** Scheduling priority **Figure 1** Scheduling priority @@ -341,7 +341,7 @@ Add the **prefer=true** label to nodes **192.168.0.97** and **192.168.0.94**. 192.168.0.94 Ready 91m v1.15.6-r1-20.3.0.2.B001-15.30.2 true 192.168.0.97 Ready 91m v1.15.6-r1-20.3.0.2.B001-15.30.2 true -Define **topologyKey** in the **podAffinity** section as **prefer**. +Define **topologyKey** in the **podAffinity** section as **prefer**. The node topology domains are divided as shown in :ref:`Figure 2 `. .. code-block:: @@ -356,7 +356,14 @@ Define **topologyKey** in the **podAffinity** section as **prefer**. values: - backend -The scheduler recognizes the nodes with the **prefer** label, that is, **192.168.0.97** and **192.168.0.94**, and then find the pods with the **app=backend** label. In this way, all frontend pods are deployed onto **192.168.0.97**. +.. _cce_10_0232__fig511152614544: + +.. figure:: /_static/images/en-us_image_0000001517903036.png + :alt: **Figure 2** Topology domain example + + **Figure 2** Topology domain example + +During scheduling, node topology domains are divided based on the **prefer** label. In this example, **192.168.0.97** and **192.168.0.94** are divided into the same topology domain. If pods with the **app=backend** label run in **192.168.0.97**, all frontend pods are deployed onto **192.168.0.97** or **192.168.0.94**. .. code-block:: @@ -376,7 +383,7 @@ Workload Anti-Affinity (podAntiAffinity) Unlike the scenarios in which pods are preferred to be scheduled onto the same node, sometimes, it could be the exact opposite. For example, if certain pods are deployed together, they will affect the performance. -The following example defines an inter-pod anti-affinity rule, which specifies that pods must not be scheduled to nodes that already have pods with the **app=frontend** label, that is, to deploy the pods of the frontend to different nodes with each node has only one replica. +In the following example, an anti-affinity rule is defined. This rule indicates that node topology domains are divided based on the **kubernetes.io/hostname** label. If a pod with the **app=frontend** label already exists on a node in the topology domain, pods with the same label cannot be scheduled to other nodes in the topology domain. .. code-block:: @@ -411,15 +418,15 @@ The following example defines an inter-pod anti-affinity rule, which specifies t affinity: podAntiAffinity: requiredDuringSchedulingIgnoredDuringExecution: - - topologyKey: kubernetes.io/hostname - labelSelector: + - topologyKey: kubernetes.io/hostname # Node topology domain + labelSelector: # Pod label matching rule matchExpressions: - key: app operator: In values: - frontend -Deploy the frontend and query the deployment results. You can find that each node has only one frontend pod and one pod of the Deployment is **Pending**. This is because when the scheduler is deploying the fifth pod, all nodes already have one pod with the **app=frontend** label on them. There is no available node. Therefore, the fifth pod will remain in the **Pending** status. +Create an anti-affinity rule and view the deployment result. In the example, node topology domains are divided by the **kubernetes.io/hostname** label. Among nodes with the **kubernetes.io/hostname** label, the label value of each node is different. Therefore, there is only one node in a topology domain. If a frontend pod already exists in a topology (a node in this example), the same pods will not be scheduled to this topology. In this example, there are only four nodes. Therefore, another pod is pending and cannot be scheduled. .. code-block:: @@ -484,4 +491,4 @@ Configuring Scheduling Policies | Weight | This parameter can be set only in a **Preferred** scheduling policy. | +-----------------------------------+------------------------------------------------------------------------------------------------------------+ -.. |image1| image:: /_static/images/en-us_image_0000001203031716.png +.. |image1| image:: /_static/images/en-us_image_0000001518062612.png diff --git a/umn/source/workloads/configuring_a_container/setting_an_environment_variable.rst b/umn/source/workloads/configuring_a_container/setting_an_environment_variable.rst index 164e5cc..d2c21ee 100644 --- a/umn/source/workloads/configuring_a_container/setting_an_environment_variable.rst +++ b/umn/source/workloads/configuring_a_container/setting_an_environment_variable.rst @@ -139,4 +139,4 @@ The environment variables in the pod are as follows: configmap_key=configmap_value # Added from ConfigMap. The key value in the original ConfigMap key is directly imported. secret_key=secret_value # Added from key. The key value in the original secret is directly imported. -.. |image1| image:: /_static/images/en-us_image_0000001247802971.png +.. |image1| image:: /_static/images/en-us_image_0000001569022913.png diff --git a/umn/source/workloads/configuring_a_container/setting_health_check_for_a_container.rst b/umn/source/workloads/configuring_a_container/setting_health_check_for_a_container.rst index 5a41319..3faac5f 100644 --- a/umn/source/workloads/configuring_a_container/setting_health_check_for_a_container.rst +++ b/umn/source/workloads/configuring_a_container/setting_health_check_for_a_container.rst @@ -14,7 +14,7 @@ Kubernetes provides the following health check probes: - **Liveness probe** (livenessProbe): checks whether a container is still alive. It is similar to the **ps** command that checks whether a process exists. If the liveness check of a container fails, the cluster restarts the container. If the liveness check is successful, no operation is executed. - **Readiness probe** (readinessProbe): checks whether a container is ready to process user requests. Upon that the container is detected unready, service traffic will not be directed to the container. It may take a long time for some applications to start up before they can provide services. This is because that they need to load disk data or rely on startup of an external module. In this case, the application process is running, but the application cannot provide services. To address this issue, this health check probe is used. If the container readiness check fails, the cluster masks all requests sent to the container. If the container readiness check is successful, the container can be accessed. -- **Startup probe** (startupProbe): checks when a container application has started. If such a probe is configured, it disables liveness and readiness checks until it succeeds, ensuring that those probes do not interfere with the application startup. This can be used to adopt liveness checks on slow starting containers, avoiding them getting killed by the kubelet before they are started. +- **Startup probe** (startupProbe): checks when a container application has started. If such a probe is configured, it disables liveness and readiness checks until it succeeds, ensuring that those probes do not interfere with the application startup. This can be used to adopt liveness checks on slow starting containers, avoiding them getting terminated by the kubelet before they are started. Check Method ------------ @@ -37,9 +37,9 @@ Check Method The CLI mode can be used to replace the HTTP request-based and TCP port-based health check. - - For a TCP port, you can write a program script to connect to a container port. If the connection is successful, the script returns **0**. Otherwise, the script returns **-1**. + - For a TCP port, you can use a program script to connect to a container port. If the connection is successful, the script returns **0**. Otherwise, the script returns **-1**. - - For an HTTP request, you can write a program script to run the **wget** command for a container. + - For an HTTP request, you can use the script command to run the **wget** command to detect the container. **wget http://127.0.0.1:80/health-check** diff --git a/umn/source/workloads/cpu_core_binding/binding_cpu_cores.rst b/umn/source/workloads/cpu_core_binding/binding_cpu_cores.rst index 754725a..d489906 100644 --- a/umn/source/workloads/cpu_core_binding/binding_cpu_cores.rst +++ b/umn/source/workloads/cpu_core_binding/binding_cpu_cores.rst @@ -77,4 +77,4 @@ For CPU, both **requests** and **limits** must be set to the same, and **request imagePullSecrets: - name: default-secret -.. |image1| image:: /_static/images/en-us_image_0000001244261055.png +.. |image1| image:: /_static/images/en-us_image_0000001569022837.png diff --git a/umn/source/workloads/creating_a_cron_job.rst b/umn/source/workloads/creating_a_cron_job.rst index 1fb71f1..a60eba4 100644 --- a/umn/source/workloads/creating_a_cron_job.rst +++ b/umn/source/workloads/creating_a_cron_job.rst @@ -37,7 +37,7 @@ Using the CCE Console **Basic Info** - **Workload Type**: Select **Cron Job**. For details about workload types, see :ref:`Overview `. - - **Workload Name**: Enter the name of the workload. + - **Workload Name**: Enter the name of the workload. Enter 1 to 52 characters starting with a lowercase letter and ending with a letter or digit. Only lowercase letters, digits, and hyphens (-) are allowed. - **Namespace**: Select the namespace of the workload. The default value is **default**. You can also click **Create Namespace** to create one. For details, see :ref:`Creating a Namespace `. - **Container Runtime**: A CCE cluster uses runC by default, whereas a CCE Turbo cluster supports both runC and Kata. For details about the differences between runC and Kata, see :ref:`Kata Containers and Common Containers `. diff --git a/umn/source/workloads/creating_a_daemonset.rst b/umn/source/workloads/creating_a_daemonset.rst index c448262..e6e02cc 100644 --- a/umn/source/workloads/creating_a_daemonset.rst +++ b/umn/source/workloads/creating_a_daemonset.rst @@ -37,7 +37,7 @@ Using the CCE Console **Basic Info** - **Workload Type**: Select **DaemonSet**. For details about workload types, see :ref:`Overview `. - - **Workload Name**: Enter the name of the workload. + - **Workload Name**: Enter the name of the workload. Enter 1 to 63 characters starting with a lowercase letter and ending with a letter or digit. Only lowercase letters, digits, and hyphens (-) are allowed. - **Namespace**: Select the namespace of the workload. The default value is **default**. You can also click **Create Namespace** to create one. For details, see :ref:`Creating a Namespace `. - **Container Runtime**: A CCE cluster uses runC by default, whereas a CCE Turbo cluster supports both runC and Kata. For details about the differences between runC and Kata, see :ref:`Kata Containers and Common Containers `. - **Time Zone Synchronization**: Specify whether to enable time zone synchronization. After time zone synchronization is enabled, the container and node use the same time zone. The time zone synchronization function depends on the local disk mounted to the container. Do not modify or delete the time zone. For details, see :ref:`Configuring Time Zone Synchronization `. diff --git a/umn/source/workloads/creating_a_deployment.rst b/umn/source/workloads/creating_a_deployment.rst index 3972467..70eddd1 100644 --- a/umn/source/workloads/creating_a_deployment.rst +++ b/umn/source/workloads/creating_a_deployment.rst @@ -32,7 +32,7 @@ Using the CCE Console **Basic Info** - **Workload Type**: Select **Deployment**. For details about workload types, see :ref:`Overview `. - - **Workload Name**: Enter the name of the workload. + - **Workload Name**: Enter the name of the workload. Enter 1 to 63 characters starting with a lowercase letter and ending with a letter or digit. Only lowercase letters, digits, and hyphens (-) are allowed. - **Namespace**: Select the namespace of the workload. The default value is **default**. You can also click **Create Namespace** to create one. For details, see :ref:`Creating a Namespace `. - **Pods**: Enter the number of pods. - **Container Runtime**: A CCE cluster uses runC by default, whereas a CCE Turbo cluster supports both runC and Kata. For details about the differences between runC and Kata, see :ref:`Kata Containers and Common Containers `. diff --git a/umn/source/workloads/creating_a_job.rst b/umn/source/workloads/creating_a_job.rst index 1e54800..60dff9a 100644 --- a/umn/source/workloads/creating_a_job.rst +++ b/umn/source/workloads/creating_a_job.rst @@ -35,7 +35,7 @@ Using the CCE Console **Basic Info** - **Workload Type**: Select **Job**. For details about workload types, see :ref:`Overview `. - - **Workload Name**: Enter the name of the workload. + - **Workload Name**: Enter the name of the workload. Enter 1 to 63 characters starting with a lowercase letter and ending with a letter or digit. Only lowercase letters, digits, and hyphens (-) are allowed. - **Namespace**: Select the namespace of the workload. The default value is **default**. You can also click **Create Namespace** to create one. For details, see :ref:`Creating a Namespace `. - **Pods**: Enter the number of pods. - **Container Runtime**: A CCE cluster uses runC by default, whereas a CCE Turbo cluster supports both runC and Kata. For details about the differences between runC and Kata, see :ref:`Kata Containers and Common Containers `. diff --git a/umn/source/workloads/creating_a_statefulset.rst b/umn/source/workloads/creating_a_statefulset.rst index 609566a..5df9b16 100644 --- a/umn/source/workloads/creating_a_statefulset.rst +++ b/umn/source/workloads/creating_a_statefulset.rst @@ -42,7 +42,7 @@ Using the CCE Console **Basic Info** - **Workload Type**: Select **StatefulSet**. For details about workload types, see :ref:`Overview `. - - **Workload Name**: Enter the name of the workload. + - **Workload Name**: Enter the name of the workload. Enter 1 to 52 characters starting with a lowercase letter and ending with a letter or digit. Only lowercase letters, digits, and hyphens (-) are allowed. - **Namespace**: Select the namespace of the workload. The default value is **default**. You can also click **Create Namespace** to create one. For details, see :ref:`Creating a Namespace `. - **Pods**: Enter the number of pods. - **Container Runtime**: A CCE cluster uses runC by default, whereas a CCE Turbo cluster supports both runC and Kata. For details about the differences between runC and Kata, see :ref:`Kata Containers and Common Containers `. diff --git a/umn/source/workloads/gpu_scheduling.rst b/umn/source/workloads/gpu_scheduling.rst index e571069..21bac57 100644 --- a/umn/source/workloads/gpu_scheduling.rst +++ b/umn/source/workloads/gpu_scheduling.rst @@ -85,7 +85,7 @@ After **nvidia.com/gpu** is specified, workloads will not be scheduled to nodes To use GPUs on the CCE console, select the GPU quota and specify the percentage of GPUs reserved for the container when creating a workload. -.. figure:: /_static/images/en-us_image_0000001397733101.png +.. figure:: /_static/images/en-us_image_0000001569022929.png :alt: **Figure 1** Using GPUs **Figure 1** Using GPUs diff --git a/umn/source/workloads/index.rst b/umn/source/workloads/index.rst index fd71f38..4666ee9 100644 --- a/umn/source/workloads/index.rst +++ b/umn/source/workloads/index.rst @@ -15,6 +15,7 @@ Workloads - :ref:`Configuring a Container ` - :ref:`GPU Scheduling ` - :ref:`CPU Core Binding ` +- :ref:`Accessing a Container ` - :ref:`Pod Labels and Annotations ` - :ref:`Volcano Scheduling ` - :ref:`Security Group Policies ` @@ -33,6 +34,7 @@ Workloads configuring_a_container/index gpu_scheduling cpu_core_binding/index + accessing_a_container pod_labels_and_annotations volcano_scheduling/index security_group_policies diff --git a/umn/source/workloads/managing_workloads_and_jobs.rst b/umn/source/workloads/managing_workloads_and_jobs.rst index 93652dc..608c8e4 100644 --- a/umn/source/workloads/managing_workloads_and_jobs.rst +++ b/umn/source/workloads/managing_workloads_and_jobs.rst @@ -12,31 +12,31 @@ After a workload is created, you can upgrade, monitor, roll back, or delete the .. table:: **Table 1** Workload/Job management - +-------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ - | Operation | Description | - +=====================================================================================+================================================================================================================================================================================================+ - | :ref:`Monitor ` | You can view the CPU and memory usage of workloads and pods on the CCE console. | - +-------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ - | :ref:`View Log ` | You can view the logs of workloads. | - +-------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ - | :ref:`Upgrade ` | You can replace images or image tags to quickly upgrade Deployments, StatefulSets, and DaemonSets without interrupting services. | - +-------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ - | :ref:`Edit YAML ` | You can modify and download the YAML files of Deployments, StatefulSets, DaemonSets, and pods on the CCE console. YAML files of jobs and cron jobs can only be viewed, copied, and downloaded. | - +-------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ - | :ref:`Roll Back ` | Only Deployments can be rolled back. | - +-------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ - | :ref:`Redeploy ` | You can redeploy a workload. After the workload is redeployed, all pods in the workload will be restarted. | - +-------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ - | :ref:`Enabling/Disabling the Upgrade ` | Only Deployments support this operation. | - +-------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ - | :ref:`Manage Label ` | Labels are key-value pairs and can be attached to workloads for affinity and anti-affinity scheduling. Jobs and Cron Jobs do not support this operation. | - +-------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ - | :ref:`Delete ` | You can delete a workload or job that is no longer needed. Deleted workloads or jobs cannot be recovered. | - +-------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ - | :ref:`View Events ` | You can view event names, event types, number of occurrences, Kubernetes events, first occurrence time, and last occurrence time. | - +-------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ - | Stop/Start | You can only start or stop a cron job. | - +-------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + +------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | Operation | Description | + +================================================================================================+================================================================================================================================================================================================+ + | :ref:`Monitor ` | You can view the CPU and memory usage of workloads and pods on the CCE console. | + +------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | :ref:`View Log ` | You can view the logs of workloads. | + +------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | :ref:`Upgrade ` | You can replace images or image tags to quickly upgrade Deployments, StatefulSets, and DaemonSets without interrupting services. | + +------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | :ref:`Edit YAML ` | You can modify and download the YAML files of Deployments, StatefulSets, DaemonSets, and pods on the CCE console. YAML files of jobs and cron jobs can only be viewed, copied, and downloaded. | + +------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | :ref:`Roll Back ` | Only Deployments can be rolled back. | + +------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | :ref:`Redeploy ` | You can redeploy a workload. After the workload is redeployed, all pods in the workload will be restarted. | + +------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | :ref:`Enabling/Disabling the Upgrade ` | Only Deployments support this operation. | + +------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | :ref:`Manage Label ` | Labels are key-value pairs and can be attached to workloads for affinity and anti-affinity scheduling. Jobs and Cron Jobs do not support this operation. | + +------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | :ref:`Delete ` | You can delete a workload or job that is no longer needed. Deleted workloads or jobs cannot be recovered. | + +------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | :ref:`View Events ` | You can view event names, event types, number of occurrences, Kubernetes events, first occurrence time, and last occurrence time. | + +------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | Stop/Start | You can only start or stop a cron job. | + +------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ .. _cce_10_0007__section7200124254011: @@ -49,7 +49,7 @@ You can view the CPU and memory usage of Deployments and pods on the CCE console #. Click the **Deployments** tab and click **Monitor** of the target workload. On the page that is displayed, you can view CPU usage and memory usage of the workload. #. Click the workload name. On the **Pods** tab page, click the **Monitor** of the target pod to view its CPU and memory usage. -.. _cce_10_0007__cce_01_0007_section51511928173817: +.. _cce_10_0007__en-us_topic_0107283638_section51511928173817: Viewing Logs ------------ @@ -62,7 +62,7 @@ You can view logs of Deployments, StatefulSets, DaemonSets, and jobs. This secti On the displayed **View Log** window, you can view logs by time. -.. _cce_10_0007__cce_01_0007_section17604174417381: +.. _cce_10_0007__en-us_topic_0107283638_section17604174417381: Upgrading a Workload -------------------- @@ -84,7 +84,7 @@ Before replacing an image or image version, upload the new image to the SWR serv #. Upgrade the workload based on service requirements. The method for setting parameter is the same as that for creating a workload. #. After the update is complete, click **Upgrade Workload**, manually confirm the YAML file, and submit the upgrade. -.. _cce_10_0007__cce_01_0007_section21669213390: +.. _cce_10_0007__en-us_topic_0107283638_section21669213390: Editing a YAML file ------------------- @@ -96,7 +96,7 @@ You can modify and download the YAML files of Deployments, StatefulSets, DaemonS #. Click **Edit** and then **OK** to save the changes. #. (Optional) In the **Edit YAML** window, click **Download** to download the YAML file. -.. _cce_10_0007__cce_01_0007_section13324541124815: +.. _cce_10_0007__en-us_topic_0107283638_section13324541124815: Rolling Back a Workload (Available Only for Deployments) -------------------------------------------------------- @@ -118,7 +118,7 @@ After you redeploy a workload, all pods in the workload will be restarted. This #. Click the **Deployments** tab and choose **More** > **Redeploy** in the **Operation** column of the target workload. #. In the dialog box that is displayed, click **Yes** to redeploy the workload. -.. _cce_10_0007__cce_01_0007_section12087915401: +.. _cce_10_0007__en-us_topic_0107283638_section12087915401: Disabling/Enabling Upgrade (Available Only for Deployments) ----------------------------------------------------------- @@ -139,7 +139,7 @@ Only Deployments support this operation. #. Click the **Deployments** tab and choose **More** > **Disable/Enable Upgrade** in the **Operation** column of the workload. #. In the dialog box that is displayed, click **Yes**. -.. _cce_10_0007__cce_01_0007_section5931193015488: +.. _cce_10_0007__en-us_topic_0107283638_section5931193015488: Managing Labels --------------- @@ -157,7 +157,7 @@ In the following figure, three labels (release, env, and role) are defined for w If you set **key** to **role** and **value** to **frontend** when using workload scheduling or another function, APP 1 and APP 2 will be selected. -.. figure:: /_static/images/en-us_image_0000001408895746.png +.. figure:: /_static/images/en-us_image_0000001517903028.png :alt: **Figure 1** Label example **Figure 1** Label example @@ -170,7 +170,7 @@ If you set **key** to **role** and **value** to **frontend** when using workload A key-value pair must contain 1 to 63 characters starting and ending with a letter or digit. Only letters, digits, hyphens (-), underscores (_), and periods (.) are allowed. -.. _cce_10_0007__cce_01_0007_section14423721191418: +.. _cce_10_0007__en-us_topic_0107283638_section14423721191418: Deleting a Workload/Job ----------------------- @@ -190,7 +190,7 @@ You can delete a workload or job that is no longer needed. Deleted workloads or - If the node where the pod is located is unavailable or shut down and the workload cannot be deleted, you can forcibly delete the pod from the pod list on the workload details page. - Ensure that the storage volumes to be deleted are not used by other workloads. If these volumes are imported or have snapshots, you can only unbind them. -.. _cce_10_0007__cce_01_0007_section1947616516301: +.. _cce_10_0007__en-us_topic_0107283638_section1947616516301: Viewing Events -------------- diff --git a/umn/source/workloads/overview.rst b/umn/source/workloads/overview.rst index fadd735..84ab7aa 100644 --- a/umn/source/workloads/overview.rst +++ b/umn/source/workloads/overview.rst @@ -20,7 +20,7 @@ Pods can be used in either of the following ways: .. _cce_10_0006__en-us_topic_0254767870_fig347141918551: - .. figure:: /_static/images/en-us_image_0258392378.png + .. figure:: /_static/images/en-us_image_0000001518222716.png :alt: **Figure 1** Pod **Figure 1** Pod @@ -33,7 +33,7 @@ Deployment A pod is the smallest and simplest unit that you create or deploy in Kubernetes. It is designed to be an ephemeral, one-off entity. A pod can be evicted when node resources are insufficient and disappears along with a cluster node failure. Kubernetes provides controllers to manage pods. Controllers can create and manage pods, and provide replica management, rolling upgrade, and self-healing capabilities. The most commonly used controller is Deployment. -.. figure:: /_static/images/en-us_image_0258095884.png +.. figure:: /_static/images/en-us_image_0000001569023033.png :alt: **Figure 2** Relationship between a Deployment and pods **Figure 2** Relationship between a Deployment and pods @@ -72,7 +72,7 @@ A DaemonSet runs a pod on each node in a cluster and ensures that there is only DaemonSets are closely related to nodes. If a node becomes faulty, the DaemonSet will not create the same pods on other nodes. -.. figure:: /_static/images/en-us_image_0258871213.png +.. figure:: /_static/images/en-us_image_0000001518062772.png :alt: **Figure 3** DaemonSet **Figure 3** DaemonSet @@ -112,4 +112,4 @@ Workload Lifecycle | Pausing | The workload is being paused. | +------------------------+-------------------------------------------------------------------------------------------------------------------------+ -.. |image1| image:: /_static/images/en-us_image_0258203193.png +.. |image1| image:: /_static/images/en-us_image_0000001517743628.png diff --git a/umn/source/workloads/volcano_scheduling/hybrid_deployment_of_online_and_offline_jobs.rst b/umn/source/workloads/volcano_scheduling/hybrid_deployment_of_online_and_offline_jobs.rst index 49a4ad0..03b7138 100644 --- a/umn/source/workloads/volcano_scheduling/hybrid_deployment_of_online_and_offline_jobs.rst +++ b/umn/source/workloads/volcano_scheduling/hybrid_deployment_of_online_and_offline_jobs.rst @@ -23,7 +23,7 @@ Resource oversubscription is the process of making use of idle requested resourc Hybrid deployment of online and offline jobs in a cluster can better utilize cluster resources. -.. figure:: /_static/images/en-us_image_0000001378942548.png +.. figure:: /_static/images/en-us_image_0000001568902489.png :alt: **Figure 1** Resource oversubscription **Figure 1** Resource oversubscription @@ -83,14 +83,15 @@ Notes and Constraints - Kubernetes version: - - 1.19: 1.19.16-r4 or later - - 1.21: 1.21.7-r0 or later - - 1.23: 1.23.5-r0 or later + - v1.19: v1.19.16-r4 or later + - v1.21: v1.21.7-r0 or later + - v1.23: v1.23.5-r0 or later + - v1.25 or later -- Cluster Type: CCE or CCE Turbo +- Cluster type: CCE or CCE Turbo - Node OS: EulerOS 2.9 (kernel-4.18.0-147.5.1.6.h729.6.eulerosv2r9.x86_64) -- Node Type: ECS -- The volcano add-on version: 1.7.0 or later +- Node type: ECS +- volcano add-on version: 1.7.0 or later **Constraints** @@ -505,6 +506,132 @@ The following uses an example to describe how to deploy online and offline jobs online-6f44bb68bd-b8z9p 1/1 Running 0 24m 192.168.10.18 192.168.0.173 online-6f44bb68bd-g6xk8 1/1 Running 0 24m 192.168.10.69 192.168.0.173 +#. Log in to the CCE console and access the cluster console. + +#. In the navigation pane on the left, choose **Nodes**. Click the **Node Pools** tab. When creating or updating a node pool, enable hybrid deployment of online and offline services in **Advanced Settings**. + +#. In the navigation pane on the left, choose **Add-ons**. Click **Install** under volcano. In the **Advanced Settings** area, set **colocation_enable** to **true** to enable hybrid deployment of online and offline services. For details about the installation, see :ref:`volcano `. + + If the volcano add-on has been installed, click **Edit** to view or modify the parameter **colocation_enable**. + +#. Enable CPU Burst. + + After confirming that the volcano add-on is working, run the following command to edit the parameter **configmap** of **volcano-agent-configuration** in the namespace **kube-system**. If **enable** is set to **true**, CPU Burst is enabled. If **enable** is set to **false**, CPU Burst is disabled. + + .. code-block:: + + kubectl edit configmap -nkube-system volcano-agent-configuration + + Example: + + .. code-block:: + + cpuBurstConfig: + enable: true + +#. Deploy a workload in a node pool where hybrid deployment has been enabled. Take Nginx as an example. Set **cpu** under **requests** to **2** and **cpu** under **limits** to **4**, and create a Service that can be accessed in the cluster for the workload. + + .. code-block:: + + apiVersion: apps/v1 + kind: Deployment + metadata: + name: nginx + namespace: default + spec: + replicas: 2 + selector: + matchLabels: + app: nginx + template: + metadata: + labels: + app: nginx + annotations: + volcano.sh/enable-quota-burst=true + volcano.sh/quota-burst-time=200000 + spec: + containers: + - name: container-1 + image: nginx:latest + resources: + limits: + cpu: "4" + requests: + cpu: "2" + imagePullSecrets: + - name: default-secret + --- + apiVersion: v1 + kind: Service + metadata: + name: nginx + namespace: default + labels: + app: nginx + spec: + selector: + app: nginx + ports: + - name: cce-service-0 + targetPort: 80 + nodePort: 0 + port: 80 + protocol: TCP + type: ClusterIP + + +------------------------------------+-----------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | Annotation | Mandatory | Description | + +====================================+=======================+=================================================================================================================================================================================================================================================================================================================================================+ + | volcano.sh/enable-quota-burst=true | Yes | CPU Burst is enabled for the workload. | + +------------------------------------+-----------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | volcano.sh/quota-burst-time=200000 | No | To ensure CPU scheduling stability and reduce contention when multiple containers encounter CPU bursts at the same time, the default **CPU Burst** value is the same as the **CPU Quota** value. That is, a container can use a maximum of twice the **CPU Limit** value. By default, **CPU Burst** is set for all service containers in a pod. | + | | | | + | | | In this example, the **CPU Limit** of the container is **4**, that is, the default value is **400,000** (1 core = 100,000), indicating that a maximum of four additional cores can be used after the **CPU Limit** value is reached. | + +------------------------------------+-----------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + +#. Verify CPU Burst. + + You can use the wrk tool to increase load of the workload and observe the service latency, traffic limiting, and CPU limit exceeding when CPU Burst is enabled and disabled, respectively. + + a. Run the following command to increase load of the pod. *$service_ip* indicates the service IP address associated with the pod. + + .. code-block:: + + # You need to download and install the wrk tool on the node. + # The Gzip compression module is enabled in the Apache configuration to simulate the computing logic for the server to process requests. + # Run the following command to increase the load. Note that you need to change the IP address of the target application. + wrk -H "Accept-Encoding: deflate, gzip" -t 4 -c 28 -d 120 --latency --timeout 2s http://$service_ip + + b. Obtain the pod ID. + + .. code-block:: + + kubectl get pods -n -o jsonpath='{.metadata.uid}' + + c. You can run the following command on the node to view the traffic limiting status and CPU limit exceeding status. In the command, *$PodID* indicates the pod ID. + + .. code-block:: + + $cat /sys/fs/cgroup/cpuacct/kubepods/$PodID/cpu.stat + nr_periods 0 # Number of scheduling periods + nr_throttled 0 # Traffic limiting times + throttled_time 0 # Traffic limiting duration (ns) + nr_bursts 0 # CPU Limit exceeding times + burst_time 0 # Total Limit exceeding duration + + .. table:: **Table 3** Result summary in this example + + +-----------------------+-------------+------------------------+---------------------------+-----------------------+--------------------------------+ + | CPU Burst | P99 Latency | nr_throttled | throttled_time | nr_bursts | bursts_time | + | | | | | | | + | | | Traffic Limiting Times | Traffic Limiting Duration | Limit Exceeding Times | Total Limit Exceeding Duration | + +=======================+=============+========================+===========================+=======================+================================+ + | CPU Burst not enabled | 2.96 ms | 986 | 14.3s | 0 | 0 | + +-----------------------+-------------+------------------------+---------------------------+-----------------------+--------------------------------+ + | CPU Burst enabled | 456 µs | 0 | 0 | 469 | 3.7s | + +-----------------------+-------------+------------------------+---------------------------+-----------------------+--------------------------------+ + Handling Suggestions -------------------- @@ -518,4 +645,4 @@ Handling Suggestions You can reduce the oversubscribed resource types only when the resource allocation rate does not exceed 100%. -.. |image1| image:: /_static/images/en-us_image_0000001207511384.png +.. |image1| image:: /_static/images/en-us_image_0000001518062608.png