# Welcome to the Azure Kubernetes Service enabled by Azure Arc (AKS Arc) repo This is where the AKS Arc team will track features and issues with AKS Arc. We will monitor this repo in order to engage with our community and discuss questions, customer scenarios, or feature requests. Checkout our projects tab to see the roadmap for AKS Arc!
MIT License
111
stars
45
forks
source link
[BUG] Target cluster pod logs are not accessible - remote error: tls: internal error #237
Describe the bug
Target cluster logs not accessible. When we try to access pod logs in target cluster we hit the tls error
Error from server: Get "[https://10.0.0.0:10250/containerLogs/kube-system/kube-apiserver-moc-l9iv8xjn3av/kube-apiserver":](https://10.0.0.0:10250/containerLogs/kube-system/kube-apiserver-moc-l9iv8xjn3av/kube-apiserver%22:) remote error: tls: internal error
To Reproduce
Steps to reproduce the behavior:
Install AksHci
Install target cluster
Dont upgrade cluster for 60 days
Restart the cluster
Expected behavior
The target pod logs should not be accessible . Any kubectl log command run against target cluster should return with an error message similar to this
Error from server: Get "[https://10.0.0.0:10250/containerLogs/kube-system/kube-apiserver-moc-l9iv8xjn3av/kube-apiserver":](https://10.0.0.0:10250/containerLogs/kube-system/kube-apiserver-moc-l9iv8xjn3av/kube-apiserver%22:) remote error: tls: internal error
Solution
Run the following command to renew the certificate manager tokens
Note
There is a known bug in AksHci version before 1.0.14.x. It should be fixed as part of 1.0.14.x. Target clusters updated to this version should not hit this issue anymore.
Describe the bug Target cluster logs not accessible. When we try to access pod logs in target cluster we hit the tls error
To Reproduce Steps to reproduce the behavior:
Expected behavior The target pod logs should not be accessible . Any kubectl log command run against target cluster should return with an error message similar to this
Solution
Note There is a known bug in AksHci version before 1.0.14.x. It should be fixed as part of 1.0.14.x. Target clusters updated to this version should not hit this issue anymore.