yexinru/doc-exports
1
0
Fork 0
forked from docs/doc-exports
Code Pull Requests Activity

CCE UMN: Added the support of the OS for features and cluster versions.

Browse Source 
Reviewed-by: Eotvos, Oliver <oliver.eotvos@t-systems.com>
Co-authored-by: Dong, Qiu Jian <qiujiandong1@huawei.com>
Co-committed-by: Dong, Qiu Jian <qiujiandong1@huawei.com>
This commit is contained in:
Dong, Qiu Jian
2023-06-20 14:52:27 +00:00
committed by zuul
parent e0f19ed93a
commit 3d9cca138b
477 changed files with 11351 additions and 4199 deletions
Download Patch File Download Diff File Expand all files Collapse all files

9
docs/cce/umn/cce_10_0129.html
View File

@ -31,6 +31,11 @@
<td class="cellrowborder" valign="top" width="76%" headers="mcps1.3.3.3.2.2.1.2.3.1.2 "><p id="cce_10_0129__p93701640145120">Number of pods that will be created to match the selected add-on specifications.</p>
</td>
</tr>
<tr id="cce_10_0129__row158631947192617"><td class="cellrowborder" valign="top" width="24%" headers="mcps1.3.3.3.2.2.1.2.3.1.1 "><p id="cce_10_0129__p15864134742615">Multi AZ</p>
</td>
<td class="cellrowborder" valign="top" width="76%" headers="mcps1.3.3.3.2.2.1.2.3.1.2 "><ul id="cce_10_0129__ul4214181752714"><li id="cce_10_0129__li5214161718270"><strong id="cce_10_0129__b14832131496">Preferred</strong>: 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.</li><li id="cce_10_0129__li4214917142716"><strong id="cce_10_0129__b821216403910">Required</strong>: 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.</li></ul>
</td>
</tr>
<tr id="cce_10_0129__row4370840165119"><td class="cellrowborder" valign="top" width="24%" headers="mcps1.3.3.3.2.2.1.2.3.1.1 "><p id="cce_10_0129__p937054045117">Containers</p>
</td>
<td class="cellrowborder" valign="top" width="76%" headers="mcps1.3.3.3.2.2.1.2.3.1.2 "><p id="cce_10_0129__p1437014065110">CPU and memory quotas of the container allowed for the selected add-on specifications.</p>
@ -39,7 +44,7 @@
<tr id="cce_10_0129__row53701440125116"><td class="cellrowborder" valign="top" width="24%" headers="mcps1.3.3.3.2.2.1.2.3.1.1 "><p id="cce_10_0129__p8370124035118">Parameters</p>
</td>
<td class="cellrowborder" valign="top" width="76%" headers="mcps1.3.3.3.2.2.1.2.3.1.2 "><ul id="cce_10_0129__ul221832131618"><li id="cce_10_0129__li12588227858"><strong id="cce_10_0129__b192571453114019">parameterSyncStrategy</strong>: indicates whether to configure consistency check when an add-on is upgraded.<ul id="cce_10_0129__ul9522414615"><li id="cce_10_0129__li19121561511"><strong id="cce_10_0129__b690911564401">ensureConsistent</strong>: indicates that the configuration consistency check is enabled. If the configuration recorded in the cluster is inconsistent with the actual configuration, the add-on cannot be upgraded.</li><li id="cce_10_0129__li119784364"><strong id="cce_10_0129__b13174144274110">force</strong>: indicates that the configuration consistency check is ignored during an upgrade. Ensure that the current effective configuration is the same as the original configuration. After the add-on is upgraded, restore the value of <strong id="cce_10_0129__b4346786426">parameterSyncStrategy</strong> to <strong id="cce_10_0129__b1024311118426">ensureConsistent</strong> and enable the configuration consistency check again.</li></ul>
</li><li id="cce_10_0129__li132885218163"><strong id="cce_10_0129__b234014615612">stub_domains</strong>: A domain name server for a user-defined domain name. The format is a key-value pair. The key is a suffix of DNS domain name, and the value is one or more DNS IP addresses.</li><li id="cce_10_0129__li1821862111168"><strong id="cce_10_0129__b2047082195610">upstream_nameservers</strong>: IP address of the upstream DNS server.</li><li id="cce_10_0129__li93661612125"><strong id="cce_10_0129__b14453761447">servers</strong>: The servers configuration is available since coredns 1.23.1. You can customize the servers configuration. For details, see <a href="https://kubernetes.io/docs/tasks/administer-cluster/dns-custom-nameservers/" target="_blank" rel="noopener noreferrer">dns-custom-nameservers</a>. <strong id="cce_10_0129__b1485722511299">plugins</strong> indicates the configuration of each component in coredns (https://coredns.io/manual/plugins/). You are advised to retain the default configurations in common scenarios to prevent CoreDNS from being unavailable due to configuration errors. Each plugin component contains <strong id="cce_10_0129__b18101940181616">name</strong>, <strong id="cce_10_0129__b9211944201611">parameters</strong> (optional), and <strong id="cce_10_0129__b19277104816161">configBlock</strong> (optional). The format of the generated Corefile is as follows:<p id="cce_10_0129__p17731113172317">$name $parameters {</p>
</li><li id="cce_10_0129__li132885218163"><strong id="cce_10_0129__b234014615612">stub_domains</strong>: A domain name server for a user-defined domain name. The format is a key-value pair. The key is a suffix of DNS domain name, and the value is one or more DNS IP addresses.</li><li id="cce_10_0129__li1821862111168"><strong id="cce_10_0129__b2047082195610">upstream_nameservers</strong>: IP address of the upstream DNS server.</li><li id="cce_10_0129__li93661612125"><strong id="cce_10_0129__b16664191691620">servers</strong>: The servers configuration is available since coredns 1.23.1. You can customize the servers configuration. For details, see <a href="https://kubernetes.io/docs/tasks/administer-cluster/dns-custom-nameservers/" target="_blank" rel="noopener noreferrer">dns-custom-nameservers</a>. <strong id="cce_10_0129__b116642016121614">plugins</strong> indicates the configuration of each component in coredns (https://coredns.io/manual/plugins/). You are advised to retain the default configurations in common scenarios to prevent CoreDNS from being unavailable due to configuration errors. Each plugin component contains <strong id="cce_10_0129__b116641916181618">name</strong>, <strong id="cce_10_0129__b466431611161">parameters</strong> (optional), and <strong id="cce_10_0129__b36641716161612">configBlock</strong> (optional). The format of the generated Corefile is as follows:<p id="cce_10_0129__p17731113172317">$name $parameters {</p>
<p id="cce_10_0129__p1122616245232">$configBlock</p>
<p id="cce_10_0129__p2035773019227">}</p>
<p id="cce_10_0129__p187693475389"><a href="#cce_10_0129__table1420814384015">Table 2</a> describes common plugins.</p>
@ -178,7 +183,7 @@
<ol id="cce_10_0129__ol1895815493314"><li id="cce_10_0129__li29576413330">The query is first sent to the DNS caching layer in coredns.</li><li id="cce_10_0129__li79589463318">From the caching layer, the suffix of the request is examined and then the request is forwarded to the corresponding DNS:<ul id="cce_10_0129__ul29582417338"><li id="cce_10_0129__li495814453313">Names with the cluster suffix, for example, <strong id="cce_10_0129__b11610940133413">.cluster.local</strong>: The request is sent to coredns.</li></ul>
<ul id="cce_10_0129__ul189581349330"><li id="cce_10_0129__li169582413313">Names with the stub domain suffix, for example, <strong id="cce_10_0129__b208218633511">.acme.local</strong>: The request is sent to the configured custom DNS resolver that listens, for example, on 1.2.3.4.</li><li id="cce_10_0129__li195815453320">Names that do not match the suffix (for example, <strong id="cce_10_0129__b13519452133513">widget.com</strong>): The request is forwarded to the upstream DNS.</li></ul>
</li></ol>
<div class="fignone" id="cce_10_0129__fig7582181514118"><span class="figcap"><b>Figure 1 </b>Routing</span><br><span><img id="cce_10_0129__image23305161015" src="en-us_image_0000001199021308.png"></span></div>
<div class="fignone" id="cce_10_0129__fig7582181514118"><span class="figcap"><b>Figure 1 </b>Routing</span><br><span><img id="cce_10_0129__image23305161015" src="en-us_image_0000001568902577.png"></span></div>
</div>
<div>
<div class="familylinks">