forked from docs/doc-exports
qiujiandong1
218900ecfc
Reviewed-by: Gergo-Bence Lorincz <a200452876@noreply.gitea.eco.tsi-dev.otc-service.com> Co-authored-by: qiujiandong1 <qiujiandong1@huawei.com> Co-committed-by: qiujiandong1 <qiujiandong1@huawei.com>
294 lines
43 KiB
HTML
294 lines
43 KiB
HTML
<a name="cce_faq_00018"></a><a name="cce_faq_00018"></a>
|
|
|
|
<h1 class="topictitle1">What Should I Do If a Pod Startup Fails?</h1>
|
|
<div id="body1527579861399"><div class="section" id="cce_faq_00018__section1678344818322"><h4 class="sectiontitle">Fault Locating</h4><p id="cce_faq_00018__p8060118">On the details page of a workload, if an event is displayed indicating that the pod fails to be started, perform the following operations to locate the fault:</p>
|
|
<ol id="cce_faq_00018__ol144628344011"><li id="cce_faq_00018__li84621534609"><span>Log in to the node where the abnormal workload is located.</span></li><li id="cce_faq_00018__li2046211349011"><span>Check the ID of the container where the workload pod exits abnormally.</span><p><p id="cce_faq_00018__p317493216238">If the node uses Docker, run the following command:</p>
|
|
<pre class="screen" id="cce_faq_00018__screen717403262316"><strong id="cce_faq_00018__b533194103918">docker </strong><strong id="cce_faq_00018__b20216208173718">ps -a | grep </strong><em id="cce_faq_00018__i321668163714">$podName</em></pre>
|
|
<div class="p" id="cce_faq_00018__p017473220232">If the node uses containerd, run the following command:<pre class="screen" id="cce_faq_00018__screen10174133214234"><strong id="cce_faq_00018__b2085210924017">crictl <strong id="cce_faq_00018__b148524904012">ps -a | grep </strong></strong><em id="cce_faq_00018__i985211912405">$podName</em></pre>
|
|
</div>
|
|
</p></li><li id="cce_faq_00018__li24628345018"><span>View the container logs.</span><p><p id="cce_faq_00018__p928111265018">If the node uses Docker, run the following command:</p>
|
|
<pre class="screen" id="cce_faq_00018__screen1728142125012"><strong id="cce_faq_00018__b828119212501">docker </strong><strong id="cce_faq_00018__b22812285010">logs </strong><em id="cce_faq_00018__i172811123502">$containerID</em></pre>
|
|
<div class="p" id="cce_faq_00018__p12281152145020">If the node uses containerd, run the following command:<pre class="screen" id="cce_faq_00018__screen142812020502"><strong id="cce_faq_00018__b1828114295014">crictl logs </strong><em id="cce_faq_00018__i328113285011">$containerID</em></pre>
|
|
</div>
|
|
<p id="cce_faq_00018__p146217341015">Rectify the fault of the workload based on logs.</p>
|
|
</p></li><li id="cce_faq_00018__li1446243415015"><span>Check the error logs of the OS. For example, check whether the logs contain any OOM errors.</span><p><pre class="screen" id="cce_faq_00018__screen31721221219"><strong id="cce_faq_00018__b0462103411017">cat /var/log/messages | grep </strong><em id="cce_faq_00018__i346213340019">$containerID</em><strong id="cce_faq_00018__b8462113417019"> | grep oom</strong></pre>
|
|
<p id="cce_faq_00018__p1046233416019">Check whether a system OOM is triggered based on the logs.</p>
|
|
</p></li></ol>
|
|
</div>
|
|
<div class="section" id="cce_faq_00018__section1120918586517"><h4 class="sectiontitle">Troubleshooting</h4><p id="cce_faq_00018__p2058061753513">Determine the cause based on the logs or events, as listed in <a href="#cce_faq_00018__table230510269532">Table 1</a>.</p>
|
|
|
|
<div class="tablenoborder"><a name="cce_faq_00018__table230510269532"></a><a name="table230510269532"></a><table cellpadding="4" cellspacing="0" summary="" id="cce_faq_00018__table230510269532" frame="border" border="1" rules="all"><caption><b>Table 1 </b>Pod startup failure</caption><thead align="left"><tr id="cce_faq_00018__row7305112615310"><th align="left" class="cellrowborder" valign="top" width="33.33333333333333%" id="mcps1.3.2.3.2.4.1.1"><p id="cce_faq_00018__p43051526105316">Log or Event</p>
|
|
</th>
|
|
<th align="left" class="cellrowborder" valign="top" width="33.3033303330333%" id="mcps1.3.2.3.2.4.1.2"><p id="cce_faq_00018__p5305142645320">Possible Cause</p>
|
|
</th>
|
|
<th align="left" class="cellrowborder" valign="top" width="33.36333633363336%" id="mcps1.3.2.3.2.4.1.3"><p id="cce_faq_00018__p1952651717383">Fault Locating and Solution</p>
|
|
</th>
|
|
</tr>
|
|
</thead>
|
|
<tbody><tr id="cce_faq_00018__row8305192615537"><td class="cellrowborder" valign="top" width="33.33333333333333%" headers="mcps1.3.2.3.2.4.1.1 "><p id="cce_faq_00018__p12352113813124">Pod logs: exit code 0</p>
|
|
</td>
|
|
<td class="cellrowborder" valign="top" width="33.3033303330333%" headers="mcps1.3.2.3.2.4.1.2 "><p id="cce_faq_00018__p529515250113">There is no process in the pod.</p>
|
|
</td>
|
|
<td class="cellrowborder" valign="top" width="33.36333633363336%" headers="mcps1.3.2.3.2.4.1.3 "><p id="cce_faq_00018__p10573406384">Check whether the pod can run properly. For details, see <a href="#cce_faq_00018__section2524165018111">No Process in the Pod (Exit Code: 0)</a>.</p>
|
|
</td>
|
|
</tr>
|
|
<tr id="cce_faq_00018__row23051626145317"><td class="cellrowborder" valign="top" width="33.33333333333333%" headers="mcps1.3.2.3.2.4.1.1 "><ul id="cce_faq_00018__ul1182154310588"><li id="cce_faq_00018__li107794514597">Kubernetes event:<pre class="screen" id="cce_faq_00018__screen152213560598">Liveness probe failed: Get http…</pre>
|
|
</li><li id="cce_faq_00018__li1682154318584">Pod logs: exit code 137</li></ul>
|
|
</td>
|
|
<td class="cellrowborder" valign="top" width="33.3033303330333%" headers="mcps1.3.2.3.2.4.1.2 "><p id="cce_faq_00018__p43494383129">The health check fails.</p>
|
|
</td>
|
|
<td class="cellrowborder" valign="top" width="33.36333633363336%" headers="mcps1.3.2.3.2.4.1.3 "><p id="cce_faq_00018__p20715122611398">Check whether the liveness probe for the pod is properly configured. For details, see <a href="#cce_faq_00018__section1766510426482">Health Check Failed (Exit Code: 137)</a>.</p>
|
|
</td>
|
|
</tr>
|
|
<tr id="cce_faq_00018__row1130662675311"><td class="cellrowborder" valign="top" width="33.33333333333333%" headers="mcps1.3.2.3.2.4.1.1 "><ul id="cce_faq_00018__ul7201151175814"><li id="cce_faq_00018__li152011514584">Kubernetes event:<pre class="screen" id="cce_faq_00018__screen553604419593">Thin Pool has 15991 free data blocks which is less than minimum required 16383 free data blocks. Create more free space in thin pool or use dm.min_free_space option to change behavior</pre>
|
|
</li><li id="cce_faq_00018__li15364101520595">Pod logs: <strong id="cce_faq_00018__b13562719161015">no left space</strong></li></ul>
|
|
</td>
|
|
<td class="cellrowborder" valign="top" width="33.3033303330333%" headers="mcps1.3.2.3.2.4.1.2 "><p id="cce_faq_00018__p53451638101212">The disk space is insufficient.</p>
|
|
</td>
|
|
<td class="cellrowborder" valign="top" width="33.36333633363336%" headers="mcps1.3.2.3.2.4.1.3 "><p id="cce_faq_00018__p996913499397">Expand the disk space or clear unneeded files. For details, see <a href="#cce_faq_00018__section169421237111219">Insufficient Disk Space of the Pod</a>.</p>
|
|
</td>
|
|
</tr>
|
|
<tr id="cce_faq_00018__row289331219916"><td class="cellrowborder" valign="top" width="33.33333333333333%" headers="mcps1.3.2.3.2.4.1.1 "><p id="cce_faq_00018__p1348538171217">Pod logs: <strong id="cce_faq_00018__b9109241344">oom</strong></p>
|
|
</td>
|
|
<td class="cellrowborder" valign="top" width="33.3033303330333%" headers="mcps1.3.2.3.2.4.1.2 "><p id="cce_faq_00018__p1034783831212">The pod memory is insufficient.</p>
|
|
</td>
|
|
<td class="cellrowborder" valign="top" width="33.36333633363336%" headers="mcps1.3.2.3.2.4.1.3 "><p id="cce_faq_00018__p861942224219">Check whether the pod has proper resource settings. For details, see <a href="#cce_faq_00018__section060854916109">Insufficient Container Resources</a>.</p>
|
|
</td>
|
|
</tr>
|
|
<tr id="cce_faq_00018__row1851432918127"><td class="cellrowborder" valign="top" width="33.33333333333333%" headers="mcps1.3.2.3.2.4.1.1 "><p id="cce_faq_00018__p5343438161214">Pod logs: <strong id="cce_faq_00018__b984795810358">Address already in use</strong></p>
|
|
</td>
|
|
<td class="cellrowborder" valign="top" width="33.3033303330333%" headers="mcps1.3.2.3.2.4.1.2 "><p id="cce_faq_00018__p196343331277">A conflict occurs between container ports in the pod.</p>
|
|
</td>
|
|
<td class="cellrowborder" valign="top" width="33.36333633363336%" headers="mcps1.3.2.3.2.4.1.3 "><p id="cce_faq_00018__p162059018434">Check whether there is a container port conflict in the pod. For details, see <a href="#cce_faq_00018__section17679197145618">Container Port Conflict in the Pod</a>.</p>
|
|
</td>
|
|
</tr>
|
|
<tr id="cce_faq_00018__row14457381268"><td class="cellrowborder" valign="top" width="33.33333333333333%" headers="mcps1.3.2.3.2.4.1.1 "><p id="cce_faq_00018__p12467143213187">Kubernetes event:</p>
|
|
<pre class="screen" id="cce_faq_00018__screen20208934135915">Error: failed to start container "filebeat": Error response from daemon: OCI runtime create failed: container_linux.go:330: starting container process caused "process_linux.go:381: container init caused \"setenv: invalid argument\"": unknown</pre>
|
|
</td>
|
|
<td class="cellrowborder" valign="top" width="33.3033303330333%" headers="mcps1.3.2.3.2.4.1.2 "><p id="cce_faq_00018__p14457582265">A secret is mounted to the workload, and the value of the secret is not encrypted using Base64.</p>
|
|
</td>
|
|
<td class="cellrowborder" valign="top" width="33.36333633363336%" headers="mcps1.3.2.3.2.4.1.3 "><p id="cce_faq_00018__p18529141719383">For details about the solution, see <a href="#cce_faq_00018__section12171141792912">Improper Value of the Secret Mounted to the Workload</a>.</p>
|
|
</td>
|
|
</tr>
|
|
<tr id="cce_faq_00018__row16151935181318"><td class="cellrowborder" valign="top" width="33.33333333333333%" headers="mcps1.3.2.3.2.4.1.1 "><p id="cce_faq_00018__p52581156168">Kubernetes event:</p>
|
|
<pre class="screen" id="cce_faq_00018__screen125344311012">the failed container exited with ExitCode: 255</pre>
|
|
</td>
|
|
<td class="cellrowborder" valign="top" width="33.3033303330333%" headers="mcps1.3.2.3.2.4.1.2 "><p id="cce_faq_00018__p029401418205">The x86 container image may run on an Arm node.</p>
|
|
</td>
|
|
<td class="cellrowborder" valign="top" width="33.36333633363336%" headers="mcps1.3.2.3.2.4.1.3 "><p id="cce_faq_00018__p165297170389">For details about the solution, see <a href="#cce_faq_00018__section1141244791317">Unmatched Container Image Tag with the Node Architecture</a>.</p>
|
|
</td>
|
|
</tr>
|
|
<tr id="cce_faq_00018__row10288054171610"><td class="cellrowborder" valign="top" width="33.33333333333333%" headers="mcps1.3.2.3.2.4.1.1 "><p id="cce_faq_00018__p132637550161">Kubernetes event:</p>
|
|
<pre class="screen" id="cce_faq_00018__screen14610361702">the failed container exited with ExitCode: 141</pre>
|
|
</td>
|
|
<td class="cellrowborder" valign="top" width="33.3033303330333%" headers="mcps1.3.2.3.2.4.1.2 "><p id="cce_faq_00018__p18790193131715">The containerd version is incompatible with the tail version.</p>
|
|
</td>
|
|
<td class="cellrowborder" valign="top" width="33.36333633363336%" headers="mcps1.3.2.3.2.4.1.3 "><p id="cce_faq_00018__p9869201545510">For details about the solution, see <a href="#cce_faq_00018__section13939123335611">Exit of tail -f xx in the Container Startup Command (Exit Code: 141)</a>.</p>
|
|
</td>
|
|
</tr>
|
|
<tr id="cce_faq_00018__row37051959205216"><td class="cellrowborder" valign="top" width="33.33333333333333%" headers="mcps1.3.2.3.2.4.1.1 "><p id="cce_faq_00018__p18705859155216">Other pod logs</p>
|
|
</td>
|
|
<td class="cellrowborder" valign="top" width="33.3033303330333%" headers="mcps1.3.2.3.2.4.1.2 "><p id="cce_faq_00018__p67123815544">Locate the fault based on services.</p>
|
|
</td>
|
|
<td class="cellrowborder" valign="top" width="33.36333633363336%" headers="mcps1.3.2.3.2.4.1.3 "><p id="cce_faq_00018__p7248104305217">For details about the fault locating, see <a href="#cce_faq_00018__section16311023103717">Service Setting Checks</a>.</p>
|
|
</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
</div>
|
|
</div>
|
|
<div class="section" id="cce_faq_00018__section2524165018111"><a name="cce_faq_00018__section2524165018111"></a><a name="section2524165018111"></a><h4 class="sectiontitle">No Process in the Pod (Exit Code: 0)</h4><ol id="cce_faq_00018__ol196691215161916"><li id="cce_faq_00018__li1566915154197"><span>Log in to the node where the abnormal workload is located.</span></li><li id="cce_faq_00018__li4848450113620"><span>View the pod status.</span><p><p id="cce_faq_00018__p824162494816">If the node uses Docker, run the following command:</p>
|
|
<pre class="screen" id="cce_faq_00018__screen22442410483"><strong id="cce_faq_00018__b1025192410482">docker </strong><strong id="cce_faq_00018__b725924184818">ps -a | grep </strong><em id="cce_faq_00018__i725202414814">$podName</em></pre>
|
|
<div class="p" id="cce_faq_00018__p152510241483">If the node uses containerd, run the following command:<pre class="screen" id="cce_faq_00018__screen10251424194811"><strong id="cce_faq_00018__b82532464816">crictl <strong id="cce_faq_00018__b15255249489">ps -a | grep </strong></strong><em id="cce_faq_00018__i1825162424811">$podName</em></pre>
|
|
</div>
|
|
<p class="MsoNormal" id="cce_faq_00018__p53989823">Below shows an example.</p>
|
|
<p id="cce_faq_00018__p71071412313"><span><img id="cce_faq_00018__image793141033" src="en-us_image_0000002516077871.png"></span></p>
|
|
<p id="cce_faq_00018__p1840412713395">If there is no process in the pod, the status code <strong id="cce_faq_00018__b7208102204114">Exited (0)</strong> is displayed.</p>
|
|
</p></li></ol>
|
|
</div>
|
|
<div class="section" id="cce_faq_00018__section1766510426482"><a name="cce_faq_00018__section1766510426482"></a><a name="section1766510426482"></a><h4 class="sectiontitle">Health Check Failed (Exit Code: 137)</h4><p id="cce_faq_00018__p10447712763">The health checks configured for a workload are performed on services periodically. If an exception occurs, there will be an event that indicates an unhealthy pod, and the pod restarts will fail.</p>
|
|
<p id="cce_faq_00018__p713825954813">If a liveness probe is configured for the workload and the number of health check failures exceeds the threshold, the pod will be restarted. On the workload details page, if Kubernetes events contain <span class="uicontrol" id="cce_faq_00018__uicontrol07285114478"><b>Liveness probe failed: Get http...</b></span>, the health check fails.</p>
|
|
<p id="cce_faq_00018__p181032054599"><strong id="cce_faq_00018__b103401439768">Solution</strong></p>
|
|
<p id="cce_faq_00018__p172111751896">Click the workload name to go to the workload details page, click the <strong id="cce_faq_00018__b26101221410">Containers</strong> tab. Then select <strong id="cce_faq_00018__b189933189514">Health Check</strong> to check whether the policy is proper or whether services are running properly.</p>
|
|
</div>
|
|
<div class="section" id="cce_faq_00018__section169421237111219"><a name="cce_faq_00018__section169421237111219"></a><a name="section169421237111219"></a><h4 class="sectiontitle">Insufficient Disk Space of the Pod</h4><p id="cce_faq_00018__p11197259141212">The following message refers to the thin pool disk that is allocated from the Docker disk selected during node creation. You can run the <strong id="cce_faq_00018__b12686448183914">lvs</strong> command as user <strong id="cce_faq_00018__b4686114893915">root</strong> to view the current disk usage.</p>
|
|
<pre class="screen" id="cce_faq_00018__screen818622211313">Thin Pool has 15991 free data blocks which is less than minimum required 16383 free data blocks. Create more free space in thin pool or use dm.min_free_space option to change behavior</pre>
|
|
<p id="cce_faq_00018__p1559613521152"><span><img id="cce_faq_00018__image259619529153" src="en-us_image_0000002484117900.png"></span></p>
|
|
<p id="cce_faq_00018__p16726731101520"><strong id="cce_faq_00018__b5897123312191">Solution</strong></p>
|
|
<p id="cce_faq_00018__p1931715017132"><strong id="cce_faq_00018__b11232904548932">Solution 1: Clearing images</strong></p>
|
|
<div class="p" id="cce_faq_00018__p149283331251">Perform the following operations to clear unused images:<ul id="cce_faq_00018__cce_faq_00098_ul921533814520"><li id="cce_faq_00018__cce_faq_00098_li2046965217521">Nodes that use containerd<ol id="cce_faq_00018__cce_faq_00098_ol578417521309"><li id="cce_faq_00018__cce_faq_00098_li1278419521014">Obtain local images on the node.<pre class="screen" id="cce_faq_00018__cce_faq_00098_screen678410524011">crictl images -v</pre>
|
|
</li><li id="cce_faq_00018__cce_faq_00098_li478485214010">Delete the unnecessary images by image ID.<pre class="screen" id="cce_faq_00018__cce_faq_00098_screen2784352202">crictl rmi <em id="cce_faq_00018__cce_faq_00098_i1669994917149">{Image ID}</em></pre>
|
|
</li></ol>
|
|
</li><li id="cce_faq_00018__cce_faq_00098_li1121533815523">Nodes that use Docker<ol id="cce_faq_00018__cce_faq_00098_ol1723885415319"><li id="cce_faq_00018__cce_faq_00098_li0238185415314">Obtain local images on the node.<pre class="screen" id="cce_faq_00018__cce_faq_00098_screen230933054816">docker images</pre>
|
|
</li><li id="cce_faq_00018__cce_faq_00098_li11135715134912">Delete the unnecessary images by image ID.<pre class="screen" id="cce_faq_00018__cce_faq_00098_screen754875916481">docker rmi <em id="cce_faq_00018__cce_faq_00098_i12578102141511">{}Image ID}</em></pre>
|
|
</li></ol>
|
|
</li></ul>
|
|
<div class="note" id="cce_faq_00018__cce_faq_00098_note1327520159174"><img src="public_sys-resources/note_3.0-en-us.png"><span class="notetitle"> </span><div class="notebody"><p id="cce_faq_00018__cce_faq_00098_p927612158179">Do not delete system images such as the <strong id="cce_faq_00018__cce_faq_00098_b892831611545">cce-pause</strong> image. Otherwise, the pod creation may fail.</p>
|
|
</div></div>
|
|
</div>
|
|
<p id="cce_faq_00018__p132271148115716"><strong id="cce_faq_00018__b76820720481840">Solution 2: Expanding the disk capacity</strong></p>
|
|
<p id="cce_faq_00018__p4914182563411">To expand a disk capacity, perform the following operations:</p>
|
|
<ol id="cce_faq_00018__ol11506174116352"><li id="cce_faq_00018__cce_bestpractice_00198_en-us_topic_0196817407_li1091823811013"><span>Expand the capacity of a data disk on the EVS console. </span><p><p id="cce_faq_00018__cce_bestpractice_00198_p1238112673019">Only the storage capacity of EVS disks can be expanded. You need to perform the following operations to expand the capacity of logical volumes and file systems.</p>
|
|
</p></li><li id="cce_faq_00018__cce_bestpractice_00198_li15327184914542"><span>Log in to the CCE console and click the cluster name to access the cluster console. In the navigation pane, choose <strong id="cce_faq_00018__cce_bestpractice_00198_b176491516203817">Nodes</strong>. In the right pane, click the <strong id="cce_faq_00018__cce_bestpractice_00198_b1882661045917">Nodes</strong> tab, locate the row containing the target node, and choose <strong id="cce_faq_00018__cce_bestpractice_00198_b464971673810">More</strong> > <strong id="cce_faq_00018__cce_bestpractice_00198_b9649161615380">Sync Server Data</strong> in the <strong id="cce_faq_00018__cce_bestpractice_00198_b41719133595">Operation</strong> column.</span></li><li id="cce_faq_00018__cce_bestpractice_00198_en-us_topic_0196817407_li209187382011"><span>Log in to the target node.</span></li><li id="cce_faq_00018__cce_bestpractice_00198_li128005014232"><span>Run <strong id="cce_faq_00018__cce_bestpractice_00198_b514633105217">lsblk</strong> to view the block device information of the node.</span><p><p id="cce_faq_00018__cce_bestpractice_00198_p980018092312">A data disk is divided depending on the container storage <strong id="cce_faq_00018__cce_bestpractice_00198_b687813596016">Rootfs</strong>:</p>
|
|
<p id="cce_faq_00018__cce_bestpractice_00198_p495772413155">Overlayfs: No independent thin pool is allocated. Image data is stored in <strong id="cce_faq_00018__cce_bestpractice_00198_b827612111165">dockersys</strong>.</p>
|
|
<ol type="a" id="cce_faq_00018__cce_bestpractice_00198_ol21273913185"><li id="cce_faq_00018__cce_bestpractice_00198_li12123399189">Check the disk and partition space of the device.<pre class="screen" id="cce_faq_00018__cce_bestpractice_00198_screen736044442417"># lsblk
|
|
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
|
|
sda 8:0 0 50G 0 disk
|
|
└─sda1 8:1 0 50G 0 part /
|
|
<strong id="cce_faq_00018__cce_bestpractice_00198_b1294212664615">sdb</strong> 8:16 0 150G 0 disk # The data disk has been expanded to 150 GiB, but 50-GiB space is not allocated.
|
|
├─<strong id="cce_faq_00018__cce_bestpractice_00198_b4744112513594">vgpaas-dockersys </strong>253:0 0 90G 0 lvm /var/lib/containerd
|
|
└─vgpaas-kubernetes 253:1 0 10G 0 lvm /mnt/paas/kubernetes/kubelet</pre>
|
|
</li><li id="cce_faq_00018__cce_bestpractice_00198_li0198144861813">Expand the disk capacity.<p id="cce_faq_00018__cce_bestpractice_00198_p921474831812"><a name="cce_faq_00018__cce_bestpractice_00198_li0198144861813"></a><a name="cce_bestpractice_00198_li0198144861813"></a>Add the new disk capacity to the <strong id="cce_faq_00018__cce_bestpractice_00198_b847894461815">dockersys</strong> logical volume used by the container engine.</p>
|
|
<ol class="substepthirdol" id="cce_faq_00018__cce_bestpractice_00198_ol152151348151813"><li id="cce_faq_00018__cce_bestpractice_00198_li7215184812181">Expand the PV capacity so that LVM can identify the new EVS capacity. <i><span class="varname" id="cce_faq_00018__cce_bestpractice_00198_varname521434871810">/dev/sdb</span></i> specifies the physical volume where dockersys is located.<pre class="screen" id="cce_faq_00018__cce_bestpractice_00198_screen11214148161819">pvresize <i><span class="varname" id="cce_faq_00018__cce_bestpractice_00198_varname521424813184">/dev/sdb</span></i></pre>
|
|
<p id="cce_faq_00018__cce_bestpractice_00198_p1421410488182">Information similar to the following is displayed:</p>
|
|
<pre class="screen" id="cce_faq_00018__cce_bestpractice_00198_screen12158489188">Physical volume "/dev/sdb" changed
|
|
1 physical volume(s) resized or updated / 0 physical volume(s) not resized</pre>
|
|
</li><li id="cce_faq_00018__cce_bestpractice_00198_li192151048121812">Expand 100% of the free capacity to the logical volume. <i><span class="varname" id="cce_faq_00018__cce_bestpractice_00198_varname755105312213">vgpaas/dockersys</span></i> specifies the logical volume used by the container engine.<pre class="screen" id="cce_faq_00018__cce_bestpractice_00198_screen16215248191818">lvextend -l+100%FREE -n <i><span class="varname" id="cce_faq_00018__cce_bestpractice_00198_varname121524816189">vgpaas/dockersys</span></i></pre>
|
|
<p id="cce_faq_00018__cce_bestpractice_00198_p18215134851812">Information similar to the following is displayed:</p>
|
|
<pre class="screen" id="cce_faq_00018__cce_bestpractice_00198_screen18215114815187">Size of logical volume vgpaas/dockersys changed from <90.00 GiB (23039 extents) to 140.00 GiB (35840 extents).
|
|
Logical volume vgpaas/dockersys successfully resized.</pre>
|
|
</li><li id="cce_faq_00018__cce_bestpractice_00198_li152151548131813">Adjust the size of the file system. <i><span class="varname" id="cce_faq_00018__cce_bestpractice_00198_varname154401456123919">/dev/vgpaas/dockersys</span></i> specifies the file system path of the container engine.<pre class="screen" id="cce_faq_00018__cce_bestpractice_00198_screen42158483188">resize2fs <i><span class="varname" id="cce_faq_00018__cce_bestpractice_00198_varname1121564851810">/dev/vgpaas/dockersys</span></i></pre>
|
|
<p id="cce_faq_00018__cce_bestpractice_00198_p12152487182">Information similar to the following is displayed:</p>
|
|
<pre class="screen" id="cce_faq_00018__cce_bestpractice_00198_screen9215174821814">Filesystem at /dev/vgpaas/dockersys is mounted on /var/lib/containerd; on-line resizing required
|
|
old_desc_blocks = 12, new_desc_blocks = 18
|
|
The filesystem on /dev/vgpaas/dockersys is now 36700160 blocks long.</pre>
|
|
</li></ol>
|
|
</li><li id="cce_faq_00018__cce_bestpractice_00198_li8293175643314">Check whether the capacity has been expanded.<pre class="screen" id="cce_faq_00018__cce_bestpractice_00198_screen1415443012394"># lsblk
|
|
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
|
|
sda 8:0 0 50G 0 disk
|
|
└─sda1 8:1 0 50G 0 part /
|
|
<strong id="cce_faq_00018__cce_bestpractice_00198_b1515463012396">sdb</strong> 8:16 0 150G 0 disk
|
|
├─<strong id="cce_faq_00018__cce_bestpractice_00198_b10154133011394">vgpaas-dockersys </strong>253:0 0 140G 0 lvm /var/lib/containerd
|
|
└─vgpaas-kubernetes 253:1 0 10G 0 lvm /mnt/paas/kubernetes/kubelet</pre>
|
|
</li></ol>
|
|
<div class="dropdownexpand"><div class="dropdowntitle" onclick="ExpandorCollapseNode(this)"><p id="cce_faq_00018__cce_bestpractice_00198_p11864720131616">Device Mapper: A thin pool is allocated to store image data.</p></div>
|
|
<div class="dropdowncontext"><ol type="a" id="cce_faq_00018__cce_bestpractice_00198_ol19673033191613"><li id="cce_faq_00018__cce_bestpractice_00198_li2673163381620">Check the disk and partition space of the device.<pre class="screen" id="cce_faq_00018__cce_bestpractice_00198_screen10480142251"># lsblk
|
|
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
|
|
vda 8:0 0 50G 0 disk
|
|
└─vda1 8:1 0 50G 0 part /
|
|
<strong id="cce_faq_00018__cce_bestpractice_00198_b9505458151516">vdb</strong> 8:16 0 200G 0 disk
|
|
├─<strong id="cce_faq_00018__cce_bestpractice_00198_b170511380163">vgpaas-dockersys</strong> 253:0 0 18G 0 lvm /var/lib/docker
|
|
├─vgpaas-thinpool_tmeta 253:1 0 3G 0 lvm
|
|
│ └─<strong id="cce_faq_00018__cce_bestpractice_00198_b10865144019161">vgpaas-thinpool</strong> 253:3 0 67G 0 lvm # Space used by thin pool
|
|
│ ...
|
|
├─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</pre>
|
|
</li><li id="cce_faq_00018__cce_bestpractice_00198_li070319311712">Expand the disk capacity.<div class="dropdownexpand"><div class="dropdowntitle" onclick="ExpandorCollapseNode(this)"><p id="cce_faq_00018__cce_bestpractice_00198_p18707103101714"><a name="cce_faq_00018__cce_bestpractice_00198_li070319311712"></a><a name="cce_bestpractice_00198_li070319311712"></a>Option 1: Add the new disk capacity to the thin pool.</p></div>
|
|
<div class="dropdowncontext"><ol class="substepthirdol" id="cce_faq_00018__cce_bestpractice_00198_ol14479322175313"><li id="cce_faq_00018__cce_bestpractice_00198_li3226162555316">Expand the PV capacity so that LVM can identify the new EVS capacity. <i><span class="varname" id="cce_faq_00018__cce_bestpractice_00198_varname122261825125313">/dev/vdb</span></i> specifies the physical volume where thin pool is located.<pre class="screen" id="cce_faq_00018__cce_bestpractice_00198_screen322642545310">pvresize <i><span class="varname" id="cce_faq_00018__cce_bestpractice_00198_varname32261225115313">/dev/vdb</span></i></pre>
|
|
<p id="cce_faq_00018__cce_bestpractice_00198_p4226112575311">Information similar to the following is displayed:</p>
|
|
<pre class="screen" id="cce_faq_00018__cce_bestpractice_00198_screen22268251531">Physical volume "/dev/vdb" changed
|
|
1 physical volume(s) resized or updated / 0 physical volume(s) not resized</pre>
|
|
</li><li id="cce_faq_00018__cce_bestpractice_00198_li82268253531">Expand 100% of the free capacity to the logical volume. <i><span class="varname" id="cce_faq_00018__cce_bestpractice_00198_varname82264252537">vgpaas/thinpool</span></i> specifies the logical volume used by the container engine.<pre class="screen" id="cce_faq_00018__cce_bestpractice_00198_screen1226125205315">lvextend -l+100%FREE -n <i><span class="varname" id="cce_faq_00018__cce_bestpractice_00198_varname11227152555311">vgpaas/thinpool</span></i></pre>
|
|
<p id="cce_faq_00018__cce_bestpractice_00198_p1322782520532">Information similar to the following is displayed:</p>
|
|
<pre class="screen" id="cce_faq_00018__cce_bestpractice_00198_screen02271259538">Size of logical volume vgpaas/thinpool changed from <67.00 GiB (23039 extents) to <167.00 GiB (48639 extents).
|
|
Logical volume vgpaas/thinpool successfully resized.</pre>
|
|
</li><li id="cce_faq_00018__cce_bestpractice_00198_li2035313285578">Do not need to adjust the size of the file system because the thin pool is not mounted to any devices.</li><li id="cce_faq_00018__cce_bestpractice_00198_li4316185812127">Run the <strong id="cce_faq_00018__cce_bestpractice_00198_b131341430125818">lsblk</strong> command to check the disk and partition space of the device and check whether the capacity has been expanded. If the new disk capacity was added to the thin pool, the capacity has been expanded.<pre class="screen" id="cce_faq_00018__cce_bestpractice_00198_screen14868124917201"># lsblk
|
|
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
|
|
vda 8:0 0 50G 0 disk
|
|
└─vda1 8:1 0 50G 0 part /
|
|
<strong id="cce_faq_00018__cce_bestpractice_00198_b155275918212">vdb</strong> 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
|
|
│ └─<strong id="cce_faq_00018__cce_bestpractice_00198_b65275916211">vgpaas-thinpool</strong> 253:3 0 167G 0 lvm # Thin pool space after capacity expansion
|
|
│ ...
|
|
├─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</pre>
|
|
</li></ol></div></div>
|
|
<p id="cce_faq_00018__cce_bestpractice_00198_p13400163612587">Option 2: Add the new disk capacity to the <strong id="cce_faq_00018__cce_bestpractice_00198_b13698105071916">dockersys</strong> disk.</p>
|
|
<ol class="substepthirdol" id="cce_faq_00018__cce_bestpractice_00198_ol73461016175512"><li id="cce_faq_00018__cce_bestpractice_00198_li8346151617552">Expand the PV capacity so that LVM can identify the new EVS capacity. <i><span class="varname" id="cce_faq_00018__cce_bestpractice_00198_varname757010455113">/dev/vdb</span></i> specifies the physical volume where dockersys is located.<pre class="screen" id="cce_faq_00018__cce_bestpractice_00198_screen12346151655517">pvresize <i><span class="varname" id="cce_faq_00018__cce_bestpractice_00198_varname1234617167553">/dev/vdb</span></i></pre>
|
|
<p id="cce_faq_00018__cce_bestpractice_00198_p1834621665517">Information similar to the following is displayed:</p>
|
|
<pre class="screen" id="cce_faq_00018__cce_bestpractice_00198_screen3346131613558">Physical volume "/dev/vdb" changed
|
|
1 physical volume(s) resized or updated / 0 physical volume(s) not resized</pre>
|
|
</li><li id="cce_faq_00018__cce_bestpractice_00198_li334601655510">Expand 100% of the free capacity to the logical volume. <i><span class="varname" id="cce_faq_00018__cce_bestpractice_00198_varname14541643627">vgpaas/dockersys</span></i> specifies the logical volume used by the container engine.<pre class="screen" id="cce_faq_00018__cce_bestpractice_00198_screen1734615168554">lvextend -l+100%FREE -n <i><span class="varname" id="cce_faq_00018__cce_bestpractice_00198_varname5346716145518">vgpaas/dockersys</span></i></pre>
|
|
<p id="cce_faq_00018__cce_bestpractice_00198_p163477161557">Information similar to the following is displayed:</p>
|
|
<pre class="screen" id="cce_faq_00018__cce_bestpractice_00198_screen834714168555">Size of logical volume vgpaas/dockersys changed from <18.00 GiB (4607 extents) to <118.00 GiB (30208 extents).
|
|
Logical volume vgpaas/dockersys successfully resized.</pre>
|
|
</li><li id="cce_faq_00018__cce_bestpractice_00198_li0347131616553">Adjust the size of the file system. <i><span class="varname" id="cce_faq_00018__cce_bestpractice_00198_varname58031041037">/dev/vgpaas/dockersys</span></i> specifies the file system path of the container engine.<pre class="screen" id="cce_faq_00018__cce_bestpractice_00198_screen8347016105513">resize2fs <i><span class="varname" id="cce_faq_00018__cce_bestpractice_00198_varname434711167551">/dev/vgpaas/dockersys</span></i></pre>
|
|
<p id="cce_faq_00018__cce_bestpractice_00198_p1534718161555">Information similar to the following is displayed:</p>
|
|
<pre class="screen" id="cce_faq_00018__cce_bestpractice_00198_screen1434771615553">Filesystem at /dev/vgpaas/dockersys is mounted on /var/lib/docker; on-line resizing required
|
|
old_desc_blocks = 3, new_desc_blocks = 15
|
|
The filesystem on /dev/vgpaas/dockersys is now 30932992 blocks long.</pre>
|
|
</li><li id="cce_faq_00018__cce_bestpractice_00198_li1255142817436">Run the <strong id="cce_faq_00018__cce_bestpractice_00198_b14275163417210">lsblk</strong> command to check the disk and partition space of the device and check whether the capacity has been expanded. If the new disk capacity was added to the dockersys, the capacity has been expanded.<pre class="screen" id="cce_faq_00018__cce_bestpractice_00198_screen1855182812432"># lsblk
|
|
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
|
|
vda 8:0 0 50G 0 disk
|
|
└─vda1 8:1 0 50G 0 part /
|
|
<strong id="cce_faq_00018__cce_bestpractice_00198_b65524285434">vdb</strong> 8:16 0 200G 0 disk
|
|
├─<strong id="cce_faq_00018__cce_bestpractice_00198_b164571384414">vgpaas-dockersys</strong> 253:0 0 118G 0 lvm /var/lib/docker # dockersys after capacity expansion
|
|
├─vgpaas-thinpool_tmeta 253:1 0 3G 0 lvm
|
|
│ └─vgpaas-thinpool 253:3 0 67G 0 lvm
|
|
│ ...
|
|
├─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</pre>
|
|
</li></ol>
|
|
</li></ol></div></div>
|
|
</p></li></ol>
|
|
</div>
|
|
<div class="section" id="cce_faq_00018__section060854916109"><a name="cce_faq_00018__section060854916109"></a><a name="section060854916109"></a><h4 class="sectiontitle">Insufficient Container Resources</h4><p id="cce_faq_00018__p266081371117">If the upper limit of container resources has been reached, OOM will be displayed in the event details as well as in the log:</p>
|
|
<pre class="screen" id="cce_faq_00018__screen124684181118">cat /var/log/messages | grep 96feb0a425d6 | grep oom</pre>
|
|
<p id="cce_faq_00018__p19781310151216"><span><img id="cce_faq_00018__image16977210101210" src="en-us_image_0000002516197853.png"></span></p>
|
|
<p id="cce_faq_00018__p127161501123">When a workload is created, if the requested resources exceed the configured upper limit, the system OOM is triggered and the container exits unexpectedly.</p>
|
|
</div>
|
|
<div class="section" id="cce_faq_00018__section17679197145618"><a name="cce_faq_00018__section17679197145618"></a><a name="section17679197145618"></a><h4 class="sectiontitle">Container Port Conflict in the Pod</h4><ol id="cce_faq_00018__ol14929324131"><li id="cce_faq_00018__li1992173217134"><span>Log in to the node where the abnormal workload is located.</span></li><li id="cce_faq_00018__li1593133241318"><span>Check the ID of the container where the workload pod exits abnormally.</span><p><p id="cce_faq_00018__p1357611413498">If the node uses Docker, run the following command:</p>
|
|
<pre class="screen" id="cce_faq_00018__screen1657604154913"><strong id="cce_faq_00018__b1557616420490">docker </strong><strong id="cce_faq_00018__b557615414911">ps -a | grep </strong><em id="cce_faq_00018__i12576184114915">$podName</em></pre>
|
|
<div class="p" id="cce_faq_00018__p115761248495">If the node uses containerd, run the following command:<pre class="screen" id="cce_faq_00018__screen1657624174916"><strong id="cce_faq_00018__b45768414497">crictl <strong id="cce_faq_00018__b1057618414920">ps -a | grep </strong></strong><em id="cce_faq_00018__i1657617484918">$podName</em></pre>
|
|
</div>
|
|
</p></li><li id="cce_faq_00018__li159417328133"><span>View the container logs.</span><p><p id="cce_faq_00018__p162381745114918">If the node uses Docker, run the following command:</p>
|
|
<pre class="screen" id="cce_faq_00018__screen1823815457493"><strong id="cce_faq_00018__b182391845124911">docker </strong><strong id="cce_faq_00018__b22399455498">logs </strong><em id="cce_faq_00018__i14239144574914">$containerID</em></pre>
|
|
<div class="p" id="cce_faq_00018__p223934513498">If the node uses containerd, run the following command:<pre class="screen" id="cce_faq_00018__screen18239124564919"><strong id="cce_faq_00018__b52391945194917">crictl logs </strong><em id="cce_faq_00018__i132395459498">$containerID</em></pre>
|
|
</div>
|
|
<p id="cce_faq_00018__p15953327133">Rectify the fault of the workload based on logs. As shown in the following figure, container ports in the same pod conflict. As a result, the container fails to be started.</p>
|
|
<div class="fignone" id="cce_faq_00018__fig15903038171615"><span class="figcap"><b>Figure 1 </b>Pod restart failure due to a container port conflict</span><br><span><img id="cce_faq_00018__image13994266" src="en-us_image_0000002516197861.png"></span></div>
|
|
</p></li></ol>
|
|
<p id="cce_faq_00018__p191112304720"><strong id="cce_faq_00018__b209005717513">Solution</strong></p>
|
|
<p id="cce_faq_00018__p1023371615160">Configure proper container ports that do not conflict with each other. Then, create the workload again.</p>
|
|
<p id="cce_faq_00018__p105602844519">If a pod uses the host network (with <strong id="cce_faq_00018__b12904124813457">hostNetwork: true</strong> configured), there may be a container port conflict. This is because containers in the pod share the network interface and port range with the host node. Multiple pods using the same port cannot run on the same node.</p>
|
|
</div>
|
|
<div class="section" id="cce_faq_00018__section12171141792912"><a name="cce_faq_00018__section12171141792912"></a><a name="section12171141792912"></a><h4 class="sectiontitle">Improper Value of the Secret Mounted to the Workload</h4><p id="cce_faq_00018__p1052411541303">Information similar to the following is displayed in the event:</p>
|
|
<pre class="screen" id="cce_faq_00018__screen6524105413015">Error: failed to start container "filebeat": Error response from daemon: OCI runtime create failed: container_linux.go:330: starting container process caused "process_linux.go:381: container init caused \"setenv: invalid argument\"": unknown</pre>
|
|
<p id="cce_faq_00018__p189253111326">The root cause is that a secret is mounted to the workload, but the value of the secret is not encrypted using Base64.</p>
|
|
<p id="cce_faq_00018__p16382125914320"><strong id="cce_faq_00018__b16204501794356">Solution</strong></p>
|
|
<p id="cce_faq_00018__p1038285910322">Create a secret on the console. The value of the secret is automatically encrypted using Base64.</p>
|
|
<p id="cce_faq_00018__p107211855183319">If you use YAML to create a secret, you need to manually encrypt its value using Base64.</p>
|
|
<pre class="screen" id="cce_faq_00018__screen16843135233418">echo -n <em id="cce_faq_00018__i58112261160">"Content to be encoded"</em> | base64</pre>
|
|
</div>
|
|
<div class="section" id="cce_faq_00018__section1141244791317"><a name="cce_faq_00018__section1141244791317"></a><a name="section1141244791317"></a><h4 class="sectiontitle">Unmatched Container Image Tag with the Node Architecture</h4><p id="cce_faq_00018__p25604291417">The proper image tag is not used during the workload creation on an Arm node. To resolve this issue, use the proper image tag.</p>
|
|
</div>
|
|
<div class="section" id="cce_faq_00018__section13939123335611"><a name="cce_faq_00018__section13939123335611"></a><a name="section13939123335611"></a><h4 class="sectiontitle">Exit of <strong id="cce_faq_00018__b157041529111720">tail -f</strong> <em id="cce_faq_00018__i1689418317179">xx</em> in the Container Startup Command (Exit Code: 141)</h4><p id="cce_faq_00018__p10940123318560">The Kubernetes event is as follows:</p>
|
|
<pre class="screen" id="cce_faq_00018__screen7940103320567">the failed container exited with ExitCode: 141</pre>
|
|
<p id="cce_faq_00018__p6940633115619"><strong id="cce_faq_00018__b9690142112313">Possible Cause</strong></p>
|
|
<p id="cce_faq_00018__p9940123310567">The legacy version of containerd is incompatible with the tail version (≥ 8.28) in the container image. As a result, executing the <strong id="cce_faq_00018__b6391349131913">tail -f</strong> command leads to an unexpected exit, returning exit code 141.</p>
|
|
<p id="cce_faq_00018__p094017332563"><strong id="cce_faq_00018__b156873532238">Temporary Workaround</strong></p>
|
|
<p id="cce_faq_00018__p3940233165613">Change <strong id="cce_faq_00018__b12787194617241">tail -f</strong> <em id="cce_faq_00018__i982714816241">xx</em> in the startup parameters to <strong id="cce_faq_00018__b108271754112410">sleep 2 && tail -f</strong> <em id="cce_faq_00018__i8288185710242">xx</em> and create a workload again.</p>
|
|
<p id="cce_faq_00018__p59401533205610"><strong id="cce_faq_00018__b65735010233">Solution</strong></p>
|
|
<ul id="cce_faq_00018__ul59401933165616"><li id="cce_faq_00018__li12940733185610">Upgrade the cluster to v1.25.16-r20, v1.27.16-r20, v1.28.15-r10, v1.29.10-r10, v1.30.6-r10, v1.31.4-r0, or later.</li><li id="cce_faq_00018__li2940033145616">Reset the node and use the Docker container engine instead.</li></ul>
|
|
</div>
|
|
<div class="section" id="cce_faq_00018__section16311023103717"><a name="cce_faq_00018__section16311023103717"></a><a name="section16311023103717"></a><h4 class="sectiontitle">Service Setting Checks</h4><p id="cce_faq_00018__p13792655144012">Check whether the workload startup command is correctly executed or whether the workload has a bug.</p>
|
|
<ol id="cce_faq_00018__ol747141124213"><li id="cce_faq_00018__li10471411423"><span>Log in to the node where the abnormal workload is located.</span></li><li id="cce_faq_00018__li64717116421"><span>Check the ID of the container where the workload pod exits abnormally.</span><p><p id="cce_faq_00018__p4203518134912">If the node uses Docker, run the following command:</p>
|
|
<pre class="screen" id="cce_faq_00018__screen92034185492"><strong id="cce_faq_00018__b14203518144914">docker </strong><strong id="cce_faq_00018__b1920381884911">ps -a | grep </strong><em id="cce_faq_00018__i1320317186499">$podName</em></pre>
|
|
<div class="p" id="cce_faq_00018__p520321812495">If the node uses containerd, run the following command:<pre class="screen" id="cce_faq_00018__screen920361844915"><strong id="cce_faq_00018__b15203121819499">crictl <strong id="cce_faq_00018__b8203191813492">ps -a | grep </strong></strong><em id="cce_faq_00018__i17203191811498">$podName</em></pre>
|
|
</div>
|
|
</p></li><li id="cce_faq_00018__li1486155164417"><span>View the container logs.</span><p><p id="cce_faq_00018__p569932615412">If the node uses Docker, run the following command:</p>
|
|
<pre class="screen" id="cce_faq_00018__screen16699122612417"><strong id="cce_faq_00018__b46992266414">docker </strong><strong id="cce_faq_00018__b9699132674110">logs </strong><em id="cce_faq_00018__i17699192610412">$containerID</em></pre>
|
|
<div class="p" id="cce_faq_00018__p669982674112">If the node uses containerd, run the following command:<pre class="screen" id="cce_faq_00018__screen1169962612410"><strong id="cce_faq_00018__b13385431204110">crictl logs </strong><em id="cce_faq_00018__i63861731184119">$containerID</em></pre>
|
|
</div>
|
|
<p id="cce_faq_00018__p1942211612810">Note: In the preceding command, <em id="cce_faq_00018__i16395152510278">containerID</em> indicates the ID of the container that has exited.</p>
|
|
<div class="fignone" id="cce_faq_00018__fig13787193210479"><span class="figcap"><b>Figure 2 </b>Incorrect startup command of the container</span><br><span><img id="cce_faq_00018__image11788133224716" src="en-us_image_0000002516077859.png"></span></div>
|
|
<p id="cce_faq_00018__p03417581816">As shown in the figure above, the container fails to be started due to an incorrect startup command. For other errors, rectify the bugs based on the logs.</p>
|
|
</p></li></ol>
|
|
<p id="cce_faq_00018__p4365191819531"><strong id="cce_faq_00018__b1252013242346">Solution</strong></p>
|
|
<p id="cce_faq_00018__p19981814105311">Create a new workload and configure a correct startup command.</p>
|
|
</div>
|
|
</div>
|
|
<div>
|
|
<div class="familylinks">
|
|
<div class="parentlink"><strong>Parent topic:</strong> <a href="cce_faq_00029.html">Workload Exception Troubleshooting</a></div>
|
|
</div>
|
|
</div>
|
|
|