折腾了好久，执行

/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

开始一直报错Failed to connect to raw.githubusercontent.com port 443: Connection refused error: Error: 7，

尝试过改动git config的代理，没有用，

换中科大的源，也没有用

最后解决办法如下。

方法一：

参考 https://blog.csdn.net/m0_37136046/article/details/106425286

sudo vi /etc/hosts

在host中加入以下

199.232.28.133 raw.githubusercontent.com

再重新执行


  /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install.sh)"

 

方法2：

重装command line tools，再执行安装指令，homebrew安装成功。

 

removing the old tools
	
rm -rf /Library/Developer/CommandLineTools
	
	
install xcode command line tools again 
	
xcode-select --install

	
 
	
	
执行
	
/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

	
 
	

1. nodePort
nodePort提供了集群外部客户端访问service的一种方式，:nodePort提供了集群外部客户端访问service的端口，即nodeIP:nodePort提供了外部流量访问k8s集群中service的入口。
比如外部用户要访问k8s集群中的一个Web应用，那么我们可以配置对应service的type=NodePort，nodePort=30001。其他用户就可以通过浏览器http://node:30001访问到该web服务。
而数据库等服务可能不需要被外界访问，只需被内部服务访问即可，那么我们就不必设置service的NodePort。

2. port
port是暴露在cluster ip上的端口，:port提供了集群内部客户端访问service的入口，即clusterIP:port。
mysql容器暴露了3306端口（参考DockerFile），集群内其他容器通过33306端口访问mysql服务，但是外部流量不能访问mysql服务，因为mysql服务没有配置NodePort。对应的service.yaml如下：
apiVersion: v1
kind: Service
metadata:
  name: mysql-service
spec:
  ports:
  - port: 33306
    targetPort: 3306
  selector:
    name: mysql-pod


3. targetPort
targetPort是pod上的端口，从port/nodePort上来的数据，经过kube-proxy流入到后端pod的targetPort上，最后进入容器。
与制作容器时暴露的端口一致（使用DockerFile中的EXPOSE），例如官方的nginx（参考DockerFile）暴露80端口。 对应的service.yaml如下：
apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  type: NodePort            // 配置NodePort，外部流量可访问k8s中的服务
  ports:
  - port: 30080             // 服务访问端口
    targetPort: 80          // pod控制器中定义的端口
    nodePort: 30001         // NodePort
  selector:
    name: nginx-pod


4. containerPort
containerPort是在pod控制器中定义的、pod中的容器需要暴露的端口。

5. 总结
总的来说，port和nodePort都是service的端口，前者暴露给k8s集群内部服务访问，后者暴露给k8s集群外部流量访问。从这两个端口到来的数据都需要经过反向代理kube-proxy，流入后端pod的targetPort上，最后到达pod内容器的containerPort。

6. 参考文章
Kubernetes中的nodePort，targetPort，port的区别和意义
kubernetes中port、target port、node port的对比分析，以及kube-proxy代理

解决git下载出现：Failed to connect to 127.0.0.1 port 1080: Connection refused拒绝连接错误

文章目录：
一、git拒绝连接原因分析
二、错误解决方式
1、查看Linux当前有没有使用代理
2、查看端口有没有被占用
2、取消代理设置
linux解决端口号被占用（扩展内容）


不知道是不是翻墙导致的错误，昨天同事说服务器出现了这个错误，然后说服务器坏啦什么哒，因为是我重启啦，所以就感觉好像在一顿帅锅，哎！！！ 然后我上去搞了一下一会搞定啦！无能者只剩下了愤怒！！！

一、git拒绝连接原因分析
使用git从远程仓库下载代码出现上述的错误是因为使用了proxy代理，所以要解决该问题，核心操作就是要取消代理
二、错误解决方式
1、查看Linux当前有没有使用代理

方式一：通过git的配置文件查看有无使用代理（没有成功）

查询是否使用代理：git config --global http.proxy 


注： 我在使用该方法并没有返回任何信息，也没有返回代理使用，当然啦，你可以尝试，毕竟好多人都是用这种方法查看的。还有，你可以试试git config --global --unset https.proxy  在http协议后面加s试一下


方式二：通过查询系统环境有没有使用代理（成功）

env|grep -I proxy

我是用这个命令查询出有在使用代理的，返回信息如下：



从上面可以看出，有很多协议占用了这个端口，有http、ftp、all、socks、https、no
2、查看端口有没有被占用
2、取消代理设置

方式一：通过git取消代理设置

$ git config --global --unset http.proxy
$ git config --global --unset https.proxy

（我尝试了该方法，并没有取消代理，代理依然存在，当然啦，你可以尝试一下）
2、方式二：
 export http_proxy=""
 export https_proxy=""
 export HTTP_PROXY=""
 export HTTPS_PROXY=""

