When you update a ConfigMap in Kubernetes, any pods that use the ConfigMap will not be automatically restarted. However, you can force a pod to restart by deleting it and letting Kubernetes create a new pod with the updated ConfigMap.
To do this, follow these steps:
- Find the name of the pod that is using the ConfigMap:
kubectl describe <pod-name> - Delete the pod:
kubectl delete pod <pod-name> - Verify that a new pod has been created with the updated ConfigMap:
kubectl get pods
Alternatively, you can use rolling updates to update your pods gradually without downtime. This involves updating your deployment or statefulset configuration to use the updated ConfigMap and then triggering a rolling update using kubectl rollout. This will gradually replace old pods with new ones using the updated configuration.
![/data # iw --debug dev wlan0 connect -w lucky-5g auth open key 0:1234567890
Usage: iw [options] dev connect [-w] [] [] [auth open|shared] [key 0:abcde d:1:6162636465] [mfp:req/opt/no]
Join the network with th...](https://linuxcpp.0voice.com/zb_users/upload/2023/05/202305162224509509129.png)
![/data # iw --debug dev wlan0 connect -w "lucky-5g" auth open key 0:1234567890
Usage: iw [options] dev connect [-w] [] [] [auth open|shared] [key 0:abcde d:1:6162636465] [mfp:req/opt/no]
Join the network with ...](https://linuxcpp.0voice.com/zb_users/upload/2023/05/202305162239148267954.png)
![驱动代码
void kalRxTaskletSchedule(struct GLUE_INFO *pr)
{
static unsigned int num = 0;
tasklet_hi_schedule(&pr->rRxTask[(num++)%NR_CPUS]);
// tasklet_hi_schedule(&pr->rRxTask);
DBGLOG(HAL, ERROR,](https://linuxcpp.0voice.com/zb_users/upload/2023/05/202305162226144313964.png)