(我尝试了该方法，并没有取消代理，代理依然存在，当然啦，你可以尝试一下）

方式二：通过系统命令取消代理

$ unset http_proxy
$ unset ftp_proxy
$ unset all_proxy
$ unset https_proxy
$ unset no_proxy

把上面出现的所有使用代理的协议，全部都取消掉，然后问题成功解决
 到此为止问题已经完全解决，下面内容为扩展内容

Reference:

1、https://www.jianshu.com/p/d6730c16a4c9

2、http://www.voidcn.com/article/p-vzlydxyu-bsa.html

3、https://blog.csdn.net/xunan003/article/details/79233147
linux解决端口号被占用（扩展内容）

查看端口有没有被占用

lsof -i:1080

显示结果：



2、查看指定端口的使用情况
netstat -tln | grep 1080

显示结果：



3、 显示系统端口使用情况
netstat -anp



查看进程号对用的可执行程序

ps -f -p 进程号



终止进程号（被占用的端口）

kill -9 进程号

例如：
kill -9 8379

Netstat 命令用于显示各种网络相关信息，如网络连接，路由表，接口状态 (Interface Statistics)，masquerade 连接，多播成员 (Multicast Memberships) 等等。
-a (all)显示所有选项，默认不显示LISTEN相关

-t (tcp)仅显示tcp相关选项

-u (udp)仅显示udp相关选项

-n 拒绝显示别名，能显示数字的全部转化成数字。

-l 仅列出有在 Listen (监听) 的服務状态
-p 显示建立相关链接的程序名

-r 显示路由信息，路由表

-e 显示扩展信息，例如uid等

-s 按各个协议进行统计

-c 每隔一个固定时间，执行该netstat命令。
提示：LISTEN和LISTENING的状态只有用-a或者-l才能看到






♠ ⊕ ♠ ⊕  ♠ ⊕ ♠ ⊕ ♠ ⊕  ♠ ⊕ ♠ ⊕ ♠ ⊕  ♠ ⊕ ♠ ⊕ ♠ ⊕  ♠ ⊕ ♠ ⊕ ♠ ⊕  ♠ ⊕ ♠ ⊕ ♠ ⊕  ♠ ⊕ ♠ ⊕ ♠ ⊕  ♠ ⊕ ♠ ⊕ ♠ ⊕  ♠ ⊕ ♠ ⊕ ♠ ⊕  ♠ ⊕ ♠ ⊕ ♠ ⊕  ♠ ⊕ ♠

1. nodePort
外部流量访问k8s集群中service入口的一种方式（另一种方式是LoadBalancer），即nodeIP:nodePort是提供给外部流量访问k8s集群中service的入口。比如外部用户要访问k8s集群中的一个Web应用，那么我们可以配置对应service的type=NodePort，nodePort=30001。其他用户就可以通过浏览器http://node:30001访问到该web服务。而数据库等服务可能不需要被外界访问，只需被内部服务访问即可，那么我们就不必设置service的NodePort。
[zhangweijian@master k8s]$ kubectl describe svc nginx-service-nodeport  -n testzhang
Name:                     nginx-service-nodeport
Namespace:                testzhang
Labels:                   <none>
Annotations:              <none>
Selector:                 name=nginx
Type:                     NodePort
IP:                       10.1.194.115
Port:                     <unset>  8000/TCP
TargetPort:               80/TCP
NodePort:                 <unset>  31143/TCP
Endpoints:                10.244.1.174:80,10.244.2.88:80
Session Affinity:         None
External Traffic Policy:  Cluster
Events:                   <none>


2.Port
k8s集群内部服务之间访问service的入口。即clusterIP:port是service暴露在clusterIP上的端口。mysql容器暴露了3306端口，集群内其他容器通过33306端口访问mysql服务，但是外部流量不能访问mysql服务，因为mysql服务没有配置NodePort。对应的service.yaml如下：
apiVersion: v1
kind: Service
metadata:
 name: mysql-service
spec:
 ports:
 - port: 33306
   targetPort: 3306
 selector:
  name: mysql-pod

3.targetPort
容器的端口（最终的流量端口）。targetPort是pod上的端口，从port和nodePort上来的流量，经过kube-proxy流入到后端pod的targetPort上，最后进入容器。

制作容器时暴露的端口一致（使用DockerFile中的EXPOSE），例如官方的nginx（参考DockerFile）暴露80端口。 对应的service.yaml如下：
apiVersion: v1
kind: Service
metadata:
 name: nginx-service
spec:
 type: NodePort         // 有配置NodePort，外部流量可访问k8s中的服务
 ports:
 - port: 30080          // 服务访问端口
   targetPort: 80       // 容器端口
   nodePort: 30001      // NodePort   如果不给值， docker会随机给默认值
 selector:
  name: nginx-pod


4.hostPort

这是一种直接定义Pod网络的方式。hostPort是直接将容器的端口与所调度的节点上的端口路由，这样用户就可以通过宿主机的IP加上来访问Pod了，如:
apiVersion: v1
kind: Pod
metadata:
  name: influxdb
spec:
  containers:
    - name: influxdb
      image: influxdb
      ports:
        - containerPort: 8086
          hostPort: 8086

这样做有个缺点，因为Pod重新调度的时候该Pod被调度到的宿主机可能会变动，这样就变化了，用户必须自己维护一个Pod与所在宿主机的对应关系。

使用了 hostPort 的容器只能调度到端口不冲突的 Node 上，除非有必要（比如运行一些系统级的 daemon 服务），不建议使用端口映射功能。如果需要对外暴露服务，建议使用 NodePort Service。
5. 总结
总的来说，port和nodePort都是service的端口，前者暴露给k8s集群内部服务访问，后者暴露给k8s集群外部流量访问。从上两个端口过来的数据都需要经过反向代理kube-proxy，流入后端pod的targetPort上，最后到达pod内的容器。
参考：

https://blog.csdn.net/yjk13703623757/article/details/79819415
https://jimmysong.io/posts/accessing-kubernetes-pods-from-outside-of-the-cluster/
https://feisky.gitbooks.io/kubernetes/practice/portmap.html